ISO sample code to create an HFS filesystem or disk image

[NJRoadfan]

System 6 should support CD-ROMs. There are likely volume flags (aka, a hack or two) in place that explicitly tell the OS that anything mounted from that device is read-only.

 

[cheesestraws]

do CDs essentially not work under System 6?

Yes - there was an extension called "Desktop Manager" or something that was distributed to fix exactly the behaviour you noticed here.

 

[LaPorta]

I did run into one issue where I could use a sanity check: do CDs essentially not work under System 6? If I mount the HFS filesystem from an ISO as a writable volume, System 6 complains the disk is "so full that the desktop file can't be created", then prompts me to make minor repairs, then complains about the desktop file again in an endless loop. Or if I mount the filesystem as a read-only volume, System 6 complains that I need to unlock the disk so that it can create the desktop file, and when I dismiss the dialog it immediately reappears. So either way, it can't be used. The only exception I've found is Myst, which doesn't trigger this error, but every other ISO and TOAST file seems to have this problem. Under System 7 it works fine.

The issue may be related to the desktop file under System 7 and 6 being different. Being read-only volumes, the System likely cannot create a new desktop file and cannot access the System 7 ones, so it gets stuck.

Somewhat related: if they are mounted as true CDs, do you need the “ISO file access” extensions and all of that nonsense? That I don’t know about.

 

[cheesestraws]

I think this is it - try this. https://macintoshgarden.org/apps/desktop-mgr-201

 

[LaPorta]

I think this is it - try this. https://macintoshgarden.org/apps/desktop-mgr-201

There you go: it allows System 6 to use System 7 desktop files.

 

[bigmessowires]

Awesome! I will try that extension.

if they are mounted as true CDs, do you need the “ISO file access” extensions and all of that nonsense?

They're mounted as read-only HD20-type hard disks that contain the HFS filesystem from the CD. No CD-specific extensions are required.

 

[cheesestraws]

There you go: it allows System 6 to use System 7 desktop files.

Yup! Also very useful in general if you're swapping between Systems 6 and 7.

 

[LaPorta]

Yup! Also very useful in general if you're swapping between Systems 6 and 7.

I need that on my SE!

 

[LaPorta]

Awesome! I will try that extension.


They're mounted as read-only HD20-type hard disks that contain the HFS filesystem from the CD. No CD-specific extensions are required.

Nice! Will this work on existing hardware, or do we need to buy a new floppy emu?

 

[bigmessowires]

That Desktop Manager extension was exactly what I needed, it works perfectly. Thanks!

The Floppy Emu ISO and SCSI image support works on existing Floppy Emu hardware - it's purely a firmware improvement. I'll release it soon, hopefully along with the auto-encapsulation of StuffIt files into HFS images, and some UI clean-up.

 

[bigmessowires]

Hmm, this issue with CDs and the desktop file will be a problem for auto-generated HFS disk images of StuffIt files too. I'd intended for the auto-generated images to be ephemeral and synthesized on the fly as needed, which would mean they'll be read-only. But if System 6 insists on having a desktop file on a disk before it will mount it, that's probably not going to work. Either the auto-generated HFS image needs to already include a desktop file in System 6 format, or the image needs to be writable so that System 6 can create a desktop file. I'm not sure what System 7 does if it encounters a locked disk that doesn't have a desktop file in System 7 format - will it still mount it?

 

[eharmon]

Hmm, this issue with CDs and the desktop file will be a problem for auto-generated HFS disk images of StuffIt files too. I'd intended for the auto-generated images to be ephemeral and synthesized on the fly as needed, which would mean they'll be read-only. But if System 6 insists on having a desktop file on a disk before it will mount it, that's probably not going to work. Either the auto-generated HFS image needs to already include a desktop file in System 6 format, or the image needs to be writable so that System 6 can create a desktop file. I'm not sure what System 7 does if it encounters a locked disk that doesn't have a desktop file in System 7 format - will it still mount it?

IIRC, formatting HFS in the OS always creates a desktop file automatically, which is why it's expected to be there.

But that should work fine? If you start with a dummy empty image, just make sure that includes a System 6-style desktop file to keep the OS happy. As in, format it in System 6, then pull it back to a modern computer to prepare it for fiddling the stuffits in. Worst case the stuffit file is missing an icon, but it should still work properly I think.

 

[bigmessowires]

As long as System 7 doesn't balk at finding a System 6 desktop file on a locked disk, that should be fine. I did some quick experiments formatting a disk under System 7, then locking it and mounting it under System 6, and also tried the reverse, and didn't get any errors in either direction.

After spending many hours in the guts of HFS and examining some disk images, I can also see opportunities for tweaking the default floppy disk image to allow for greater storage space when there's only a single file on the disk. If I'm reading this right, a standard-formatted 800K floppy will have:

1KB for boot blocks
1KB for master block record and volume bitmap
6KB reserved for the catalog file
6KB reserved for the extents overflow file
1KB for a redundant copy of the MBR plus the last sector is never used

For a 1.44MB disk, the default catalog and extents overflow files are even bigger, at 11KB each.

