Mac Geekery

Answer

Forked files frequently fared fowl in file operations for a few reasons, the first of which is that only the Macintosh ever really utilized them.

Forked files were the 1980s answer to the same question that spawned packages in Mac OS X: How can we keep an application and its support data together so it doesn’t require an installation? If you’ve ever used a PC (or a bad port of a PC program) then you’ll notice that they often have the main application and then about a dozen support files and folders that eventually get spewed all over the disk. That’s not only ugly and bad design, but hell to troubleshoot and uninstall.

By forking a file into a data fork and a resource fork, the hope was to put the program in the data fork of the file and all of the graphics, dialogs, translation tables, controls and other snippets into the resource fork so that it could look like one file to the user but have the content of several dozen files. It worked well for many years and was a “feature” of the Macintosh concept at the development level.

Yet, when NeXT bought Apple (go on, tell me different) the idea of forks in files was anathema to the Unix geeks that reinhabited the offices on 1 Infinite Loop. Instead, the idea was to use the NeXTism of packages. That is, don’t try and force a whole set of files to be serialized into one binary store of a forked file, but, instead, leave the files be and just tell the OS to hide them. Works great, don’t you think? You’d never know about it unless you read up on Mac OS X (which most have, that read here).

So, that’s the current answer, but with Classic and Carbon programs, forks are still relevant. Some programs stored metadata about the files in the fork, like previews, annotations, version information, or indexes. Some programs, like Ambrosia’s Escape Velocity Nova, still, to this day, have plugins written as special resources in a file. For these files, the loss of the resource fork is lost data. If you just copy or move the data fork of a Photoshop file, you’ll lose some metadata, but nothing important. If you copy the data fork of an EVN plugin, you’ll get a zero-byte file.

Does it matter when backing up your system? It can, but it’s hard to say. Most of Mac OS X proper (if not all) uses single-fork files in packages. Most Apple apps are the same way. A lot of old Carbon apps ported just enough to work in Mac OS X may still work with files in the old way — it’s really hard to say which.

The good part is that in Tiger all of the shell utilities use a custom Apple function to copy and move files instead that preserves forks, permissions, and ACLs in a copy/move. It’s hard to lose that information in Tiger, unless you use tar to bundle something up.

When in doubt, transport it via a disk image or Finder archive.