Creating HFS Images in macOS?

[PotatoFi]

As is commonly known, modern versions of macOS are able to read HFS volumes, but not write to them. While I consider it very lucky that I have a 1.44mb floppy drive to work with on my Macintosh SE FDHD, writing floppy disks for it with my MacBook Pro and a USB floppy drive presents some unique challenges.

First, here's what I CAN do with macOS 10.14.2, a 1.44mb USB floppy drive, and my Macintosh SE FDHD today:

• Write .img and .dsk images to floppies with my Macbook Pro, and read and write to them with my Macintosh SE
  
• Write files to floppies with my Macintosh SE FDHD, and read them on my MacBook Pro
  

What I CANNOT do is this:

• Write loose files to floppies with my MacBook Pro
  

When software comes as a .dsk or .img, I'm usually in good shape (although some images will randomly fail to be read by the Macintosh SE). But loose files are a no-go, because my MacBook can't write HFS. I tried an Ubuntu VM, and at face value it seems to have the same limitation. Also, an entire Ubuntu VM is a lot of resources to dedicate to just writing files to floppies. I can slog out my iMac G3... but not everyone has an iMac G3, and it's heavy to move around.

So, I turned my attention to Mini vMac. My theory is that if I could:

1. Move files into Mini vMac with ImportFL
   
2. Mount a blank 1.44mb image, move the files into the image , unmount the image
   
3. Write the image to a floppy disk with DD
   

This would allow me to write loose files to a disk that a classic Macintosh could read with no additional hardware, other than a cheap 1.44mb USB floppy drive. Here's the set of commands that I use to write images to the floppy in macOS 10.14:

diskutil list


To determine which volume is my floppy drive. On my system, this is usually /dev/disk5

diskutil ummount /dev/disk5


Not always necessary, but if macOS mounts the HFS volume this must be done before using DD.

sudo dd if=diskimage.dsk of=/dev/disk5 bs=84 skip=1


This writes the image to the floppy.

Sound like an airtight plan? I thought so, until I tried it. Sadly, my Macintosh SE does not recognize these custom disk images that I've made. I've reached a dead end. Any ideas what I might be doing wrong, or if there's a potential fix?

 

[LaPorta]

As an aside, if these are loose program or other resource-laden files, copying them from your MBP to the floppy, even if  you were able to do so, will not preserve the resource forks in the copy. If you were, say, sending over a Word document, it might work, but it's type and creator codes would be lost.

One modification that you could try is doing as you said moving the files into Mini vMac, mounting the 1.44 MB floppy image, transfer, unmount, then copy the image file itself to the floppy, and use a utility like MountImage to open the image on your SE. Just be sure that the image you are using is a Disk Copy 4.2 image.

 

[PotatoFi]

I got it working! Well, for loose files, like you said. Sadly, applications do not launch on my Macintosh SE for the reasons you gave. The solution was in dd, the "skip" command needs to be dropped:

sudo dd if=diskimage.dsk of=/dev/disk5 bs=84


I'll do a full writeup soon of the entire process with screenshots. Maybe a video. For now, I'm going to experiment with copying .sit files in with this method, and expanding them on the Macintosh SE with StuffIt Expander. That should keep macOS 10.14's hands off of the files and preserve the resource forks? Maybe? We'll see.

 

[nglevin]

Regarding handling old Mac files, APFS still recognizes and preserves resource forks as MFS, HFS and HFS+ did, which is kind of a surprise.

The problem is that most command line tooling, especially Linux/BSD derived tooling, doesn't really know how to handle the resource forks properly. Git will pretend they're not there, the diff tool doesn't acknowledge their presence, and only the very latest versions of rsync (unfortunately not the one that ships with macOS) will so much as try to preserve a resource fork in any form.

Worse is that starting with I believe High Sierra, possibly Sierra itself, the command line tooling to transform resource forks into AppleDouble encoded data was removed from the Mac OS X package

