Zip files "uploaded" to the host computer don't expand resource forks properly?

[simX]

I'm not sure if this is actually a bug or not with Infinite Mac. I'm using the System 7.5.3 emulator. It seems in at least one case, I'm trying to "upload" a file to The Outside World (which saves it to the host computer), and on macOS, the resulting zip file does not expand resource forks as I would expect. Steps to reproduce:

1. Launch the System 7.5.3 emulator on Infinite Mac: https://infinitemac.org/1996/System%207.5.3
2. Click the "Macintosh Garden" tab and search for "Dinopark Tycoon". Click "dinopark-tycoon-01.sit" to load it into the "Downloads" folder of "The Outside World", then double-click it to Unstuff it.
3. Launch DinoPark Tycoon and play a game. Create a save file and save it somewhere.
4. Drag your DinoPark Tycoon saved game file to the "Uploads" folder of "The Outside World". Shortly, a zip file should start saving to your host Mac.
5. On macOS Sonoma, 14.7.1 (23H222), double click the .zip file to uncompress it. Note that this creates a zero-length file, with no resource fork at the sub-path ../namedfork/rsrc
6. Open the .zip file from Step 4 with a zip file inspector application (Pacifist is a good option). Note that the zip file does actually contain what seems to be a resource fork inside the ".rsrc" folder in the zip file. However, the native macOS Compression Utility does not seem to recognize this or properly uncompress it.
7. Back on Infinite Mac, install Stuffit Deluxe 4.5 from Macintosh Garden ("STUFFITDLX45.SIT"), then compress the DinoPark Tycoon saved file with Stuffit Deluxe first, then copy it to the "Uploads" folder. When you uncompress with the native macOS Compression Utility on the host Mac, and then uncompress the .sit file with "The Unarchiver" (https://macpaw.com/the-unarchiver), the resource fork is kept intact in the saved game file on the modern Mac. You can use cat /Users/dino/DinoPark Saved File/..namedfork/rsrc to view the resource fork correctly in the Terminal.

Again, not sure if this is actually a bug.

Possible resolutions:

1. Ideally, the .zip files generated when saving a file to the host computer should be natively understood by modern macOS's Compression Utility.

2. The sticky that mentions how to upload files to the host computer doesn't mention any special handling for files with resource forks from the emulated Mac. Maybe all that's needed is a note here saying to preserve the .zip file, rather than expanding it and preserving that file. I can see a (possibly rare) instance where someone uncompresses the .zip file and then saves that somewhere, deleting the .zip file and expecting the expanded file to preserve all the data. Not sure how common this scenario might be.

[mihaip]

This is somewhat intentional, the .zip files that Infinite Mac generates are my own creation (based on the directory structure that Basilisk II and SheepShaver use to support resource fork and creator/type metadata on foreign file systems, via parallel .rsrc and .finf directories). That being said, it's a good idea to instead use the approach that modern macOS uses for .zips (via a __MACOSX directory - I added support for importing those zips in 41c6023eee5473558b508c2c1d6efd052776c6a2), so that they're more interoperable. I'll look into this, but no promises of when it could happen.

In the meantime, if you're looking to do a fully fidelity export from Infinite Mac, you may want to look into creating a disk image in the emulated Mac and exporting that via The Outside World (they should not need any resource forks).

[simX]

I did try to make a disk image via DiskCopy, but the resulting .img file could not be opened on macOS Sonoma. I was under the impression that modern macOS was able to mount really old disk images, but it didn't seem to be able to do so. Do I need to use a specific format/size, or is there a better utility to use to create disk images instead?

[MaddTheSane]

You might need to migrate the .img to a .dmg. Also, newer macOSes dropped support for standard HFS. You'd need to format the disk image as HFS+ (Mac OS Extended).

[simX]

This brings the question as to what you would actually want to do with such an old disk image in a modern macOS environment? Nothing will launch or open in there. Hope that helps.

Not sure why any of this comment was necessary, as it should be pretty clear why I was using a disk image: it was recommended by mihaip as another possible way to get data from the emulated Mac to the host Mac while preserving resource forks. It was a good suggestion but still requires intermediate steps to access the data on the modern Mac (as MaddTheSane already pointed out), so using StuffIt instead seems to be a better option for now.

mihaip: Glad to hear you're looking into this issue, thanks! No worries about the timetable, Infinite Mac is really useful already!

[that-ben]

Not sure why any of this comment was necessary

No problem, so sorry about that. I thought it would be useful. I removed my useless comment.

[mihaip]

@simX took a stab at implementing this. .zip files generated by the "Uploads" folder now match what modern macOS expects (a parallel __MACOSX folder structure with the resource forks and metadata in an AppleDouble file). Using ResForge on the native side shows that resource forks in saved games are preserved: