A Little About Resource Forks

"Resource forks are deprecated anyway and they will sooner or later disappear alltogether." "Sorry, this is deprecated."

That's right. I've been deprecated. I will disappear sooner or later anyway, and well, I should just go die already. You see, I have files with resource forks on my various computers and hard drives. And when resource forks aren't supported in file transfer applications like Cyberduck, they get destroyed when transferring between computers. And when resource forks get destroyed, sometimes the whole file is rendered unusable. So I thought I'd put up a little reminder that when transferring or backing up files with resource forks, you need to take steps to preserve them.

First a little background. Resource forks are mostly a relic from the classic Mac OS, though they also exist in OS X, that stored data on a file apart from the data fork. So each file had two forks, only one of which (the data fork) would be recognized on non-Mac systems. On normal files like .txt's or .png's this wasn't a problem because whatever was in their resource forks (custom icons?) wasn't required to open them. But for applications, Disk Copy images, and font files, this was a big problem because their resource forks contained data necessary for their operation. So say if you moved a Mac application to a Windows hard drive and then back again, it wouldn't open because the resource fork was stripped in the process.

So don't move around Mac files on non-Mac file systems, right? It's not quite that simple. There are a few other dangers to be aware of. First, when networking files you must use AFP (Apple Filing Protocol) which is implemented by the Personal File Sharing option in your OS X preference pane and in OS 9's File Sharing control panel. For Linux systems you will need to install Netatalk and then access the network drives in Nautilus or PCManFM (Thunar chokes on AFP networks). The one other networking option is the SSH associated scp -E command where the -E option preserves resource forks, but both machines must be running Tiger or later so the practicality of that is limited.

Besides networking, there's also backing up to disc. When burning files with resource forks to a DVD or CD-R, they must be recorded on a Mac filesystem. Burning in OS X's Finder will accomplish this, making what's known as a Mac + PC hybrid disc that's readable on both Macs and PCs. If you're using another burning application like Burn, don't use the PC or iso9660 option. You must use either Mac (HFS+) or Mac + PC (FYI, Mac + PC hybrid discs will automount in Linux, but Mac-only discs will not).

If none of this is an option and you have to upload files on a non-AFP network or a non-Mac filesystem, you can still preserve resource forks by compressing the file(s) in a .sit container. There's also documentation that says tar can do this, but don't use .zip. The only zip application that handles resource forks is MacZip for Mac OS 9, and it must be used for both compressing and unpacking (OOPS: BOMArchiveHelper in Tiger can create zips that preserve resource forks, too. It's the app used when you right click on a file and choose "Create Archive of..." Just make sure to unzip them with the same app which is the default when double-clicking--Credit to ClassicHasClass).

rsync I'd have to look into. From what little I've read on this, it looks possible but messy.

Just to reiterate, you don't have to preserve resource forks on normal files like .jpg's or .mp3's unless you have something like custom icons you want to keep. Resource forks are only essential for OS 9 applications or fonts or Disk Copy images (and possibly Hypercard stacks?). And it's not wholly limited to OS 9. Certain OS X files like .webloc and .textClipping files store all their data in resource forks or extended attributes, too.