“Resource forks are so 1990s.”
That may be, but it’s funny how they stick around in OS X, hanging on to data files like dryer lint.
I’ve been cleaning up a project archive so that I can move it into svn instead of doing ad hoc, zip-the-entire-folder style backups. The trick is that many of the files aren’t plain text files: there are Photoshop source images, AppleScripts, REALbasic project files… all kinds of stuff.
svn can handle text and binary files just fine, but it doesn’t pay any attention to resource forks. That’s the main reason I haven’t moved the archive over sooner.
But in OS X, resource forks are a deprecated technology, right? How pervasive can these things still be?
The first step is to figure out which files have resource forks and which don’t. That by itself is not too difficult, and afterwards my little resource fork browser tool tells me that over 100 of 252 files in my archive have resource forks.
Now comes the tricky part. I’d like to just sic the Grim Ripper on all these files and remove their resource forks entirely. But not all resources are created equal. Some applications use resources to attach useful but fundamentally unessential metadata to files. Such files can be shoved into svn without concern.
Other applications store essential information in resources. These files need to be safely converted — to .zip, .r, or .bin formats, for example — before adding to svn.
Looking more closely at the files with resource forks, they break down like this:
Let’s take a closer look, shall we?
povray source files have custom ‘POVR’ resources (ID 1000, 3000, and 3001). 1000 and 3001 store window position data and are safe to delete. 3000 is trickier: this stores any custom render settings for the file. In general this is safe to delete, although you may want to store information about preferred render settings within the text file itself for safety.
povray-generated PICT files have a single ‘icns’ resource (-16455). This is just a custom icon for the file that the Finder can display in file lists. Safe to remove.
Similarly, Photoshop likes to dump a pile of resources into the files it saves so that the Finder can preview the file for you. These resources, which include the ‘icns’ resource above, a ‘STR ’ resource, a ‘PICT’ preview, and lots of ‘8BIM’ resources, can all be safely stripped. Note that if you use Photoshop’s export to web command, you’ll get a file with no resources. But if you use Save or Save As, they tag along.
BBEdit, along with some other text editors, likes to attach ‘MPSR’ resources that contain information about the editing session (font information and window position). I’m also noticing some empty ‘CSta’ resources (ID 128) — I don’t know what these are for, and we’re talking about text files, for Pete’s sake. These resources are not necessary.
AppleScript gets trickier. AppleScript applications have vital resources. For use with a version control system, it’s better to track the source script file and assume we can rebuild the application as needed. AppleScript .scpt files also have resources. ‘WPos’ and ‘DPos’ ID 128 look like window position information and can be removed. However, note that if you use the Description field, Script Editor stores your description in a styled text resource pair: ‘TEXT’ and ‘styl’ ID 1128. In some cases this may be critical information. My suggestion is to stop using this field and simply add your description to the top of your script as a comment.
OmniGraffle uses ‘icns’ for Finder previewing. Safe to remove.
Icon files are collections of icon resources at various sizes. These are critical elements, but you can use .icns files instead of resource files to store the same information in the data fork. Iconographer is useful for this.
ResEdit files are, fundamentally, collections of resources, so by definition we can’t strip these resources out. These files are usually used in development environments and added to built applications to meet a variety of needs. Fortunately, in modern OS X development, you can get away with using packages to provide much of what used to be done using resources. In XCode or CodeWarrior, you can avoid having to use ResEdit-style files by using .r files or data-fork based .rsrc resource files. For REALbasic, there is little need to add resources to a project, with the exception of ‘CURS’ resources to support various cursor appearances.
So at the end of the day, most of these resources can be ignored. A few, like POVR 3000 and AppleScript’s TEXT/style resources, may contain important information, but you can store the same information within the file itself, as long as you’re aware of the need to do so.
For the rare few critical resources, DeRezzing them seems the best option for svn management. Just remember to update the derezzed version when you modify the source! (A preflight script that checks compares modification dates might be a good idea.)
It is remarkable that six years into OS X, nearly half of the files in this archive have resource data attached to them. Most of this data seems to fall into one of two purposes: Finder preview information, or “last known state” information that can’t be added to the file itself because the file is in a shared format (e.g. plain text, JPEG). These aren’t critical uses, but the continued pervasiveness of resource forks makes me wonder whether Apple’s going to be able to completely kill them off. In 2012, I expect resource forks will still be hanging on.
Only one comment:I've been looking like forever for and OS X app to delete resouce forks. Yes, I used Google, but it wasn't until I stumbled on this page that I found out about the Grim Ripper CM. Thank you so much! There are many ways to do it in OS 9 (my favorite was FinderPop), but this is the first time I've seen something for OS X.
John Haynes () - 16 June '07 - 10:42