Mac OS X still preserves resource forks if you create ZIP files from the Finder's File -> Compress option, but I can't give you any guarantees that the included "zip" command line tool does the same. The man page documentation for command line "zip" still says...

Support for some Mac OS features in the Unix Mac OS X port, such as resource forks, is expected in the next zip release.

...which is reassuring.

All of this is separate from the larger problem of managing HFS from modern Mac OS X. I still think the best path forward for that really is with emulators like Mini vMac and any virtualization solution that runs Mac OS X 10.5 or earlier.

 

[PotatoFi]

Ok, getting .sit files to my Macintosh SE if cake now... but for some reason, StuffIt Expander (this one specifically) does not see the ".sit" files on the disk. I haven't used StuffIt Expander before... any ideas why I'm running into this problem?

 

[LaPorta]

I’ve run into this, and I mean to rectify it in the future with my archive. Basically, the SIT files you have are too new for the older Expander. My goal is to stuff all my System 6 stuff with StuffIt 1.5.1 or so on a native machine, THEN re-copy it to my house server.

In the interim, if there’s anything you need right now, ASAP, send me the files (PM me for email) and I will re-stuff with an older StuffIt version.

i like your technique...this is amazing. I have a USB SuperDisk Drive that I could try this with!

EDIT: sometimes this is also due to the archive no longer having type/creator codes, and older versions of Expander only looking for those specific type codes in documents. You could try using ResEdit to put in the correct codes and see if it works...no guarantee, though.

 

[Bolle]

I gave up on the whole HFS thing and use DOS formatted floppies now. Just encode all files to binary before copying them to the floppy and all your resource forks will make it over. Decoding can be done with MacBinary or Stuffit.

In the event I really need to write to a HFS disk I have a VM with 10.5 around which can write to HFS just fine. Seems to be less hazzle than getting things into vmac and then waste time copying a whole image to the floppy if I just need a 37K file.

 

[davidg5678]

I have been experimenting with something similar after reading about it in another thread. With the Basilisk II emulator, it is possible to mount Zip Disks containing a bootable MacOS installation directly into the emulator on a modern mac. Basilisk II is able to view the modern mac filesystem from within emulation as a drive labeled Unix. I am able to download files from the internet, decompress them with The Unarchiver under High Sierra, and then view and copy the files directly onto the Zip Disk from the emulator. The Zip Disk can then (theroretically) be booted on original hardware. This method should also allow for booting off an image on the modern mac and just mounting floppy disks in the emulation.

First I unmount the drive, then give my user account root access to the drive partition eg: sudo chown chu-oh /dev/disk2s2 then I add that drive as a volume in BasiliskII. BasiliskII allows you to mount folders on your mac as drives so you can drag and drop files to the HFS drive. 

 

[LaPorta]

I gave up on the whole HFS thing and use DOS formatted floppies now. Just encode all files to binary before copying them to the floppy and all your resource forks will make it over. Decoding can be done with MacBinary or Stuffit.

How do you get System 6 to read DOS floppies?

 

[PotatoFi]

I have yet to find a single StuffIt file that works with StuffIt 4.0.2. Are they really all encoded with newer versions of StuffIt? They just show up as a generic "file" in System 6, and StuffIt stubbornly does not see the file to open it. Is this because both Windows and macOS 10.14 are blowing up the resource forks?

 

[nglevin]

If it's not split up across multiple floppy disks, it was probably compressed with StuffIt 5.5. Recalling what StuffIt's original audience once was.  :tongue:

macOS 10.14 shouldn't blow up any resource forks, I can still DeRez and Rez them with ease using the latest Xcode toolchain. What proof do you have that Mojave is mishandling them?

 

[PotatoFi]

I really don't have any, this is all pretty new to me. I guess I need to try unstuffing them on my OS X 10.4 box, and writing them to an HFS floppy. I'll give that a shot next.

 

