11

I'm trying to analyse the resource forks of classic Motorola 680x0 Mac files. All the documentation I can find says they start with 4 32-bit values: offset to data, offset to map, length of data, and length of map.

The offset to the data is always 0x100 on all the files I have. One doc stated this is usually the case, but I can't find that doc to link at the moment.

But the resource forks from classic Mac files I've inspected all have structured data in this region including 4-character codes similar those used for resources.

Here's an example that I'm analysing with Ghidra:
Ghidra screenshot

The files I have are compiler files for a classic mac "hello world" program in C. I believe one is the project file, one is the resource file, and one is the resulting compiled program. The screenshot is the compiled program. The others have similar but different structure in this region.

Could this be a copy of the 'FinderInfo', or part of it? I can't find it documented. Do we know what it is exactly?

Improve this question
1
  • 2
    Could have just been random junk left over in memory from other things, filling otherwise undefined space.
    – Jon Custer
    Commented Jul 15 at 18:08

2 Answers 2

Reset to default
10

Officially according to Apple, it is "reserved for system use". (Source: Apple Computer, 1985. Inside Macintosh volume I. Chapter 5: The Resource Manager.)

Figure 9: p. I-128

p. I-129

However, by 1993, Apple apparently allowed the Finder to use the space for "scavenging". I'm not sure exactly what they meant by this -- perhaps to recover a file system after a system crash. In any case, the format of such data was never made public, and they warn that "if you copy a resource file, the duplicate may not be exactly like the original." (Source: Apple Computer, 1993. Inside Macintosh: More Macintosh Toolbox. Chapter 1: The Resource Manager, p. 1-53]

More Macintosh Toolbox p. 1-53

It's not clear exactly when Apple started to use that block for "scavenging", but it certainly was not present on the first Macs, so you cannot rely on every file to have valid data there.

Improve this answer
2
  • 2
    Aha! Thanks. I got these files from a stuffit archive on GitHub. The only files with resource forks on Sonoma on my M1 Mac are Icon\r files in directories that have custom icons, and those have all zeros in this region.
    – hippietrail
    Commented Jul 16 at 4:48
  • 4
    I found this which doesn't shed a lot of light, though: This field is used by the Classic Mac OS Finder as temporary storage space. It usually contains parts of the file metadata (name, type/creator code, etc.). Any existing data in this field is ignored and overwritten.
    – tofro
    Commented Jul 16 at 5:52
7

On the Mac, the term "scavenging" is used for disk error recovery, e.g. fixing things left in a bad state after a sudden power loss. I've seen it applied to MFS/HFS.

Once upon a time, I wrote disk compression software for the Apple IIgs that uncompressed and decompressed data on the fly, for both forks of a file. Everything was working great until I took it to a friends' house, where we started seeing disk corruption issues. Forked files stored on his network server were getting mangled. The problem turned out to be that I was compressing the entire resource fork, and the AppleShare file server code was expecting to be able to modify the data at the very start. (The fix was to leave the first part of the resource fork uncompressed.)

Mac and IIgs resource forks are different, so I'm guessing the files being corrupted back in the day were stored in Mac format on the AppleShare server. The data in your hex dump looks like filename and filetype/creator, which is certainly something AppleShare might tuck away if it was worried about files being stored on a medium that lacked HFS-style file attributes.

So my guess is that you're seeing files that were stored on AppleShare at some point. I haven't found any AppleShare documentation that explains what it writes to resource fork headers, however, so I don't know exactly what's stored there.

Regarding an open question in your post, "Finder info" is two 16-byte pieces, one from the MFS-era Finder (FInfo), one added to the HFS-era Finder (FXInfo). Detailed information about both can be found in Inside Macintosh: Macintosh Toolbox Essentials, starting on page 7-47. The file type and creator are stored in the first 8 bytes of FInfo.

Improve this answer
1
  • Yes I know what FinderInfo is. I was wondering/hoping this area might somewhat reliably contain these fields but I think even when they are there they're not always in the same spot.
    – hippietrail
    Commented Jul 17 at 12:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .