Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the TidBITS Content Network for Apple consultants.

Snow Leopard Snubs Document Creator Codes

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.]


Backblaze is unlimited, unthrottled backup for Macs at $5/month.
Web access to files means your data is always available. Restore
by Mail allows you to recover files via a hard drive or USB.
Start your 15-day trial today! <https://www.backblaze.com/tb>

Comments about Snow Leopard Snubs Document Creator Codes
(Comments are closed.)

I don't think file extensions are the UNIX way. They came from Windows. UNIX didn't really have any standard they adopted the Windows methodology.
David Emery  2009-09-08 09:33
In Unix, they're a convention, since there is no 'double-click to open'. A file is executable if the right permission bit is set, there's a "magic number" at the beginning of the file that indicates if it's an executable (and if so, what kind). If it's a text file, then the first line can optionally indicate a shell program to interpret the text file.

On VAX/VMS file extensions worked as they do in Windows and now MacOS X. (ugh...)
Clem Dickey  2009-09-08 11:30
"make" uses extensions to determine file type, so in that sense extensions are a Unix way. But as others have noted, they are not the only Unix way.
Warner  2009-09-08 11:50
Also, cc, ld, as, ar, etc all did different things depending on if the file was a .c, .o, .s, .a, etc. This behavior dates back to the earliest days of Unix (I know for sure that v7 did this, but I'm not sure of earleir revs).

The convention in the source code also was like this for things like manual pages.

The key difference here is that Unix (at least old-school Unix, before GUI) didn't have a way to say "open" this file with "that" application. You gave the application a list of files, and it would do with them what it saw fit.

So I agree with other posters that this is a Windows convention. Windows may have inherited it from the systems, including PARC, that it derived from. The use in Unix under things like KDE and GNOME come in via Windows and don't trace from the earlier heritage.
Chris D  2009-09-08 11:54
"they are not the only Unix way" is indeed the Unix way, isn't it?
Another case of Apple trying to oversimplify something to suit the average end user.
Is it more sinister than oversimplification? Is it a way to bind all files of a type to the default (Apple) application?
In multiplatform environments, a very common problem is files generated on a Mac that lack an appropriate file extension. Give up. The file-extension way isn't great, but having a standard way that works even if your file system doesn't support any metadata except the filename is VERY desirable.
Dave Sopchak  2009-09-08 11:33
Not necessarily- you know how Mail has the option for "Send Windows Friendly Attachements"? When this is checked, Mail could convert any metadata stuff to the best file extension or whatever is appropriate, such as MIME...
Metadata on your mac, conversion to the Lowest common denominator for windows.
Thomas  2009-09-09 04:36
This can possibly work for mail, sure, but it won't work in the case of a shared network filesystem.
yurigoul  2009-09-09 11:49
I have html files created in various applications and since that is done on a per project basis, I want to be able to open up all those files in the appropriate application as soon as Idouble click them. Until now apple gave me that possibility and it helps the way I work.
File extension for launching applications came from DOS, not unix. Unix uses 'magic' and /etc/files to determine what application to launch for a file.
David Weintraub  2009-09-06 19:22
The "Unix" way was the /usr/share/file/magic file. This specified how you could tell what type of program opened each file. It could use file extensions or it could look at the first 256 bytes of the file.

Although there is an elegance in the Mac way of doing things, it was just "the Mac way" and didn't really fit in the rest of the world. The main reason to discourage use of file and creator codes is that they simply aren't used in the rest of the world, and that's important to the Mac.

I liked file/creator codes, but they simply have no use in an interoperable world. Much like resource forks. Neat idea, but you have to work with the rest of the world.
And yet, file/creator codes as they worked in Leopard were harmless to interoperability, cooperated with file extensions, and provided a sublime benefit when working on the Mac. I deliberately have chosen a Mac to use - interoperability is an admirable goal, but if I want lowest common denominator, what value does any OS provide me above another?
Thank you for finally calling this to public attention. I have been outraged over this since I upgraded to Snow Leopard on Day One.

It has completely destroyed my workflow. I can no longer simply go with the flow and expect OS X to "just work" every time I open I file I have to pause and decide which app I want and right click and pick the right app--as nightmarish images of Windows 98 come slamming down on me.

I am angry to the verge of tears. OS X was always a document-centered OS, now--sigh--it's yet another app-centric one. If I wanted this lame behavior I would have never switched.

Apple please if you happen to see this I'm begging you to change this unacceptable behavior.
Evan Scheessele  2009-09-08 16:57
Mark's comment that the Mac OS is/was/always had been until now *document-centric* is spot-on. The unfortunate changes described here (loss for respect for a document's creator code) seems to me like a short-sighted fix for a QA "concern" (new users being temporarily confused by how the system opens files) at the expense of a loss of a core but probably unnoticed feature valued by more prolific users and work-flow driven content creators.
Shay Telfer  2009-09-06 21:34
I'm now staring at a server full of documents our Mac users haven't added filename extensions to, and either have to script a mass renaming, or tell them to do it manually. Thanks Apple... thapple.
Travis  2009-09-08 09:58
I work in a multi-OS environment, so to be honest this doesn't bother me - and it now stops Photoshop from resetting itself to be the default app for any images I happen to edit, which I think is a good thing.

