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:

• povray source files (.pov)
• povray-generated PICT images (.pict)
• Photoshop source files (.psd)
• Photoshop-exported image files (.pct, .gif, .jpg, .bmp)
• BBEdit-edited text files (.py, .txt, etc.)
• AppleScripts (.scpt)
• AppleScript applications
• OmniGraffle files (.graffle)
• Icon files
• ResEdit files

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.

We’ve had this problem under control for several months using a technique called HashCash. We also format all links in comments with the rel=’nofollow’ attribute, which prevents Google from using the link in its PageRank calculations. (Yet spambots still visit us. Go figure.)

Recently, some spambots has broken HashCash. So, we’ve added a new layer of shiny anti-spambot coating: the Obvious Question. If you’re leaving a comment (please do!), before you submit the comment form you’ll need to answer an Obvious Question. The answer is even provided, in case what’s obvious to us isn’t obvious to you.

In general, we hate the idea of inconveniencing real contributors in order to better manage spam. But the ratio of spambot postings to real postings is running well over 1:1. The Obvious Question attempts to solve the problem in the least intrusive way.

It turns out the problem is that when you use AppleScript to execute commands via Terminal, the last command you perform via the “do script” AppleScript command can get “stuck” in Terminal’s ExecutionString preference, which is run whenever a Terminal window opens. (Fortunately for me, the command that got stuck was a simple cd command.) There is no interface in Terminal to view or edit ExecutionString, which makes the bug a bit tricky to track down. (Huzzah for Google, as usual.) To fix it, you need to either edit com.apple.Terminal.plist manually, or execute the following command in a Terminal window:

defaults write com.apple.terminal ExecutionString ’’

The ideas and examples here aren’t just applicable to commercial API designers. Every codebase is essentially an API that someone is going to have to learn (or, if you’re returning to your own code, relearn). The ideas strike me as being a level above quibbling about things like the merits of Hungarian Notation, and more in the pragmatic programming realm.

Here’s the thing, though. The move to Intel was spun as being about performance per watt. G5s were too hot to get into a Powerbook, they said, which is certainly true.

So what’s the performance per watt like in the new MacBook Pro? We have no idea, because there is absolutely no information available about battery life. That seems to be a conspicuous omission.