I think we'd only need 1KB or 1.5KB for the catalog file, and 1KB for the extents overflow file, so that's about 10KB of potential savings on an 800KB disk or 20KB savings on a 1.44MB disk. Possibly an extra 1KB if the areas for redundant MBR and the last sector can be repurposed. It's not a lot, but if it proves to be the difference between a file fitting on a floppy or not, it would be worth it.

EDIT: I also found that the Desktop file on an empty floppy is only 321 bytes but occupies 6.5KB due to something called clumping which is intended to help reduce fragmentation. I think this could be adjusted too.

In the end there's only 778.5KB available for storing user files on an 800KB floppy with the default format, but I think it could be increased to about 794KB.

 

[eharmon]

As long as System 7 doesn't balk at finding a System 6 desktop file on a locked disk, that should be fine. I did some quick experiments formatting a disk under System 7, then locking it and mounting it under System 6, and also tried the reverse, and didn't get any errors in either direction.

After spending many hours in the guts of HFS and examining some disk images, I can also see opportunities for tweaking the default floppy disk image to allow for greater storage space when there's only a single file on the disk. If I'm reading this right, a standard-formatted 800K floppy will have:

1KB for boot blocks
1KB for master block record and volume bitmap
6KB reserved for the catalog file
6KB reserved for the extents overflow file
1KB for a redundant copy of the MBR plus the last sector is never used

For a 1.44MB disk, the default catalog and extents overflow files are even bigger, at 11KB each.

I think we'd only need 1KB or 1.5KB for the catalog file, and 1KB for the extents overflow file, so that's about 10KB of potential savings on an 800KB disk or 20KB savings on a 1.44MB disk. Possibly an extra 1KB if the areas for redundant MBR and the last sector can be repurposed. It's not a lot, but if it proves to be the difference between a file fitting on a floppy or not, it would be worth it.

EDIT: I also found that the Desktop file on an empty floppy is only 321 bytes but occupies 6.5KB due to something called clumping which is intended to help reduce fragmentation. I think this could be adjusted too.

In the end there's only 778.5KB available for storing user files on an 800KB floppy with the default format, but I think it could be increased to about 794KB.

Ah very interesting. I suppose it makes sense even System 7 will format (and create a desktop file for) a floppy in a way that's System 6 compatible, since it's expected to transport that between machines. I agree with your logic, it should be possible to shrink those (at the cost of storing fewer files with fewer extents -- irrelevant here) for some more savings.

One thing I've wondered...given a 2.88MB floppy is still MFM...can a SWIM actually cope with a floppy that presents with that many sectors? That might buy you more space but I'm not sure anyone has ever tried.

 

[bigmessowires]

Does anyone see a problem if I generate 400K HFS disk images with this? As far as I know, 400K disks are always formatted MFS by the Finder, but there's nothing stopping me from making a 400K HFS disk. My reason is that the disk should be no larger than needed to contain the StuffIt file, to give it a chance to work on the largest number of computers and drives, but I don't want to duplicate all my HFS research and code for MFS. Alternatively I could choose 800K HFS as the smallest size that this will generate, and owners of Macs with 400K drives just won't be able to use the feature.

 

[cheesestraws]

400K HFS should work fine on anything with HFS support.

 

[bigmessowires]

With a 400K HFS image, I've found that Disk First Aid 7.0 complains "this is not an HFS disk", even though it certainly is an HFS disk and it seems work fine otherwise. Hopefully there aren't any other lurking bugs like that in the system software.

 

[bigmessowires]

With a 400K HFS image, I've found that Disk First Aid 7.0 complains "this is not an HFS disk", even though it certainly is an HFS disk and it seems work fine otherwise.

Scratch that, this was due to an unrelated problem with my disk image. 400K HFS works just fine.

 

[bigmessowires]

What are the normal Creator ID and Type ID for common files that might need to be encapsulated in an HFS disk image? I'd like to encode some simple rules to set the creator and type ID based on the filename extension. For StuffIt I think there are several different ones depending on the StuffIt versions, but I'm not sure whether it matters. I hope that StuffIt is smart enough to open a StuffIt 5.5 archive even if it has a StuffIt 1.5.1 creator/type, or a completely incorrect creator/type. But having a good guess at the creator/type will make it more likely to work by simply double-clicking on the file.

But for StuffIt, there are multiple creator IDs too. SITx and SIT! are both used, and maybe others. Perhaps one is StuffIt Expander and the other is StuffIt itself, but I'm not sure which one is best to use.

Is there a standard type/creator for MacBinary and BinHex files?

Some relevant references are here: https://www.macdisk.com/macsigen.php

I'm hoping to make something like this, for common file types that are data-only with no resource fork:

Extension	Creator	Type
.sit	SITx/SIT!	SITD/SIT!
.hqx	SITx	TEXT
.bin	SITx/BNHQ	BINA
.cpt	CPCT	PACT
.txt	ttxt	TEXT
default	????	????

 

[NJRoadfan]

Here is what netatalk uses for translation: https://github.com/Netatalk/netatalk/blob/branch-netatalk-2-3/config/AppleVolumes.system

It assigns type SIT! and creator SITx to Stuff-IT! and MacBinary files. I'm not putting much faith in that MacDisk list. I would see what actual archives created by various versions tag the files as.