Opening classic Mac disk images with OSX

[bigmessowires]

I just stumbled onto something that surprised me, but I'm not sure if it's common knowledge. Current versions of OSX (at least 10.13 High Sierra that I'm running) are able to mount and open classic Mac HFS disk images! I had thought this capability was removed in OSX 10.7, and I guess it was for Disk Copy 4.2 disk images, but raw HFS disk images still work just fine. These are the disk images that typically have a .DSK filename extension, and are used with emulation tools like Floppy Emu and Mini vMac. The trick is that you must rename the file to .IMG in order to make OSX 10.13 recognize it. After that you can just double-click the disk image to open it:



It's read-only, but even so this method is still a million times easier than screwing around with Mini vMac and ExportFL just to transfer some old files onto a modern system. 

Did everyone else already know this, and I'm just utterly clueless? That would be embarrassing.   

Edit: it also looks like you can open raw HFS disk images from the command line, with no file renaming necessary. Just type:

hdiutil attach -imagekey diskimage-class=CRawDiskImage myDiskImage.dsk

 

[bigmessowires]

Given the zero replies, I'm assuming everyone else already knew this. Is there an easier way to accomplish the same thing?

 

[retrodev]

I've seen it discussed on eMaculation. High Sierra can still open HFS disk images. It was the writing capability that was removed in Lion.

No one seems to have a good solution for writing to HFS disks on modern machines. I use SheepShaver running OS 9 to create and write HFS images.

 

[bigmessowires]

Is there a simple way to open the HFS images without having to rename the files? Other than the command line syntax I described above.

 

[nglevin]

LaunchServices on macOS treats the Uniform Type Identifiers (UTIs) it has associated for a given file or folder extension as its source of truth. You can probe into the identifiers macOS uses with one of the Spotlight command line tools, mdls.

mana:~ nglevin$ mdls -name kMDItemContentType /Users/nglevin/Downloads/DiskTools85_PPC.img
kMDItemContentType = "com.apple.disk-image-ndif"
mana:~ nglevin$ mdls -name kMDItemContentTypeTree /Users/nglevin/Downloads/DiskTools85_PPC.img
kMDItemContentTypeTree = (
"public.archive",
"public.item",
"public.data",
"public.disk-image",
"com.apple.disk-image",
"com.apple.disk-image-ndif"
)
mana:~ nglevin$


That also affects what app is used when you use "open" on the command line. You can also use a different app's bundle identifier to "open" with another app, if you wish. The macOS man page documentation for open covers that.

For more information on how macOS associates what with what (tl;dr, the plists found within indexed macOS apps):

https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/understanding_utis/understand_utis_conc/understand_utis_conc.html

https://superuser.com/questions/246476/create-new-extension-association-and-icon-in-snowleopard/246493

Fortunately usage of Spotlight hasn't changed much since Snow Leopard, so it's not as difficult to find documentation on this as it used to be. Like launchd.

 

[bigmessowires]

Have you tried that to verify it works? I don't think that will help, because it's not simply a question of the association between filename extension and default application to open it. For example if I force DiskImageMounter or DiskUtility to open a .DSK file by right-clicking and "Open With...", it doesn't work. I get an error "legacy image should be converted" and the disk image won't be opened.

The problem is that DiskImageMounter and Disk Utility actually do something different depending on the filename extension. They appear to use the extension (at least in part) to determine what type of disk image they're dealing with, instead of making a decision based on the contents of the image file. If I rename the .DSK file to .IMG, the "legacy image" error disappears and it suddenly works. Same if I manually force it to use raw disk image mounting, with the command line syntax from my first post.

 

[nglevin]

Well, I presented what's happening at the Finder level. macOS loves UTIs and plists.  But if you're specific about DiskImageMounter.

I don't believe there is any documentation specific to DiskImageMounter, and there's no command line options that I can see to manipulate it with. But there is hdiutil, which has the same problem with .dsk file extensions that you've noticed.

EDIT: Alternatively, you could dig around hdiutil to see what macOS is looking for from it's disk images. While it will mount disk images without checksums, it will complain a bit, and it certainly won't be able to do the macOS verification dance that it wants to do with "hdiutil verify filename".

 

[nglevin]

So with some probing with the dsk extension on a non-checksummed Disk Copy 6(?)* image:

mana:~ nglevin$ hdiutil attach -verbose /Users/nglevin/Downloads/DiskTools85_PPC.dsk
Initializing…
DIBackingStoreInstantiatorProbe: interface 0, score 100, CBSDBackingStore
DIBackingStoreInstantiatorProbe: interface 1, score -1000, CBundleBackingStore
DIBackingStoreInstantiatorProbe: interface 2, score -1000, CRAMBackingStore
DIBackingStoreInstantiatorProbe: interface 3, score 100, CCarbonBackingStore
DIBackingStoreInstantiatorProbe: interface 4, score -1000, CDevBackingStore
DIBackingStoreInstantiatorProbe: interface 5, score -1000, CCURLBackingStore
DIBackingStoreInstantiatorProbe: interface 6, score -1000, CVectoredBackingStore
DIBackingStoreInstantiatorProbe: interface 0, score 100, CBSDBackingStore
DIBackingStoreInstantiatorProbe: interface 1, score -1000, CBundleBackingStore
DIBackingStoreInstantiatorProbe: interface 2, score -1000, CRAMBackingStore
DIBackingStoreInstantiatorProbe: interface 3, score 100, CCarbonBackingStore
DIBackingStoreInstantiatorProbe: interface 4, score -1000, CDevBackingStore
DIBackingStoreInstantiatorProbe: interface 5, score -1000, CCURLBackingStore
DIBackingStoreInstantiatorProbe: interface 6, score -1000, CVectoredBackingStore
DIFileEncodingInstantiatorProbe: interface 0, score -1000, CMacBinaryEncoding
DIFileEncodingInstantiatorProbe: interface 1, score -1000, CAppleSingleEncoding
DIFileEncodingInstantiatorProbe: interface 2, score -1000, CEncryptedEncoding
DIFileEncodingInstantiatorProbe: interface 0, score -1000, CUDIFEncoding
DIFileEncodingInstantiatorProbe: interface 0, score -1000, CSegmentedNDIFEncoding
DIFileEncodingInstantiatorProbe: interface 1, score -1000, CSegmentedUDIFEncoding
DIFileEncodingInstantiatorProbe: interface 2, score -1000, CSegmentedUDIFRawEncoding
DIDiskImageInstantiatorProbe: interface 0, score -1000, CUDIFDiskImage
DIDiskImageInstantiatorProbe: interface 1, score 0, CSparseBundleDiskImage
DIDiskImageInstantiatorProbe: interface 2, score 0, CSparseDiskImage
DIDiskImageInstantiatorProbe: interface 3, score 0, CRawDiskImage
DIDiskImageInstantiatorProbe: interface 4, score 0, CDARTDiskImage
DIDiskImageInstantiatorProbe: interface 5, score 0, CDiskCopy42DiskImage
DIDiskImageInstantiatorProbe: interface 6, score 0, CNDIFDiskImage
DIDiskImageInstantiatorProbe: interface 8, score -100, CShadowedDiskImage
DIDiskImageInstantiatorProbe: interface 9, score -1000, CCFPlugInDiskImage
DIDiskImageInstantiatorProbe: interface 10, score -100, CWrappedDiskImage
DIDiskImageNewWithBackingStore: probe fails to find appropriate CDiskImage class.
Attaching…
Error 110 (image not recognized).
Finishing…
DIHLDiskImageAttach() returned 110
hdiutil: attach failed - image not recognized
mana:~ nglevin$




And then again with the .img extension on that same image:

mana:~ nglevin$ hdiutil attach -verbose /Users/nglevin/Downloads/DiskTools85_PPC.img
Initializing…
DIBackingStoreInstantiatorProbe: interface 0, score 100, CBSDBackingStore
DIBackingStoreInstantiatorProbe: interface 1, score -1000, CBundleBackingStore
DIBackingStoreInstantiatorProbe: interface 2, score -1000, CRAMBackingStore
DIBackingStoreInstantiatorProbe: interface 3, score 100, CCarbonBackingStore
DIBackingStoreInstantiatorProbe: interface 4, score -1000, CDevBackingStore
DIBackingStoreInstantiatorProbe: interface 5, score -1000, CCURLBackingStore
DIBackingStoreInstantiatorProbe: interface 6, score -1000, CVectoredBackingStore
DIBackingStoreInstantiatorProbe: interface 0, score 100, CBSDBackingStore
DIBackingStoreInstantiatorProbe: interface 1, score -1000, CBundleBackingStore
DIBackingStoreInstantiatorProbe: interface 2, score -1000, CRAMBackingStore
DIBackingStoreInstantiatorProbe: interface 3, score 100, CCarbonBackingStore
DIBackingStoreInstantiatorProbe: interface 4, score -1000, CDevBackingStore
DIBackingStoreInstantiatorProbe: interface 5, score -1000, CCURLBackingStore
DIBackingStoreInstantiatorProbe: interface 6, score -1000, CVectoredBackingStore
DIFileEncodingInstantiatorProbe: interface 0, score -1000, CMacBinaryEncoding
DIFileEncodingInstantiatorProbe: interface 1, score -1000, CAppleSingleEncoding
DIFileEncodingInstantiatorProbe: interface 2, score -1000, CEncryptedEncoding
DIFileEncodingInstantiatorProbe: interface 0, score -1000, CUDIFEncoding
DIFileEncodingInstantiatorProbe: interface 0, score -1000, CSegmentedNDIFEncoding
DIFileEncodingInstantiatorProbe: interface 1, score -1000, CSegmentedUDIFEncoding
DIFileEncodingInstantiatorProbe: interface 2, score -1000, CSegmentedUDIFRawEncoding
DIDiskImageInstantiatorProbe: interface 0, score -1000, CUDIFDiskImage
DIDiskImageInstantiatorProbe: interface 1, score 0, CSparseBundleDiskImage
DIDiskImageInstantiatorProbe: interface 2, score 0, CSparseDiskImage
DIDiskImageInstantiatorProbe: interface 3, score 100, CRawDiskImage
DIDiskImageInstantiatorProbe: interface 4, score -1000, CDARTDiskImage
DIDiskImageInstantiatorProbe: interface 5, score -1000, CDiskCopy42DiskImage
DIDiskImageInstantiatorProbe: interface 6, score 0, CNDIFDiskImage
DIDiskImageInstantiatorProbe: interface 8, score -100, CShadowedDiskImage
DIDiskImageInstantiatorProbe: interface 9, score -1000, CCFPlugInDiskImage
DIDiskImageInstantiatorProbe: interface 10, score -100, CWrappedDiskImage
DIDiskImageNewWithBackingStore: CRawDiskImage
DIDiskImageNewWithBackingStore: instantiator returned 0
Attaching…
DI_kextWaitQuiet: about to call IOServiceWaitQuiet...
DI_kextWaitQuiet: IOServiceWaitQuiet took 0.000006 seconds
2018-05-11 11:07:18.190 diskimages-helper[4100:702572] DIHelperHDID serveImage: attaching drive
{
autodiskmount = 1;
"hdiagent-drive-identifier" = "3DEF3AD5-6BA0-4ED2-AC88-4FC851B89BBD";
"unmount-timeout" = 0;
}
2018-05-11 11:07:18.192 diskimages-helper[4100:702572] DIHelperHDID serveImage: connecting to myDrive 0x410B
2018-05-11 11:07:18.192 diskimages-helper[4100:702572] DIHelperHDID serveImage: register _readBuffer 0x112119000
2018-05-11 11:07:18.192 diskimages-helper[4100:702572] DIHelperHDID serveImage: activating drive port 17163
2018-05-11 11:07:18.192 diskimages-helper[4100:702572] DIHelperHDID serveImage: set cache enabled=TRUE returned FAILURE.
2018-05-11 11:07:18.222 diskimages-helper[4100:702572] DIHelperHDID serveImage: set on IO thread=TRUE returned SUCCESS.
2018-05-11 11:07:18.222 diskimages-helper[4100:702572] -processKernelRequest: will sleep received
Checking volumes…
Prompting user…
There may be a problem with this disk image. Are you sure you want to open it?
[Opening this disk image may make your computer less secure or cause other problems.]
Attach? (Y/N) y
Volume check completed…
Mounting…
2018-05-11 11:07:20.694 diskimages-helper[4100:702570] _mountDevEntries: disk2 aborting mountpoint postflight because disk image has no band size specified.
Finishing…
Finishing…
/dev/disk2 /Volumes/Disk Tools
mana:~ nglevin$




Looks like there's no way to force it to interpret the disk image differently without changing the filename, alas. Which is a very UTI-ish way of addressing the problem of mounting disk images.

btw, the entire HISTORY section of hdiutil's man page documentations is neat. Goes through the history of Mac disk images from Disk Copy 4.2 on.

* - EDITed postscript: Checking how macOS is probing the image in the output above, what I thought was a Disk Copy 6.1+ image (NDIF) is probably just a raw byte by byte dump of a diskette from a tool like dd.

 

[Rasmus]

I just stumbled onto something that surprised me, but I'm not sure if it's common knowledge. Current versions of OSX (at least 10.13 High Sierra that I'm running) are able to mount and open classic Mac HFS disk images! I had thought this capability was removed in OSX 10.7, and I guess it was for Disk Copy 4.2 disk images, but raw HFS disk images still work just fine. These are the disk images that typically have a .DSK filename extension, and are used with emulation tools like Floppy Emu and Mini vMac. The trick is that you must rename the file to .IMG in order to make OSX 10.13 recognize it. After that you can just double-click the disk image to open it:

It's read-only, but even so this method is still a million times easier than screwing around with Mini vMac and ExportFL just to transfer some old files onto a modern system. [...]

Edit: it also looks like you can open raw HFS disk images from the command line, with no file renaming necessary. Just type:

hdiutil attach -imagekey diskimage-class=CRawDiskImage myDiskImage.dsk

Thanks! This is quite useful. Sounds like you will have to rewrite the last page of the Floppy Emu user manual!?

I imagine this is old news to many here, but here's the current work flow I'm using to move my Disk Copy 4.2 disk images from the SE FDHD ("SuperDrive") running 6.0.8 that I've used to create them over to my 2017 iMac 5K:

[1] Follow instructions to boot the SE from the Floppy Emu HD20.dsk = "Hard Disk 6.0.8"

[2] Copy the folder(s) in question from the SE's hard drive to "Hard Disk 6.0.8"

[3] Shut down the SE and move the SD card from the Floppy Emu to the iMac

[4] Copy HD20.dsk to the iMac

[5] Change the file extension from .dsk to .img

[6] Voila! High Sierra/APFS opens HD20.img as a disk image and the folder(s) can be copied to the iMac
 

The Disk Copy 4.2 .image files are intact, with the proper disk-image icons and the correct dates.

For things to go on the internet and into long-term storage, I'm wrapping them in the Stuffit 3.5 .sit format on the SE, then moving them as above. I haven't had any issues expanding .sit files in OS X and macOS using The Unarchiver. I agree entirely with hanaquil that this format is best (as opposed to later Stuffit 5 or Stuffit X formats) for most people looking to use Disk Copy to make floppies, because it makes bringing the disk images to System 6 safe and easy.

I might experiment with the last shareware version of Stuffit (1.5.1), to try to make archives that can travel back to before System 6 and make floppies on, say, a Macintosh 512K. I'm not sure how feasible that is, but we'll see.