However my main reason for responding to your post in particular is to acknowledge a fellow "Look Around You" fan! Thanks, Shay - thay.
Andrew Laurence  2009-09-06 22:06
In many ways, us long-long-long-time Mac OS users are anchors, and we are unquestionably the sliver end of the Mac OS X bell curve. As a Mac user and an IT supporter, I long ago tired of files which "don't work" for most users because the Mac users ignorantly didn't put file extensions on their documents.

I'm pleased to see that Snow Leopard will force users to name their documents in an interoperable manner.

Umac_de  2009-09-06 23:06
It's a nightmare coming to .eps-Files.
May be quark.eps, FreeHand.eps, Illustrator.eps, Photoshop.eps or what ever...
exactly my problem. someone fix this.
I use file extensions to help me identify the file type and to help out non-mac-buddies. But - I want those files to open in the creator app.
I use several different text editors and graphic editors for several different file types - pdf, eps, png, tiff, txt, rtf, rtfd, php, html, csv - the type of file (much less the extension) should not determine which app opens it - what the bloody hell I was doing with it should decide what opens it.
I think it was OS 4 when I started using a Mac Plus. In general: Good news, it's all cheaper and more stable - Bad news, the OS and apps are less pleasant to use, too cumbersome and complex.

Windows did not exist when I started. When it did I choose Mac because it was better. Might not make any difference now except for hackers, but that will change too.

Bottom line, I'll stick with the Mac.
Paul Ellis  2009-09-07 07:50
I dropped the double-click habit years ago. I now always drag files to Dock icons to choose the app I want them to open in. Ironically, this was precisely because I *didn't* want a double-click on a PDF or JPEG I'd been sent to open Adobe Reader or Photoshop and wait half a minute for the app to launch when Preview would open and display it within 2 seconds. So, funnily enough, I prefer the new way.
Ross Carter  2009-09-07 09:01
Why do some posters think that creator codes and extensions are incompatible? I agree that files without extensions are a problem. Fine, so require extensions. You don't have to drop creator codes to do that.

I could understand ranking the extension before the creator code if the file came from an external source, or maybe if the file's owner is not the current user. But if I choose one text editor from among all the text editors on my Mac when creating a file, that's a pretty good clue that I want to use that app to open that file. If I wanted to open it in TextEdit I would have created it in TextEdit.

Thanks, Matt, for the thorough report.
I think the people harping about file extensions and interoperability are confusing type codes and creator codes.

Type codes are still followed in Snow Leopard. I.e. you still don't have to add on a file extension for Mac OS X to know what type of file it is.

Creator codes, however, which never imposed any obstacle to cross-platform interoperability, are completely ignored. I have a bunch of image files that were last saved in Photoshop. Except now they don't open in Photoshop, they open in Preview because that's the default application for that file type.

Now you have to specifically choose which application you want to open a file, rather than it defaulting to the last program you saved it in. It's really stupid behavior, and I sincerely hope it's a bug and not a "feature."
Grover  2009-09-08 05:04
So let's sum up:

