• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

Creating HFS Disks and Images Under Snow Leopard 10.6

Mac128

68020
GOOD NEWS!

I was working with Wolf over at LEM's Vintage Mac forum and came up with an extremely simple way to copy HFS disks and images using Terminal (and I hate using Terminal). I was using a USB Zip drive, but I would think a USB floppy would work just as well.

Here's the procedure: Unmount the Zip drive using Disk Utility (don't eject), and images. Then type the following commands in OS X Terminal:

Image to Zip:

$ dd if=/Zip.dmg of=/dev/disk2s1

Zip to Image:

$ dd if=/dev/disk2s1 of=/Zip.dmg

Obviously "Zip.dmg" is the name of the disk image. "/Zip.dmg" specifies the image in the root directory or internal hard disk. "disk2s1" is the name of the USB Zip drive. This can be found by mounting the Zip disk and typing "$ mount" in Terminal. You'll see something like this in the list of reported devices: "/dev/disk2s1 on /Volumes/Untitled (hfs, local, nodev, nosuid, read-only, noowners)" Alternatively, in Disk Utility, you can click on the mounted Zip disk and "Get Info". The first item in the list will be "Disk Identifier : disk2s1" –– Make sure you unmount before you attempt to make a copy. You can do the same thing with the disk images if you don't know where they are and don't want to just put them in the root HD. Just click on the disk image in Disk Utility and look for "Full Path : /Zip.dmg".

Be patient. Terminal provides no feedback status updates of what is happening (one of the reasons I hate it besides the archaic command line interface which I thought was the whole point of the Mac to avoid). But the 100MB Zip was completely copied in less than 10 min.

ERRORS: I received an Input/Output error report on both making the disks and images, but both seemed to mount and work properly under the OS X Finder as read only. I have not yet tested them with real Macs yet. The disk image attempted to boot under Mini vMac, but reported minor repairs were needed then was unable to create a desktop database. The original disk image from which the real Zip was made and then re-imaged, worked fine in Mini vMac. So I'm not sure what the problem is yet. Also, the blank ZIP disk had already been formatted with HFS standard, so I don't yet know if formatted in another file system (i.e. FAT, HFS+) if this will still work. However, the disk image seems to be a proper HFS image, as Snow Leopard confirms it as read only, and Mini vMac easily reads it, if not able to fully start up from it.

Please, everyone, start trying this with your USB ZIP and Floppy drives under Snow Leopard to accumulate some data. There's likely a simple solution here somewhere.

Now who wants to write a script to automate this for the rest of us?

 
Last edited by a moderator:
Maybe I'm missing something here, but... if the panic here is about "How do I get software onto HFS disk images for vMac when Snow Leopard won't write to HFS disk images anymore", isn't the simplest solution to just use BasiliskII or Sheepshaver as a go-between?

Both of those emulators create a virtual drive through which one can read the host computer's UNIX filesystem. They use the same disk image format as vMac so it's not exactly challenging to fire up one of them with your for-vMac disk image mounted as a second drive and use it to copy the software from the host system over. (As a bonus, BasiliskII/Sheepshaver are much faster than and can run newer programs then vMac, so if you're dealing with .sit, .hqx, or other archive formats as a go-between it's easier to work with them then inside vMac.)

The "dd" trick is the standard way to get a bit-exact copy of a disk under UNIX. I guess I just don't see how widely useful it's going to be under these circumstances. It does work (I've done it) to make images of 1.44MB floppies, but "old" Mac software is probably going to be on 800k disks and I don't think *any* USB drives will read those. If you'll be needing to have an old Mac around to read disks anyway you can just use Disk Copy and be done with it. If you're packing up a larger disk you're probably better off using an archive format and transferring the archive file. (Which then can be made back into a disk using BasiliskII/Sheepshaver as described above.)

Another option, in theory, is that you might be able to point Basilisk directly at your hard disk/zip drive. See this page here, the part about HFS volumes. Again, I've done this under Linux (read a Mac-formatted drive hanging off a SCSI controller), but in principle it might work under OS X as well. (Similar to how you figured out the mount point to "dd" from in your instructions you'd use that as the target for setting up your volume in the Basilisk dialog box. You'll probably have to run Basilisk as root or set the executable SUID root for this to work. Again, whether it does under OS X I can't say.) I guess that's no more friendly then "dd"-ing a copy and mounting that as a disk image, but if you just want to get a subset of files off a very large disk and move them to images it might be a useful technique.

