Print

[alphaTECH]

I ripped over a hundred software discs in OS 9 and compressed them with StuffIt. I removed the .sit extension from each archive and the file still remained associated with StuffIt for decompression. I moved all of the archives to my NAS, and still the association remained. Months later, I had a major issue with NAS and the volume needed to be rebuilt. All of the file associations were then lost on my archives, which would ask for a program to use the file with if executed.

I ripped a few more discs recently with the same procedure and, as before, they have retained their association with StuffIt without the .sit extension. Today I used a bulk renaming utility to add .sit to all of the archives' file names, watched the associations populate, then removed the .sit extensions using the same utility, at which point all the associations except for my recently created archives were lost again (see attached picture).

I'm a bit confused by this. How is OS 9 and OS X keeping associations without a file extension until the file system is messed around with by Windows or Linux? And how do I restore the persistent associations in the event that they're lost?

[davecom]

Under the classic Mac OS, files had two forks—data and resource. Most file systems do not have this concept. When you transfer classic Mac OS files to Windows or Linux based systems they lose their resource forks unless you specially encode them for transfer (MacBinary, Stuffit, etc.). Anyway, in the resource fork are resources known as type and creator codes. These specify the file's type and the program that created it. That is how the classic Mac OS associates files with programs.

You can edit these resources using something like ResEdit. There are also utilities for the classic Mac OS made specifically for changing just these two resources.

[alphaTECH]

Under the classic Mac OS, files had two forks—data and resource. Most file systems do not have this concept. When you transfer classic Mac OS files to Windows or Linux based systems they lose their resource forks unless you specially encode them for transfer (MacBinary, Stuffit, etc.). Anyway, in the resource fork are resources known as type and creator codes. These specify the file's type and the program that created it. That is how the classic Mac OS associates files with programs.

You can edit these resources using something like ResEdit. There are also utilities for the classic Mac OS made specifically for changing just these two resources.

Thanks Dave, that makes sense, although the resource forks do actually seem to stick around when the archives are transferred to my NAS (which natively runs Linux, as most do). The screenshot I took is of the folder on my NAS which has all of my archives in it.

I wonder if ResEdit can work on files in bulk...

[Bolkonskij]

Unix does its associations via file suffixes and expects that from any file. So if you transfer a file from classic Mac OS to a Unix server, the resource fork gets lost on the way. (try to transfer a file from OS 9 to your NAS or e.g. a web server via FTP. Then immediately copy it back to your OS 9 install to see live how it gets lost during the transfer process)

A utility like FileTyper can be used to inspect and to change the type/creator code of any file on Mac OS. Files with a lost resource fork usually show up as "?? ??" in there. There’s also programs who do en masse changes, like BunchTyper (never used it personally yet, can’t vouch for it - proceed with caution)