Apple deprecated a system (creator codes) for associating files with applications back in 2001 or so and replaced it with with a different system. They supported this deprecated system for eight years. Now they've finally stopped supporting it and you're all indignant?

I'm completely baffled the tone of this article. If you don't like the new system, that's fine, but the "Apple totally pulled the rug out from under us" sentiment is absurd when Apple gave you nearly a decade to get used to the idea.
Adam Engst  An apple icon for a TidBITS Staffer 2009-09-08 07:35
I think the point is that eliminating the use of creator codes means that functionality is lost, and it's functionality that people used and liked. So it shouldn't be surprising that people are upset - it's always distressing to find that you've upgraded to a new version of something and lost previously enjoyed features.
Maristic  2009-09-08 10:12
You may have liked it, but other users (like me) hated it. If I export a .jpg file from ImageReady, I don't care where it came from. If I want to look at it a month later, I don't want to launch ImageReady. If someone else gives me a file they made with Word, I don't care, I want to open it in Pages.

Creator is the wrong model. Just because an app created a file doesn't make it the boss of that file. I am.

Now that's not to say there couldn't be better automation or specification of what apps to open for what files, but don't think that the creator scheme worked well for everyone.
Sam Moffatt  2009-09-08 16:31
The functionality is still there with the UTI. I started reading this article and wondering what were wrong. My Smultron files (plain text with no extension) were working fine and still associated with Smultron and will continue to open. It still works, but the old way is gone. The new way permits a form of fallback, so for the file in question:
kMDItemContentTypeTree = (

So if this is on a system without Smultron, anything that supports the plain text entry can open it which means that the open with menu still works even though the item doesn't have a file extension and has a custom creator code (SMUL)
Allen Watson  2009-09-09 11:14
So, how does one easily set the UTI? Perhaps the problem is that we do not have a decent tool for doing that job easily?
Patrick Stadelmann  2009-09-09 15:00
Unless Smultron is simply the default for plain text files without extensions !
Does it work if you save the file with a .txt extension and the default for .txt is not Smultron ?
As was pointed out in the story, there was never an easy way to change creator codes. That required some 3rd party application (I'm sure there are several in the works now). Typically the application did it for you and you changed the binding as necessary. The problem here seems to be that the creator codes weren't properly deprecated, giving developers time to move to UTIs on the files they create, nor did anyone think to provide a mechanism to assign UTIs to old files with creator codes.
Eliyahu  2009-09-08 05:22
This is quite offensive!

I'd like to add that not only are file extensions NOT the Unix way, they're also not the "only" or even a "standard" way!

Sun's Solaris, for example, put binding information into "hidden" files (names prefaced with a period,) in each directory. Solaris drag-and-drop would invisibly copy that metadata around into the appropriate folder's file.

And the "official" Internet way is through the MIME code, going all the way back to RFC-822 of 13-Aug-82, lo, these 27 years! (For those unfamiliar, see http://en.wikipedia.org/wiki/MIME or http://www.iana.org/assignments/media-types/index.html .) MIME codes are currently maintained by IANA - the Internet Assigned Numbers Authority.

Windoze-compliant programs map extensions to MIME types when inter-operating over the Internet.

In fact, Apple's invented UTI in Tiger to "improve" MIME. (http://en.wikipedia.org/wiki/Uniform_Type_Identifier) It's an initiative no others have followed, AFAICT, yet now they force it on us!
juandesant  2009-09-08 08:30
That is correct, the UTIs allow a file to be a public.plain-text, but at the same time be a com.barebones.plain-text if the application so desires.
This is a way to enforce application developers to claim their applications once and for all.
Sarwat Khan  2009-09-08 17:34
Unfortunately, the only way to attach a UTI to a file is by using a filename extension or four-char HFS file type.

BBEdit would have to either tag its files without .txt or 'TEXT,' meaning it won't be treated as a text file by other applications.
juandesant  2009-09-08 08:32
And you can read the praise of UTI's in John Siracusa's excelent review for Ars Technica:

Actually I remember file extensions from CP/M which came before DOS and Windows. The Atari ST also used 3 character file extensions and the Amiga could use them but I don't think it was necessary to have them. Wikipedia says DEC operating systems introduced them first so hardly the fault of "Windows" which came out many years later.

As for OS X you need to look no further back than NeXTStep (http://www.catb.org/~esr/writings/taouu/html/graphics/nextstep.png).
Dennis Groves  2009-09-08 07:31
Seriously, the UNIX is not the Windows way, and UNIX never adopted the Windows way. Former Windows developers who came to Linux ported the idiot Windows way they were familiar with.

Open a terminal and do a 'man magic' to learn about the much superior UNIX way.
Eliyahu  2009-09-08 08:38
Actually, "magic" is kludge! It's not a "superior way," it was just a developer intensive solution typical of Unix, where we are all geeks together. :)

Don't get me wrong. I LOVE Unix. I worked at Murray Hill through the Breakup ("Judge Green Is A Bell-Buster!") and I had lunch more than once with Ritchie et al., (tho' I was in a different department.) and am pretty much of a *nix fan boy. But that doesn't mean I can't/won't admit the truth. "Magic" is a very snarky way to solve the problem of identifying disparate file types.

In Plan 9, /etc/magic was eliminated; look at the source code for the file command (http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/file.c) you'll see that the "magic" style of file identification is used as a last resort.

Or look at Linux' man page for file(1), which includes a rant against Berkeley.

Serious *nix developers accept magic but understand it is NOT a desirable state of affairs. It's like nosehair - we need it, but cut it when it sticks out.
Tonya Engst  An apple icon for a TidBITS Staffer 2009-09-08 05:46
If I create a file in BBEdit, I'd like it to open up in BBEdit next time I double-click the file icon, assuming I"m still me and still using my same Mac. I'd like this to happen regardless of what smoke and mirrors is happening behind the scenes and regardless of whether Unix or the Mac OS or whatever is the root of the technique that makes it happen. Seems reasonable to me.
Roman Buussyghin   2009-09-08 07:19
I think they did the right things. If I want to change application associated with the file then I should change it explicitly.
Kernos  2009-09-08 08:37
For me it is more that just cosmetics. Part of my workflow includes sorting folders of 100's to thousands of JPGs by kind, so I can select those belonging to Photoshop, to Fireworks, to GraphicConverter or to Preview (default). This way I know what has been done to the photos and which remain to be processed.

Now sorting by Kind in a list view Finder window, lists them all as JPGs. I have been doing it this way for many years and am POed at being forced to change something that works well, by misguided managers at Apple

Where do I rant?
Kenny Millar  2009-09-08 08:55
The current behaviour in Snow Leopard is correct. It is the applications like BBEdit which have to move on. We're using a new schema now, suck it up and get used to it. BBEdit et al all need to define, register and use their own UTIs.
Dana Danger  2009-09-08 09:07
I must say I'm quite pleased with how this change affects image files. I hate it when I double-click on a JPEG thinking it will open in Preview, but instead I've accidentally made a life-altering decision to open Photoshop. That seems to be the only positive aspect of this decision though--I'm not thrilled with having to manually associate, say, text and RTF files with particular applications.
Kernos  2009-09-08 09:31
Which is why Kind should say Preview or PS or whatever.

I dont care how they do it, it should display as before.
andrew  2009-09-08 09:10
For those of you comfortable with the command line, there's a utility called "duti" for setting UTI ownership:

Allen Watson  2009-09-09 11:17
Now all someone needs to do is develop a simple GUI for it...
Torbjrn Vik Lunde  2009-09-08 09:12
I think this is great.

The way OS X handles what should open with what has frustrated me quite a bit before. I find simply having a default application for filetypes more orderly.

If I want to open a file in a specific app I can simply drag it onto the app in the dock.
Edward  2009-09-08 09:30
In your example, TextEdit didn't "Steal" BBEdit's document. It wasn't BBEdit's document to begin with, it was the users and the user expressed a preference for TextEdit to open text documents. Apple has just started honouring the users wishes.
phroggy  2009-09-10 07:10
Except that the user didn't really express that preference. The OS assumed the user had that preference. The user's preference, which they are now unable to express, is that all text files created by BBEdit should open in BBEdit while all text files created by TextEdit should open in TextEdit.
David Emery  2009-09-08 09:30
I think the dependence on file naming conventions is, frankly, A Bad Idea. I thought Creator/File Type codes, which could be stored as POSIX (implementation-specific) directory attributes was a much better solution. This is a case of "Unix integration" that Apple got wrong.
To be honest the OS X behaviour has been driving me mad in Leopard for ages. If I say "All txt files should be opened with TextMate" then that's what I want to happen. In Leopard it was random depending on which app had created it. So I say, good on Apple, they've fixed an annoying issue.
Aaron Swartz  2009-09-08 09:48
Where is the Get Info data stored?
Ryan Dunn  2009-09-08 09:49
So it seems that the opinions are split. Perhpas this would be better solved as an option somewhere, to enable/disable the new behavior.
Options are a sometimes necessary evil, but should be avoided where possible.
This doesn't need an option. It just needs developers of ancient apps like BBEdit to step up to the plate and use UTIs rather than legacy pre OS X functionality.
Adam Engst  An apple icon for a TidBITS Staffer 2009-09-08 15:02
To be clear, we just used BBEdit as an example - we have no idea what Bare Bones Software's plans are for dealing with UTIs or the like, so there should be no implied criticism of them for using a completely appropriate mechanism that has worked well for many people for many years.
breese78  2009-09-08 12:14
While the article did clear some stuff up for me, it left some unanswered for me. On item #1 above: "The user might have employed the Finder's Get Info dialog to bind this document to an application," you do not specify where or how this information is stored. Is it stored in the UTI?
Dan D.  2009-09-08 14:40
It's most definitely a bug, not a feature. Basically Apple has rendered several of my workflows completely unusable. I'm downgrading to Leopard tonight and staying there until this is fixed. I'm not about to switch to Windows, but there's no way in hell I'm going to such a broken system.
Sam Moffatt  2009-09-08 16:36
Upgrade your applications. My Smultron documents (Smultron does set UTI's) behaves as it did in Tiger and Leopard. Apple haven't nuked the workflow, they've just removed the option that they said they were going to remove when they introduced UTIs to begin with!
Jim Matthews  2009-09-08 14:59
"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."

We reverse-engineered the Get Info functionality and implemented it in Fetch. We let users say, for example, that downloaded .html files should open in TextWrangler (and not in Safari, which is probably the default .html opener).
Alexei S.  2009-09-08 20:30
Do you have any docs on the Get Info file-association storage format?
Oscar Ruitt  2009-09-08 15:28
Great. Add this to the extreme annoyance introduced in Leopard where the Finder doesn't remember the View of folders between openings of said folders or reboots. Where the hell is this OS headed?
Chris Gehlker  2009-09-08 17:03
The author is simply mistaken when he says that removing a file extension will not restore type/creator bindings. The issue is that editing the files name in the finder will merely hide the extension. Edit the name in the Get Info... dialog or from the command line.
Edd Knowles  2009-09-08 20:11
How difficult would it be for there to be an option to "turn on" the old behavior -- much like Windows XP allowed one to chose "classic view" for the control panel. In fact, is there a way to configure Snow Leopard to recognize creator codes??
Davide  2009-09-08 21:13
What, exactly, does Get Info do to make sure that a file is associate with a given application? This seems to be nowhere explained...
Douglas Goodall  2009-09-09 01:12
Gee and I thought in Unix there were magic numbers that could be used in many cases to identify file types. Then again #! headers feed a text file into the proper command interpreter without regard for a file extension. And to make things worse, when microsoft hid the file extensions, they allowed for file.txt.exe files to exist and cause users to click on executable files when they thought they were clicking on text files.
It is a bit of a poo for those who used some quite cunning tricks in workflow, like sorting images to find out which was edited with PS. But I seriously doubt that's the only way and that's OSX "top feature" noone can live without now.
Old behaviour was annoying at best. Photoshop save it's projects in *.psd files, I don't see any problem there. Once I create jpeg that's it, end product, open it with something fast, I don't need any editor anymore. Too me it also wasnt clear just looking at icons what resource hog will launch when I click on something like 3kb gif file. If file is so special I'm still one click away to make it unique. Next there is taging files, I, no OS, can organize them in different folders with automator ect. Adapt a bit, there are tons of options. But at bottom line this change is in my humble opinion good.
Bit by bit, the Mac OS goes away. I see people writing that 'the Mac way' doesn't fit the rest of the world. i didn't buy the rest of the world! I paid a premium for a BETTER way!

Remember when you told Finder to 'Calculate Folder Size's and it actually did it? I bet there's an Escape Clause in there somewhere, too. And Apple have the balls to put in an option for 'Use as Default', just to twist the knife a little further.

Now OS X can associate a file type with only one Application, how long before it just asks "Which application would you like to use and displays the contents of the Applications folder "for our convenience"? This sucks big time. OS X sucks more with every release. Bring back Mac OS please Mr Jobs (when you're finished fiddling with your tablet). BE OS is looking pretty good right now, isn't it, folks? Arrrrrrrrrrgh!
Shay Telfer  2009-09-09 07:10
So, where do developers go to register their filename extensions? Apple? Microsoft?
Alan Robertson  2009-09-09 09:20
I'm not an Apple user, but I found this thread to be quite interesting hence me commenting. Hope thats okay.

As an outsider it appears that many of you are unhappy with the change, but it does seem to be an improvement on the mish-mash of possible ways for the OS to open a file in previous versions.

I'm a RISC OS user and it has a similar approach to how OS X does it now. A hidden 3 digit code specifies the filetype, and it is upto an application to specifiy if it can open the file or not. And of course files can always be dragged to a applications window to open it if required.

I think Apple have done the right thing. I'm sure you guys won't miss the olden ways after a month or two.
Fenton  2009-09-09 11:29
First, thank you very much for your article. As someone who used BBEdit almost exclusively for text files, it is important for me for it to open its files. I use TextEdit for rtf, etc. (pretty colors).

Two files created with BBEdit

1. With extension ".txt", opens with BBEdit
{default application:alias "Macintosh HD:Applications:Text:BBEdit.app:", kind:"BBEdit text document", file type:"TEXT", file creator:"R*ch", type identifier:"public.plain-text"}

2. With no extension, opens with TextEdit
some text
{default application:alias "Macintosh HD:Applications:TextEdit.app:", kind:"SimpleText Format", file type:"TEXT", file creator:"R*ch", type identifier:"com.apple.traditional-mac-plain-text"}

My entry in Launch Services.plist:
LSHandlerContentType = "public.plain-text";
LSHandlerRoleAll = "com.barebones.bbedit";
Fenton  2009-09-09 11:37
I should have said, the info for the files was gotten by info for in AppleScript. I see in System Events dictionary that the default application of an item is writable. When I use that in a script, I can change the above "some text" file to always open with BBEdit. That changes its kind to "BBEdit text document" (seems the only difference).

That will be a droplet for my Dock Applets folder. The raw AS code (not yet a droplet, but you can see that it will work):

set aFile to (choose file without invisibles) as file specification
tell application "System Events"
set default application of aFile to alias "Macintosh HD:Applications:Text:BBEdit.app:"
end tell
Fenton  2009-09-09 11:46
Actually, it turns out I already had it, and better, by someone else (sorry, didn't keep who). Save as Application:

on open (these_items)
tell application "System Events"
repeat with this_item in these_items
set default application of file (this_item as text) to (path to application "BBEdit")
end repeat
end tell
end open
Breton  2009-09-21 17:30
You could even attach an apple script to your documents folder, to run every time a file gets saved there.
Shawn Rutledge  2009-09-09 12:25
Sounds like UTIs are an improvement. But they should be consistent: use UTIs exclusively and ignore the file extension. (Then again how are UTIs better than MIME types?)

BTW another approach on "unix" is to use the magic numbers database, like the "file" utility does.

There are 3 kinds of metadata: the kind that should be read-only (like creation date); the kind the user should be able to modify (like comments and open-with preferences); and the kind that is an inherent property of the data itself (for example, does it look like XML? or does it have a JPG header? or the average volume level of music in an MP3). But a file extension is a part of the filename, rather than separately-stored metadata. That has always been a bad convention, for the sake of filesystems that don't store metadata separately. Changing the extension does not turn JPG into PNG. The data type is inherent, and recognizable, so mostly it doesn't make sense for users to change this metadata.
Sandy Johnakin  2009-09-09 12:32
What about those of us who just use Snow Leopard and don't know Unix? I'm having a problem with files being downloaded and Dreamweaver opening when I click a link. I have no idea how to stop it. It's very frustrating.
heavyboots  2009-09-09 16:02
Get info on one of the files and choose the app that should actually open all files with that extension. Now choose the "Change All" button underneath and hopefully that will make all future docs default to that app.
heavyboots  2009-09-09 16:00
What is truly hilarious is that it has gotten so bad that they are accidentally creating a market for someone to manage their file opening for them. Soxy springs to mind as the first example of this.


I've written something similar just for InDesign so that we can double-click and get the right version of ID to open the file.
I'm running InDesign CS3 and InCopy CS3 under Snow Leopard. Unfortunately InDesign .indd files default to launching InCopy (which is not the behavior I want). So I went to Get Info... and while I change one file to "Open With..." InDesign I CANNOT use the "Change All..." button, because it is greyed out. There seems to be no way to tell Snow Leopard to always open .indd files with InDesign... (if I find a solution I'll post it here).
Conguero  2009-09-13 20:40
To make it clear: Unix systems don't depend on nor care about file extentions. In fact most of the files in a typical Unix don't have extentions at all. Unix commands like "file" figure out file types by reading the first bits in the file and fetching associated type from a database(usually /etc/magic or some c header file). File extentions are the DOS/Windows way and have nothing to do with Unix.
Wu0142adysu0142aw  2009-09-14 12:17
Old control panel RCDefaultApp by Rubicode still works under Snow Leopard and allows to manipulate the connections between applications and types, extensions and UTIs.
" ... presumably because we're hoist with the petard of the UTI."

What does that mean? (I'm not trying to be smarmy, or to be a proofing stickler. I'm really not clear on what that means.)

Adam Engst  An apple icon for a TidBITS Staffer 2009-09-15 13:28
Google finds some very enjoyable descriptions of the phrase. :-)

Chip Mc Kennie  2009-09-21 06:56
DefaultApp v2.1 PreferencePane may allow some 'modifying'. Refer to http://www.rubicode.com/Software/RCDefaultApp/
Patrick  2009-09-21 11:22
To be fair, this "feature" is one of the most annoying things to me in OS X. When I set "all documents like this" to be opened in a particular application, I do not wish for this to be changed to any or all files on a whim, not when I happen to open it once in another application and save it, not when I run another application and it decides to arbitrarily change my defaults, not in a house or with a mouse. I do not like green eggs and ham and I do not like this so-called feature. When I say always open in Preview I mean it. Forever. I can understand some people may like creator codes, but it should be very much optional.
Ted Wood  2009-09-22 17:40
UTI folks. UTI. It provides all of the functionality of the Creator and Type codes, and much more. You may need to retrain Snow Leopard initially of your desired file associations, but no functionality has been lost. They've just finally phased out Creator codes in favor of UTI, which has been around for several years now.
Florent V.  2009-09-22 23:59
"Can application in Snow Leopard cannot use a creator code attached to a document to bind that document to itself"

Thank goodness, at last! I won't get bugged by Photoshop attaching itself to vanilla JPEG images it creates. If i want to open a JPEG in Photoshop, i right-click the file and select Photoshop, or drag the file from the Finder to Photoshop's icon.

Why would i want applications to be able to SILENTLY declare themselves as owning some particular files? I want my file types and associated actions to be predictable, thank you very much.
This buggy feature was killed in Snow Leopard to improve UI consistency. That was the right move. The only persons complaining about it are application developers who relied on it (serves them right, especially if they didn't provide that behavior has an option%u2026) and some advanced users who used that feature in their workflow. My guess is that most users won't care, and many will just notice that they are not bugged as much as before.
Arnaud Nicolet  2009-10-03 06:29
If you create a file in an application, isn't it logical behaviour that the file gets opened in the same application the next time?
If you want a file to be opened in another application, create the file with that other application, that makes sense.