I guess I just don't see the panic angle because almost all the time I've been running Mac emulators it's been on host OSes that never had native HFS support in the first place. The tools to get by without it are certainly "there".

 
Maybe I'm missing something here, but... if the panic here is about "How do I get software onto HFS disk images for vMac when Snow Leopard won't write to HFS disk images anymore", isn't the simplest solution to just use BasiliskII or Sheepshaver as a go-between? ... Another option, in theory, is that you might be able to point Basilisk directly at your hard disk/zip drive.
With all due respect, yes you are missing something. It's not about getting disk images to work with emulators. It's about getting files out of Snow Leopard onto real media.

As you correctly point out, no one has been able to produce a real 400K or 800K disk from a current Mac since Apple dropped SuperDrive support in 1998. But that really only affects the Mac 128K through Plus and stock Mac SEs & IIs. Everything else can use a 1.44MB floppy from an OS X external USB drive. But again, that is not the point either. I, as do many others use their contemporary Mac to manage their vintage files, to download from the internet, test them in Mini vMac, and prepare floppy disk images. I don't use a 1.44MB drive, but I do use a USB ZIP drive, for which media easily transfers to my SCSI ZIP drive which I use on a Mac Plus. For the smaller 128K & 512K disks I use Terminal transfer directly out of Snow Leopard. Snow Leopard has now even limited AFP to OS X Macs. The point is, there is no easy way to get files out of Snow Leopard for use on a vintage Mac (either via network or physical media) without one or more intermediary Macs.

Also, SheepShaver nor Basilisk II can use USB devices. There is no implementation for the SCSI bus, floppy, or any other external devices. See the SheepShaver FAQ. Also, whileit is possible on Basilisk, it's not easy or stable, or practical for most. So that is not an option for creating real media or importing real media. SheepShaver (and to some extent Basilisk II) are the only viable methods for reading both HFS & HFS+ images. They make a fine method for managing them, but getting them into and out of Snow Leopard is another matter completely. To do that with any operating system appropriate drivers will have to be written. Although, I do understand that under a Windows PC SheepShaver will access the floppy drive directly (involving HFV explorer), though I'm not sure if Boot Camp will allow that on a Mac.

Finally, there is no panic. Don't over-blow the situation and what some of us are trying to accomplish. It is merely a concern. Apple has eliminated a primary means for managing old media on new Macs. The next Macs released won't even be able to boot into a System that reads and writes HFS, so this is the end of the line. I am a huge fan of Mini vMac because it just works. I fully expect the Mac II emulation (and with a IIfx ROM can run OS 8.1), to be ready by the time Apple likely drops HFS altogether (in 10.7?). Mini vMac will make working with disk images painlessly easy for even the most Unix adverse (I can't stand Unix – command line interfaces were left far behind in January 1984). But there is still no good means to manipulate HFS disk images and media at the moment, without a lot of unnecessary and often unreliable machinations. So why go to all of that trouble? Basilisk II & SheepShaver are not being actively developed anyway, and "dd" in Terminal seems to be rather easy and straightforward method for dealing with this?

Ideally, this is how a disk copy utility would work under Snow Leopard, in case it still isn't clear: Files are downloaded to the SL desktop. Mini vMac can directly import them, or vintage archived files can be put into an HFS+ disk image and transferred to an HFS disk image using SheepShaver. Within the emulator, the files can be manipulated. Using a disk copy utility (like "dd" in Terminal), the resulting HFS disk images can be copied to a real HFS disk on an external drive. Files can then be manipulated and/or generated on a Vintage Mac. The resulting disk can then be re-imaged using a disk copy utility, thereby retaining a single file that can be copied back and forth for use in an emulator in Snow Leopard and a real Mac.

 
With all due respect, yes you are missing something. It's not about getting disk images to work with emulators. It's about getting files out of Snow Leopard onto real media.
Okay, then...

Also, SheepShaver nor Basilisk II can use USB devices. There is no implementation for the SCSI bus, floppy, or any other external devices. See the SheepShaver FAQ. Also, whileit is possible on Basilisk, it's not easy or stable, or practical for most.
Actually, I think you're misunderstanding how BasiliskII/Sheepshaver work on UNIX hosts. (I don't care about Windows, which is what the BasiliskII link is about, so on that you might indeed be up a creek. Too bad, get a real operating system.) It doesn't matter that "Sheepshaver has no SCSI, floppy, or any other external device" support. As long as the *host operating system* has device drivers supporting the disk device in question and is able to present the whole disk and/or individual partitions as readable nodes under the /dev tree Sheepshaver/BasiliskII can use those device nodes for disk access. (The Sheepshaver manual shows it having the same /dev device options as BasiliskII. You set up the nodes as if they're disk images, not as entries under the "SCSCI" tab.) Again, I'll grant all the documentation about this is for Linux, but I'm willing to try it under OS X. Let's see...

