Mac OS 9 Discussion > Software
How do file associations work in OS 9 and OS X?
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:
--- Quote from: davecom on September 16, 2024, 12:23:56 AM ---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.
--- End quote ---
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:
--- Quote from: Bolkonskij on September 16, 2024, 03:54:29 AM ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
Go to full version