ISO sample code to create an HFS filesystem or disk image
- Thread starter bigmessowires
- Start date
cheesestraws
Well-known member
Yes - there was an extension called "Desktop Manager" or something that was distributed to fix exactly the behaviour you noticed here.
LaPorta
Well-known member
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
Well-known member
I think this is it - try this. https://macintoshgarden.org/apps/desktop-mgr-201
LaPorta
Well-known member
There you go: it allows System 6 to use System 7 desktop files.
bigmessowires
Well-known member
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.
cheesestraws
Well-known member
Yup! Also very useful in general if you're swapping between Systems 6 and 7.
LaPorta
Well-known member
I need that on my SE!
LaPorta
Well-known member
Nice! Will this work on existing hardware, or do we need to buy a new floppy emu?
bigmessowires
Well-known member
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.
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
Well-known member
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
Well-known member
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
Well-known member
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.
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.
Last edited:
eharmon
Well-known member
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.
Last edited:
bigmessowires
Well-known member
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
Well-known member
400K HFS should work fine on anything with HFS support.
bigmessowires
Well-known member
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
Well-known member
Scratch that, this was due to an unrelated problem with my disk image. 400K HFS works just fine.
bigmessowires
Well-known member
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:
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 | ???? | ???? |
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.
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.
Similar threads