[BadGoldEagle]

because my MacBook can't write HFS

It can, well sort of...

I use HFS Disk Maker when I want to mount loose files to vMac and create proper images to put on real physical disks later down the line.

It basically creates an HFS .dsk image from an existing HFS+/APFS folder on your modern Mac. A couple of seconds later you have an HFS disk that will work 99% of the time in a real Mac. 

From vMac you can edit the image to your liking. Shut down the emulator, use dd to write it to a floppy and boom, you're done.

Isn't that what you were trying to do?

 

[LaPorta]

I have yet to find a single StuffIt file that works with StuffIt 4.0.2. Are they really all encoded with newer versions of StuffIt? They just show up as a generic "file" in System 6, and StuffIt stubbornly does not see the file to open it. Is this because both Windows and macOS 10.14 are blowing up the resource forks?

Can you send me some

of your files to play around with?

 

[LaPorta]

. What proof do you have that Mojave is mishandling them?

10.4 still enables you to run Mac OS 9 in Classic mode. Once that was taken away (in 10.5, if I’m not mistaken), there was no longer any reason to support resource forks.

 

[nglevin]

10.4 still enables you to run Mac OS 9 in Classic mode. Once that was taken away (in 10.5, if I’m not mistaken), there was no longer any reason to support resource forks.

Uh, what? I'm running all three operating systems, and resource forks are still supported on Mac OS X 10.4, 10.5 and macOS 10.14. I'm not sure why you think they're no longer supported on 10.14.

In Sierra, they were handled as part of a file's extended attributes. Check page 80 of the APFS File System Reference documentation, there's a special Inode to define and preserve the resource fork. Earlier in this thread, I pointed out a developer tool (Rez and DeRez) whose sole purpose is to create .r files to act as a textual representation of the resource fork, and it still works great in 10.14.

EDIT: And to be maybe thorough with this, I used DeRez on 10.14.2 with a System 7 app as its argument (specifically, Laurie Strode's shareware MIDI Terminal) on an APFS disk that was unstuffed with Smith Micro StuffIt Expander 16.0.6 from the Mac App Store and got the full resource fork printed in nice text based format, starting with:

mojave-mac:~ nglevin$ DeRez /Users/nglevin/Downloads/MIDI\ Terminal™\ 1.2.2/MIDI\ Terminal™\ 1.2.2

data 'DATA' (0, purgeable, protected) {

$"0000 1A53 6176 6520 756E 6465 7220 7768"            /* ...Save under wh */

$"6174 2066 696C 6520 6E61 6D65 3F00 0000"            /* at file name?... */

$"0C45 6E64 206F 6620 4669 6C65 2E00 0000"            /* .End of File.... */

$"0114 1341 626F 7574 204D 4944 4920 5465"            /* ...About MIDI Te */

 

[PotatoFi]

I just took a bunch of .sit files over to my iMac G3 running 10.4, and I used StuffIt Expander 2010 to unstuff them directly to an HFS floppy. Success! When I bring them over to System 6, they work great. I think I've found my workflow.

All of that said... for accessibility on modern systems, it seems like having a .dsk image that you can DD to a floppy is the easiest solution. Not everyone is as lucky as I am to have a machine with 10.4 kicking around.

 

[nglevin]

To reiterate another point made in this thread, 10.5 handles HFS as well as 10.4, as mentioned before, and the Server version works great on VMware and Parallels.

I also know Leopard works fine with USB floppy drives, as I used it ten years ago to shuffle files that way. Not as great as a local network, really, which Leopard also handles fine with AppleTalk support for old Mac OS.

That networking support was unfortunately removed in Snow Leopard 10.6 along with HFS (not HFS+) support. Which is a shame because the state of olde Apple networking seemed to be getting better in Leopard (10.5) compared to Tiger (10.4).

 

[LaPorta]

I will double check my info regarding the resource forks. I’d be more than happy to be proven wrong on this.