(Crunch and waste some time here...)

Yes, it works. I just took a USB key (only "removable drive" I had handy) and used OS X 10.5 to erase it, write a new APM partition table (this is an important thing I had to work out, as when I merely told disk utility to put an HFS standard filesystem on it it retained the DOS MBR partition table.), and format the file system. So my USB key "looks like" a ZIP drive or external hard disk formatted on a Classic Mac. (Connected via, say, a SCSI/Firewire or SCSI/USB bridge.) Then after that, well... there's some kinks to doing this under OS X that aren't there under Linux. Luckily, other people have encountered them before:

First off, since I was using a USB key instead of a hard disk, if I used the GUI to unmount it it'd actually destroy the device node in /dev/. Here's how you get around that using the terminal commands for manipulating volumes. This problem might apply to floppy drives as well.

So after I did "diskutil unmountDisk /dev/disk2", I told Sheepshaver to mount "/dev/disk2" (the root device node for my now unmounted key) as a second volume. I am not the first person to do this under OS X. Here's a guy mounting the hard disk from his dead iMac G3 exactly the same way. I did what he did.

After doing this I booted Sheepshaver, and viola, I can see the HFS filesystem on the key, and I can drag files to and from it. Once I'm done fooling around in Sheepshaver I shut it down and then run "diskutil eject /dev/disk2". Then I pulled the key out and shoved it back into the Mac and viola, I can see the files I wrote to it. Eazy Peasy.

