Feature request: Utility to retrieve legacy Mac OS’ type & creator codes

[elmimmo]

The utils at extended-attributes-and-tags do not seem to be able to extract legacy Mac OS’ type & creator code of a file, and it would be useful if one could locally.

macOS stores legacy type & creator code inside the extended attribte com.apple.FinderInfo and one can specifically query them with /usr/bin/GetFileInfo -t <file> and /usr/bin/GetFileInfo -c <file> respectively.

DSM seems to store them inside @SynoResource files.

[hwdbk]

I think the use of the FourCC Mac OS file type and Creator code have been deprecated a long time ago. For instance, if I create a brandnew file "untitled text.txt" with BBEdit, I get:

$ /usr/bin/GetFileInfo -t untitled\ text.txt 
"\0\0\0\0"
$ /usr/bin/GetFileInfo -c untitled\ text.txt 
"\0\0\0\0"

i.e. null values, where I had expected "TEXT" and "BBEd" (I think). I sampled also a lot of files from my local mac and I find primarily "\0\0\0\0" and " " (4 spaces), but very litte true FourCCs, and if, only from very old files.
Originally, the label colour was also stored in the FileInfo, but these are now made explicit in xattr and now supports multiple labels on a file instead of just one, and hence the toolset.

So, let's explore this:

(on a synology NAS): $ xxd -ps file.txt\@SynoResource | tr -d '\n'
00051607000200004e65746174616c6b202020202020202000020000000900000032000000200000000200000052000000005445585421526368000c00000000000000000000000000000000000000000000

where the
54455854 21526368
are the FourCCs you're interested in ('TEXT!Rch', to be precise). Then, extract the hex sequences:

hex=$(xxd -p file.txt\@SynoResource | tr -d '\n') ; xxd -r -p <<< ${hex:100:8}

will give you TEXT, and

hex=$(xxd -p file.txt\@SynoResource | tr -d '\n') ; xxd -r -p <<< ${hex:108:8}

will give you !Rch

The only thing this snippet doesn't do is convert non-printable characters (like 0x00) to something readable (like \0).

[elmimmo]

Awesome! Type and Creator codes are indeed ancient, and I happen to have archived plenty of files from decades ago, with no file extension as was the practice on classic Mac OS, so I wanted to document that by extracting those codes. And it works as you described. Thanks!

[hwdbk]

Ah, yes, that is a very valid use case! - and with the information add the proper file extension to the file name so the file type becomes explicit and visible from the file's full name. Hopefully, the files are still supported by today's software. I have found many (very, really) old files whose data was saved in the Resource Fork at the time, and somewhere along the way got lost. These files would have the creator and file type, but are (and were always) zero bytes long in the Data Fork (but relax, there wouldn't be code around to do something useful with these files anyway). For other files (Framemaker pops to mind, as an example), the file data does exist in the Data Fork, but, again, there is no code around to do something with it. I hope for you these were TEXT files, because these will still be readable (mind the MacRoman character set, though :-). Good luck.

[elmimmo]

These files would have the creator and file type, but are (and were always) zero bytes long in the Data Fork (but relax, there wouldn't be code around to do something useful with these files anyway)

Well, in the case of legacy Mac fonts, that’s actually how it’s supposed to be! (i.e. empty Data Fork, everything in the Resource Fork). DSM’s SMB server, when accessed from a Mac, abstracts however DSM stores the Resource Fork in @SynoResource so they are still accessible from Mac clients. Bulk converting those suitcase files (FFIL type code, hence why I went this rabbit hole in the first place) to Opentype so that the archive data remains somewhat usable is one of my intentions, and FontForge sees their Resource Fork data intact 👌

[elmimmo]

It ended up not being so straightforward. @SynoResource files seem to be in the AppleDouble format and, depending on the file, type and creator codes might be in their Finder Info block, their Resource Fork block or both, so simply targeting a specific character position will not always work.

Here are a couple of scripts (Bash and Python, the latter being MUCH faster so being the recommended one) to get legacy Mac OS file type and creator codes from files stored on a Synology NAS running DSM.

On another note, on macOS, /usr/bin/GetFileInfo, which I used in the issue’s description, seems to be deprecated and therefore eventually gone (as a matter of fact, macOS requires a download the first time one tries to run it). One can instead get type and creator codes with xattr -p com.apple.FinderInfo <file>, no download required.