Jump to content

Creating HFS Images in macOS?


Recommended Posts

  • 68kMLA Supporter

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?

Link to post
Share on other sites

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.

Link to post
Share on other sites
  • 68kMLA Supporter

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.

Edited by PotatoFi
Link to post
Share on other sites

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...

Quote

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.

Link to post
Share on other sites

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.

Edited by LaPorta
Link to post
Share on other sites

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.

Link to post
Share on other sites
  • 68kMLA Supporter

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.

 

On 12/2/2018 at 1:05 AM, chu-oh said:

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. 

 

 

 

Link to post
Share on other sites
3 hours ago, Bolle said:

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?

Link to post
Share on other sites
  • 68kMLA Supporter

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?

Edited by PotatoFi
Link to post
Share on other sites

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?

Link to post
Share on other sites
On 12/15/2018 at 8:44 PM, PotatoFi said:

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?

Link to post
Share on other sites
9 hours ago, PotatoFi said:

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?

Link to post
Share on other sites
3 hours ago, LaPorta said:

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 */

Edited by nglevin
Just being thorough
Link to post
Share on other sites
  • 68kMLA Supporter

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.

Link to post
Share on other sites

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).

Edited by nglevin
Link to System7Today so I can be more helpful instead of being a shouty boy who is Right on the Internet
Link to post
Share on other sites

It seems that way back when I was given some incorrect information regarding this. I see now that the more modern network protocols are what may have issues with the resource forks (always knew via internet didn’t work without stuffing/binhexing). There it little to no way to get these files off these newer systems without disk images/hexing. That’s where I got confused.

Link to post
Share on other sites

You might also be thinking about creator codes, which are stored in the resource fork. There was a small flare up among Apple bloggers almost ten years ago around how those were being ignored in Snow Leopard; http://livecode.byu.edu/helps/file-creatorcodes.php . Took me awhile to remember this one.

 

It's a shame that small quality-of-life change got more negative press than the more unfortunate dumbing down of AppleTalk and dropping of HFS write support, also in Snow Leopard.

 

I was going to link to Cult of Mac here but the web ad density of that site has only gotten worse, somehow, and the editorial that first brought this up on TidBITS is kind of a meandering mess in the comments.

 

 

 Anyway, my apologies for the derail. My entire workflow for managing old Macs would be harder without resource fork support in Mojave. I was surprised by the stronger claims made in this thread that seemed contrary to what I can do. ;-)

Edited by nglevin
Link to post
Share on other sites
45 minutes ago, gpz500 said:

this is a port of Unix/Linux hfsutils package to macOS: https://formulae.brew.sh/formula/hfsutils

hfsutils works, but it doesn't mount a filesystem in to the normal filesystem space of the OS. It virtually mounts the HFS volume for use by its own tools. This is fine for occasional use or for automated use, but can be a little tedious since regular scripts need to be modified and you can't use it with Finder.

 

I use it to mount the Mac OS boot volume on my Quadra while it's running NetBSD :)

Link to post
Share on other sites
  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...