When you double-click a document in the Finder, how does the system decide what application should open it? The relationship between a document and its owning application is called a preferred application binding. Since the very first day of the very first version of Mac OS X, there has been an uneasy detente between the Unix way of binding documents to applications and the former Mac way, inherited from the early days of the Mac OS. Now, in Snow Leopard, users and developers are complaining that the Unix way is being allowed to run roughshod over the Mac way.

The venerable Mac way of binding a document to an application is the creator code, a four-letter (actually integer) value, unique to an application, attached as metadata to a document. One advantage of this approach is that it lets applications share documents of a common type (itself expressed as another four-letter value, the type code). For example, looking on the Desktop of my Mac OS 9 machine, I see two ordinary plain text files (type code "TEXT"); one belongs to SimpleText (creator code "ttxt"), the other to BBEdit (creator code "R*ch").

Creator and type codes are invisible to the user; that's good because they're out of your way, but power users require a third-party utility to manage them. For a deep and fascinating historical discussion of this mechanism, see TidBITS publisher Adam Engst's interview with its inventor, Bruce Horn ("The Mac at 20: An Interview with Bruce Horn," 2004-01-26).

The Unix approach (or what I'm calling "Unix" for purposes of this article; its history actually goes back to DEC and DOS and is in fact merely optional in Unix) is to use file extensions, which are abbreviations following a period in a document's name.

Many users regard Mac OS X's implementation of file extensions as somewhat lame - they're ugly and incomprehensible; now you see them, now you don't; you can change them, but your hand gets slapped. Adam provided a brief but trenchant critique many years ago (see "Mac OS X 10.1: The Main Features," 2001-10-01). Still, they do have one great advantage: they are "just text," so they can be seen and changed.

(In early 2005 Apple introduced another way of specifying a file's type: the uniform type identifier, or UTI. It's invisible metadata, like a type code, but it's longer, it carries more information, and it can be part of a hierarchy. For example, a text file would typically be a "public.plain-text", which is a subclass of "public.text". File extensions are still with us, though.)

In the Unix way, a document's file extension just says what type it is; ownership of that type is another matter. An application bundle contains an important file called Info.plist that lets it "claim" ownership of certain file types. Mac OS X's Launch Services facility maintains a database of such claims, which it uses to determine the binding that operates when you double-click a document in the Finder.

In addition, you, the user, can customize a preferred application binding: the Finder's Get Info dialog lets you bind a particular file or extension to a specific application.

So, to sum up, a document can have at least three different aspects that associate it with an application:

1. The user might have employed the Finder's Get Info dialog to bind this document to an application.
2. The document's name might have an extension and/or UTI that is claimed by an application.
3. The document might be marked with an application's creator code.

Clearly Launch Services must have some internal rules, an algorithm, by which it arbitrates any conflicts between these modes of application binding. These rules are somewhat murkily documented, and have changed several times over Mac OS X's history. It is evident that the user's customizations in the Get Info dialog trump all other considerations, which is right and proper. But what if the extension and the creator code conflict? And in particular - and now we come to the real point at issue - what if a file's extension (its type) is claimed by multiple applications, and the file also has a creator code?

Apple's documentation says, in part:

"If more than one application has been found as a result of steps 2-3, apply the following criteria in the order shown:

(a) If the document carries a four-character creator signature (or if one has been specified as a parameter), give preference to any application that claims to accept documents with that signature (typically the application to which the signature belongs)."

So according to this rule, if two text files have the same extension (such as .txt), but one has a creator code "R*ch", then that file belongs to BBEdit. And this is a good thing, because it means that BBEdit can edit any text file without affecting its application binding, and yet when it creates a text file it can mark that file as belonging to itself by attaching its creator code to the file.

(If the text-based example doesn't float your mental boat, think about image files. A .jpg file created by Photoshop or GraphicConverter, respectively, can still belong to either Photoshop or GraphicConverter.)

That rule was obeyed in Tiger and Leopard, and users and developers have become accustomed to it. However, the rules also include an Elastic Clause:

"Note: Apple reserves the right to change the selection criteria in future system releases."

In Snow Leopard, Apple has taken advantage of the Elastic Clause. Without notice, and with no change to the documentation, Apple has apparently abolished the rule cited as "(a)" above.

Thus, an application in Snow Leopard cannot use a creator code attached to a document to bind that document to itself. For example, in Snow Leopard, when you create a text document with BBEdit, BBEdit assigns it the "R*ch" creator code, but nevertheless it belongs by default to TextEdit. It has TextEdit's icon, and when double-clicked in the Finder, it is opened with TextEdit - even though BBEdit created it. TextEdit has stolen BBEdit's document. Similarly, Preview has stolen documents created by Photoshop or GraphicConverter.

When I first heard of this problem, I thought it might be solved, however unsatisfactorily, by deleting a filename's extension (so that the system would be forced to use the creator code information). But although I'm told that this did solve the problem in early developer seeds of Snow Leopard, it doesn't work now, presumably because we're hoist with the petard of the UTI. A file's name may no longer end explicitly in .txt, but under the hood it is still a "public.plain-text", which amounts to exactly the same thing. Launch Services will still give the nod to TextEdit.

So your only option, if you want a file to open by default with BBEdit, is to say so explicitly: select the file in the Finder, open the Get Info window (Command-I), and change the Open With setting. That's easy enough for a single file, and also in the opposite case, where you want, for instance, all plain text files to open with BBEdit (click the Change All button). But what if you want to find just text files created by BBEdit and restore them to their pre-Snow Leopard behavior? Luckily, you can do it. Here's how:

In the Finder, choose File > Find. Change the Kind pop-up menu to Raw Query. (Choose Raw Query from the Other... dialog if you don't see it in the pop-up menu.) In the text field next to Raw Query, enter this phrase:

(kMDItemContentType == "public.plain-text") && (kMDItemFSCreatorCode == "R*ch")

This expression finds all your .txt files created by BBEdit; now you can select them all, do a Get Info, and change their Open With setting in one move. Deducing how to do this for, say, .jpg files created by GraphicConverter, is left as an exercise for the reader - a rather advanced exercise, which of course is exactly what's wrong with this approach.

As for developers, I'm not sure what they can do about this problem. You, the user, can use Get Info to mark a specific file with a preferred application binding, but as far as I know there's no way for an application to do that. Perhaps developers will be able to work around the problem by a judicious use of UTIs, but I'm not sure how or whether that's possible. It appears that Apple has well and truly snubbed creator codes in Snow Leopard.

[Evidence provided through an anonymous tip suggests that removal of the influence of creator codes in Snow Leopard was deliberately imposed by management on engineering. Since engineering's hands are tied, bug reports to them are likely to be met with the usual "works as intended" brush-off. A petition, or comments via the public feedback page, might be a more effective way to register opposition.]