That said, there are systems who support Mac OS resource forks. Hotline comes to mind. (question: Does anyone among us use a Hotline instance for backup?)
You could also use a HFS+ formatted external drive for backing up OS 9 files unencoded. (I've got an external LaCie Firewire HDD specifically for that)

Otherwise, you’ll need to protect your files before transfer as davecom suggested. Encode them with something like StuffIt or Mar to keep everything together, only then transfer the archive to your (Linux driven) NAS. The disadvantage is that you'll have to unpack it every time you retrieve the file. Also beware that using OS X inbuilt zip functionality to back up Mac OS files also loses the resource fork.

[alphaTECH]

Unix does its associations via file suffixes and expects that from any file. So if you transfer a file from classic Mac OS to a Unix server, the resource fork gets lost on the way. (try to transfer a file from OS 9 to your NAS or e.g. a web server via FTP. Then immediately copy it back to your OS 9 install to see live how it gets lost during the transfer process)

A utility like FileTyper can be used to inspect and to change the type/creator code of any file on Mac OS. Files with a lost resource fork usually show up as "?? ??" in there. There’s also programs who do en masse changes, like BunchTyper (never used it personally yet, can’t vouch for it - proceed with caution)

That said, there are systems who support Mac OS resource forks. Hotline comes to mind. (question: Does anyone among us use a Hotline instance for backup?)
You could also use a HFS+ formatted external drive for backing up OS 9 files unencoded. (I've got an external LaCie Firewire HDD specifically for that)

Otherwise, you’ll need to protect your files before transfer as davecom suggested. Encode them with something like StuffIt or Mar to keep everything together, only then transfer the archive to your (Linux driven) NAS. The disadvantage is that you'll have to unpack it every time you retrieve the file. Also beware that using OS X inbuilt zip functionality to back up Mac OS files also loses the resource fork.

Thanks for the explanation, looks like my NAS does support resource forks then. I can copy an archive back and forth without losing the association.

I'll try restoring the other ones with the apps you mentioned. Cheers for the heads up.

[Bolkonskij]

Good luck in your restoration process!

(are you transfering your files via AFP perhaps?)

[alphaTECH]

Good luck in your restoration process!

(are you transfering your files via AFP perhaps?)

I am, amazing that it's still supported these days honestly.

[IIO]

in MacOS9 it is relatively easy to explain.

when a file was created in OS9, it has a resource fork (including what i believe is correct to call "info fork") where its type/creator code is stored.

that code can by empty, a general paceholder type of code, or unambiguously give information about the app it was created with and which type of file it is, like stCA/AIFC (cubase, aiff audio) or SIT5/SIT! (stuffit archive.)

the codes must be 4 character long, spaces are allowed, all-minorcase codes are reserved for apple inc.

four spaces means no code, ? ? ? ? means "prompt the user if possible", if the code is ABCD but there is no app which can  open ABCD nothing will happen on launch.

most applications in OS9 otoh have a BNDL resource in their resourcefork, where they announce their signature (the creator code) and what types of files they are asking to be associated with, and then usually both a type code - and an icon - is present.

whenever an app is opened for the first time OS9 will be told and remember this info (in one of these invisble "desktop" files which sometimes do not update properly) and that info is fetched from there whenever a document is opened by doubleclick, by command-downarrow (or by applescript or via apple events)

there are only a few excpetions which outrule that creator code stuff which can be found in the files and apps themselves, when i am not wrong this is limited to the internet controlpanel and quicktime settings.
 
 
in OSX it is more complicated. it "understands" and uses type creator codes sometimes, but it also has two other methods, of which one of them are these "com.manufacturer.whatever" textfiles (i never understood this shit).

so in OSX it happens far more often that files show weird icons from wrong apps or ask for the program to be opened with despite of having the correct T/C info "built-in".

for example when i have a carbon audio plug-in in OSX which has a steinberg signature it will still open with spark because that audio host program has a newer date than cubase.

at the same time in OSX and windows this is a lesser problem becuse they are very good in interprerting what type of file it could be and offer you a list of programs which possibly can open it.

if a MacOS file´s info survive storage on foreign operating systems, file systems and/or a transfer over the net depends on these OSes, harddisk file systems or file transfer programs.

for example many linux servers will detect the MIME type of an AIFF file, and then you FTP client gets that info and might deliberately add creator:quicktime filetype: AIFF to the file.
 
 
filename extensions mean absolutely nothing on MacOS9. except for your eyes.

the majority of applications has content in the resourceforks (i.e. beside the info stuff, which is easy to redo), the majority of documents to not make use of that. so your programs in that screenshot are lost, your documents or stuffed programs are not.

making disc images to transfer files around is much faster than using compression.

[joevt]

If you look at a file in Mac OS X, you see there are two extended attributes.

Code: [Select]

ls -l@ AppGap
-rwxr-xr-x@ 1 joevt  staff  0 16 Sep 09:50 AppGap
com.apple.FinderInfo 32
com.apple.ResourceFork 3033
FinderInfo contains creator and type codes and Finder flags. ResourceFork contains resources.

These extended attributes exist in HFS, HFS+, and APFS. For other file systems, they might get stored in invisible folders and files. See https://en.wikipedia.org/wiki/AppleSingle_and_AppleDouble_formats

Sheepshaver creates a .finf folder to store finder info for host files even if the host supports extended attributes (such as a macOS host).

MacBinary is a container type for storing finder info and both forks of an Apple file.

Stuffit and Compact Pro include finder info and both forks in their compression format. Same for Zip in Mac OS X (might use Apple Double?).

[IIO]

yeah, bin and hqx are also very fast and elegant solutions indeed.

but what i like about images is that you open them everywhere to look inside (yet not successfully copy to HD)