So that is not an option for creating real media or importing real media. SheepShaver (and to some extent Basilisk II) are the only viable methods for reading both HFS & HFS+ images. They make a fine method for managing them, but getting them into and out of Snow Leopard is another matter completely.
As demonstrated, it does work. Now, as to how useful this is: I will grant that if you just "dd" the entire volume into a disk image, manipulate it, and then write it back out the end result is basically the same. The difference is that if you're doing this to a 120MB ZIP drive you're stuck reading the entire volume into a file (ZIPs aren't fast), and then when you're done writing the entire mess back out again, while if you just mounted the ZIP inside Sheepshaver you can copy your one file and be done. (dd is also an example of one of those "scary" commands that can trash things if you foul up the command line syntax, which is another reason I don't like it, and it also doesn't do any error checking. It just blindly grabs bits and stuffs them out the other end. Mounting a disk as a filesystem *might* be slightly less likely to accumulate errors over repetitive use, although I'm sure you could make a case either way.)

dd'ing *is* probably the correct answer for floppy transfer as apparently Sheepshaver has issues parsing floppy devices directly under OS X, but for shuffling hard-disk-size volumes around, well, maybe not. Both require roughly the same level of "arcane-ity" at the command line.

Anyway, didn't mean to insult you, if you took it that way. Just pointing out there are other alternatives.

 
Actually, I think you're misunderstanding how BasiliskII/Sheepshaver work on UNIX hosts. ... dd'ing *is* probably the correct answer for floppy transfer as apparently Sheepshaver has issues parsing floppy devices directly under OS X[/url], but for shuffling hard-disk-size volumes around, well, maybe not. Both require roughly the same level of "arcane-ity" at the command line.
Again thanks for your thoughtful input. I am not surprised I do not understand how UNIX hosts work. As I said before, I use Macs so I don't have to. Somebody else works it out for me and it is otherwise transparent to me. Sadly, that becomes a problem when I need something outside the general parameters of Apple and its support communities' focus.

For me, trying to wrap my head around UNIX commands is a real headache. However, you are correct, if SheepShaver can directly access the ZIP disk then that would be the best option. Certainly "dd" on a 1.44MB disk is not such a risk or as time consuming, so no real loss there. I will reproduce your efforts with a flash drive using my ZIP disk under Snow Leopard and SheepShaver and see what comes of it. With any luck, it will yield and easy to setup method for mounting a ZIP disk directly in SheepShaver. Hard drives are less practical because they typically require a SCSI interface on any Mac which would require HFS.

 
Again thanks for your thoughtful input. I am not surprised I do not understand how UNIX hosts work. As I said before, I use Macs so I don't have to. Somebody else works it out for me and it is otherwise transparent to me. Sadly, that becomes a problem when I need something outside the general parameters of Apple and its support communities' focus.
No problem.

For me, trying to wrap my head around UNIX commands is a real headache. However, you are correct, if SheepShaver can directly access the ZIP disk then that would be the best option. Certainly "dd" on a 1.44MB disk is not such a risk or as time consuming, so no real loss there. I will reproduce your efforts with a flash drive using my ZIP disk under Snow Leopard and SheepShaver and see what comes of it.
If you have any trouble figuring it out yourself I can probably help you with a recipe that'll do it. Here's a reader's digest version.

1: Open a Terminal.

2: Plug in your ZIP drive with the disk you want to read inserted. At this point SL will probably mount it read-only. Once you see it in the finder...

3: Enter "diskutil list". The output will look like something like this:

Code:
~$ diskutil list
/dev/disk0
  #:                       TYPE NAME                    SIZE       IDENTIFIER
  0:      GUID_partition_scheme                        *149.1 Gi   disk0
  1:                        EFI                         200.0 Mi   disk0s1
  2:                  Apple_HFS YayApple               148.7 Gi   disk0s2
/dev/disk2
  #:                       TYPE NAME                    SIZE       IDENTIFIER
  0:     Apple_partition_scheme                        *960.0 Mi   disk2
  1:        Apple_partition_map                         31.5 Ki    disk2s1
  2:                  Apple_HFS Woot                    960.0 Mi   disk2s2
In this case, the disk showed up as /dev/disk2. The second partition, named "Woot" in this case, is the one that actually contains the data so if you were to type "mount" you would see something like this:

Code:
/dev/disk2s2 on /Volumes/Woot (hfs, local, nodev, nosuid, noowners)
Your disk of course might show up as something else. It almost certainly *won't* be /dev/disk0 and it would probably be a Bad Thing to point Sheepshaver at that. Moving on, assuming it came up as disk2...

4: Enter: "diskutil unmountDisk /dev/disk2" . The mounted volume should disappear from the finder. Verify the device node is still connected by typing "diskutil list" again. Output should look the same as before. At least with my flash drive hitting the "^" icon in the finder "ejected" the disk and destroyed the device node, so don't do that.

5: Start the Sheepsaver GUI. Hit the "add ..." button on the Volumes tab and type "/dev/disk2" as the path. Once done, hit start. With any luck at all when Sheepshaver comes up your drive will appear on the desktop.

When you're done with Sheepshaver, type "diskutil eject /dev/disk2" (or whatever it gets mapped as) before unplugging the Zip. I don't know if that's crucial, but the one page about memory cards suggested that doing so flushes any unwritten buffer. You'll probably want to remove the /dev/ entry from the sheepshaver config when you're not using it, as otherwise it might try mapping, I dunno, your digital camera, into Sheepshaver if you start it with it plugged in.

With any luck, it will yield and easy to setup method for mounting a ZIP disk directly in SheepShaver. Hard drives are less practical because they typically require a SCSI interface on any Mac which would require HFS.
In theory at least you might be able to use this thing to mount a SCSI drive the same way, assuming it works with 10.6. (It does work with 10.5)

 
In theory at least you might be able to use this thing to mount a SCSI drive the same way, assuming it works with 10.6. (It does work with 10.5)
I thought about that too, but those little buggers were hard to come by at the time and expensive ($109 in 2009!?), nor widely adopted or supported. Given the ease of use and inexpensive availability of ZIP drives, combined with the smaller disk size which would result in less data loss in the event of corruption (which SheepShaver and Basilisk are prone to), it's less attractive to me. But it's worth a shot.

 
In theory at least you might be able to use this thing to mount a SCSI drive the same way, assuming it works with 10.6. (It does work with 10.5)
I thought about that too, but those little buggers were hard to come by at the time and expensive ($109 in 2009!?), nor widely adopted or supported. (...)
$109 actually seems incredibly reasonable for an obscure tech product that by definition isn't going to sell in large quantities yet satisfies a real need, but I suppose it depends on your point of view. In 1986 a "Digi-Mouse" for a Tandy 1000 computer was $99 for the mouse and another $99 for the controller board. (The Radio Shack catalog archive was the first place I could think of to find a price list from the early mac era.)

 
5: Start the Sheepsaver GUI. Hit the "add ..." button on the Volumes tab and type "/dev/disk2" as the path. Once done, hit start. With any luck at all when Sheepshaver comes up your drive will appear on the desktop.
I got this far then lost you. The only GUI for OS X I could find is SheepShaversPrefs.app Clicking "add" opens a box that only allows you to search for disk images. Are you aware of a specific GUI app for OS X and SheepShaver? Otherwise this is a dead end.

 
5: Start the Sheepsaver GUI. Hit the "add ..." button on the Volumes tab and type "/dev/disk2" as the path. Once done, hit start. With any luck at all when Sheepshaver comes up your drive will appear on the desktop.
I got this far then lost you. The only GUI for OS X I could find is SheepShaversPrefs.app Clicking "add" opens a box that only allows you to search for disk images. Are you aware of a specific GUI app for OS X and SheepShaver? Otherwise this is a dead end.
I used the SheepShaver 2.3 snapshot from this site. It includes a settings/launcher application called "SheepShaverGUI". I guess I remember seeing something on blog post about mounting the iMac drive... and there it is. Scroll down until you see this:

"SheepShaverGUI?? What about the new SheepShaver builds?" you are of course thinking. Good questions. Let's say that I launch either of the new SheepShaver applications and then choose the SheepShaver menu's Preferences... command, which opens the window below: ...
Either download the older version and edit the configuration with it, or edit the ".sheepshaver_prefs" file in your home directory to manually add the "disk /dev/diskX" (X=whatever you got from following my instructions) line.

The ugly truth about computers is when you "simplify" GUI's by simply cutting out functionality and eliminating the ability for an "advanced" user to do what they want you're usually shooting yourself (and your users) in the foot. Apple does it all the time, I guess it's natural the Sheepshaver developers would too.

 
I used the SheepShaver 2.3 snapshot from this site. It includes a settings/launcher application called "SheepShaverGUI".
Good news, bad news.

First the good news. The old GUI works just fine under Snow Leopard. I was able to set the device path. SheepSaver 2.3 and the latest build both mount the device. FYI, for those who do not wish to get their hands dirty with Terminal can unmount the volume in Disk Utility just as easily (as well as get the device info).

Now for the bad news. SheepShaver mounts the device but immediately gives me the old "This Mac Cannot Recognize This Disk ... Do You Want To Initialize" Then it gives me only one visible choice: "ProDOS OK" I can also select another position on the drop bar with nothing. I have not yet initialized the disk because it otherwise shows up on my Snow Leopard desktop as a perfectly readable HFS volume, and under Panther, a fully interactive HFS volume. Again I have not tested it on a vintage Mac yet. However, when I launch Disk First Aid under SheepShaver's 8.6, the ZIP drive shows up with a garbage name: "p!.. IȦ̇̃ ᴂ". Choosing "erase" also only produces ProDOS OK, or the blank option. Attempting to erase other volumes produces the choice of HFS standard. So I'm not sure where the problem lies.

EDIT: Some good news. I put in a ZIP disk which was formatted HFS on a vintage Mac. The ZIP disk that did not show up properly was formatted HFS under Panther.

Evidently the disk must be pre-formatted HFS standard in order for SheepShaver to mount it or erase it.

 
Now for the bad news. SheepShaver mounts the device but immediately gives me the old "This Mac Cannot Recognize This Disk ... Do You Want To Initialize" Then it gives me only one visible choice: "ProDOS OK" I can also select another position on the drop bar with nothing. I have not yet initialized the disk because it otherwise shows up on my Snow Leopard desktop as a perfectly readable HFS volume, and under Panther, a fully interactive HFS volume. Again I have not tested it on a vintage Mac yet. However, when I launch Disk First Aid under SheepShaver's 8.6, the ZIP drive shows up with a garbage name: "p!.. IȦ̇̃ ᴂ". Choosing "erase" also only produces ProDOS OK, or the blank option. Attempting to erase other volumes produces the choice of HFS standard. So I'm not sure where the problem lies.

EDIT: Some good news. I put in a ZIP disk which was formatted HFS on a vintage Mac. The ZIP disk that did not show up properly was formatted HFS under Panther.

Evidently the disk must be pre-formatted HFS standard in order for SheepShaver to mount it or erase it.
Can you post the output of "diskutil list" for the disk that didn't work? Seeing you say that the one that didn't work was formatted under Panther makes me think I know what's wrong.

(In my first post about doing this with a USB stick, I mentioned I had to force Disk Utility to repartition the disk with an "Apple Partition Map" partition table. USB sticks of course by default have a DOS MBR partition table, and merely "formatting" the disk with Disk Utility kept the MBR style partition table. With the MBR table when I tried to mount the stick in Sheepshaver I got exactly what you did, that prompt about formatting it "ProDOS OK". I'm willing to bet your "bad" ZIP disk has an MBR partition table on it.

That of course would never happen on a disk formatted under OS 9 or earlier.)

 
Can you post the output of "diskutil list" for the disk that didn't work? Seeing you say that the one that didn't work was formatted under Panther makes me think I know what's wrong.
At the moment, no. The disk will no longer mount under anything, even to attempt a re-format. Clearly, this is far from a simple procedure and not for everyone. I'm going to attempt to reformat it under my SCSI ZIP with a vintage Mac. I am starting to think that ZIP disks may have a delicate relationship with Snow Leopard and even OS X in general. There was full functionality from 8.6 to 10.2. But, from Panther to Tiger, Iomega indicates the drivers are included in OS X, and post a list of disclaimers about what won't work anymore. Leopard has a similar disclaimer, but a Snow Leopard update which doesn't specifically mention the ZIP 100.

Also, I see that a year ago this topic was presciently covered by Low End Mac. At least with Leopard, this article reports good success using "dd" with USB floppy disks.

 
In theory at least you might be able to use this thing to mount a SCSI drive the same way, assuming it works with 10.6. (It does work with 10.5)
I thought about that too, but those little buggers were hard to come by at the time and expensive ($109 in 2009!?), nor widely adopted or supported. (...)
$109 actually seems incredibly reasonable for an obscure tech product that by definition isn't going to sell in large quantities yet satisfies a real need, but I suppose it depends on your point of view. In 1986 a "Digi-Mouse" for a Tandy 1000 computer was $99 for the mouse and another $99 for the controller board. (The Radio Shack catalog archive was the first place I could think of to find a price list from the early mac era.)

I've seen FireWire to SCSI adapters far cheaper on the used market.

The one I have works great. I use it to zero out hard drives with my eMac at the warehouse, in conjunction with the shell of an old external SCSI CD-ROM that died. You don't have to reboot after every hard drive (just unplug the adapter from FireWire, and it's off), so I can wipe a lot faster.

 
As it turns out, Disk Utility WILL create an HFS standard disk image from an external drive. Mount and highlight the HFS drive you want to create an image from. Under "File", "New", "Disk Image From (Select a Device)..." This produces a perfectly functional HFS disk image.

Presumably, Disk Utility must be able to mount the disk in question, so if Apple ever completely drops HFS, I would presume the option will no longer be possible in Disk Utility. Is this just "dd" via Disk Utility, or is Disk Utility really something helpful?

 
if it detects no filesystem, you could just image the device.
Please confirm. I have only tried this with a ZIP drive, but while Disk Utility would go through the motions of imaging the device, it failed to produce an actual image, with errors. Only imaging the mounted volume produced an image. Have you actually done this?

 
Back
Top