Metadata madness

Yesterday I woke up sucking a lemon.

It seems that UTIs are in the news again. It all started with a change in application binding in Snow Leopard. In a scant few weeks it's degenerated into a sometimes-angry bout of cross-blog debate. I have an opinion about the changes in Snow Leopard, and I'll get to that eventually, but my main goal is to clarify the issue. It's really not that complicated, and seeing all the confusion on the web has been disheartening.

Type and creator

At issue are two pieces of file metadata: type and creator. (If you don't know what "metadata" means in this context, you can read all about it and come back when you're done.) I was going to explain these using an analogy, but screw it, this should be simple enough to understand directly.

Let's start with the simplest one: creator. This is the application that created a file. Presumably, all files were created by some application, but if not, or if the creating application is unknown, then creator metadata may not be present. But if creator information is present, this is what it's expressing: "This file was created by application XYZ."

A file's type describes the structure of the content. Is it a JPEG image? A plain text file? An MP3 audio file? It's possible to get confused about this piece of metadata because some file types are proprietary and are named after their creating application, e.g., "Adobe Photoshop document" and "Microsoft Word document." Those are file types because they're names for particular arrangements of data within a file. "File format" is a synonymous term that emphasizes the "internal structure" aspect of file type.

So that's the abstract. Now for the concrete. How are type and creator expressed? In classic Mac OS, each was represented by a four-byte value usually expressed as four characters. These are the fabled "type and creator codes." For example, TEXT is a type code for text files and ttxt is the creator code for the TeachText application. Type and creator codes are stored in the file system metadata structures of HFS/HFS+ volumes alongside things like creation and modification dates. (Mac OS X emulates their storage on non-HFS/HFS+ file systems.)

With the advent of Mac OS X, Apple introduced a new way to identify applications, and therefore a new way to express a file's creator. Each Mac OS X application has a "bundle identifier" (also sometimes called "application id") in the form of a Java-style reverse-DNS string. For example, the bundle identifier for iTunes is com.apple.iTunes. This is a lot more expressive than classic Mac OS creator codes and has a much lower chance of accidental name collisions.

In Mac OS X 10.4 Tiger, Apple introduced a new way to identify file types: Uniform Type Identifiers, or UTIs. Since file types are all about the structure of the data itself, UTIs are also used to identify data in memory (e.g., on the clipboard). I wrote extensively about UTIs back in 2005.

To review, we have now two ways of expressing a file's type (type codes and UTIs) and two ways of identifying a file's creator (creator codes and bundle identifiers).

Application binding

Now we come to the crux of this debate: application binding. That is, what happens when I double-click on a file in the Finder? How does the OS decide which application to use to open the file? The part of Mac OS X that makes this decision is called Launch Services.

Launch Services decides which application to use to open a given file based on an application binding policy. This policy can technically be based on anything: time of day, phase of the moon, the first letter of the file name, etc. But let's say we want the application binding policy to take into account a file's type and creator. Given a file on disk, how do we get that information?

We've already established that Mac OS X has at least two different ways of expressing a file type's and creator, so we're immediately faced with the task of prioritizing those representations. If Launch Services can get both a four-byte classic Mac OS type code and a UTI for a given file, which should it use? The values themselves will be different (e.g., TEXT versus public.plain-text) so it's not even clear if they agree, let alone if one is more precise than the other. The situation is similar with creator codes and bundle identifiers.

There is no one "right" answer. It comes down to an old-fashioned policy decision. A well-chosen policy will do what most people expect, and a poorly chosen policy may be confusing and even frustrating. But in the end, Apple is faced with the daunting task of matching a single policy with thousands of different mental models of "how computers should work."

For the sake of argument, and since we're all "technology enthusiasts" here, let's decide that Launch Services is going to ignore classic Mac OS type and creator codes and instead only deal with file type and creator information in the form of UTIs and bundle identifiers, respectively.

Given a file on disk, Mac OS X provides a way to get a UTI representation of that file's type. This may lead you to believe that, like the classic Mac OS type codes, there is a storage location somewhere in the file system for the UTI of each file. This is not the case. Instead, Mac OS X derives the UTI from other information, primarily—and tragically—from the file name extension.

But let's move on, because it only gets worse. How do we get the bundle identifier of the application that created a file? Like UTIs, there is no dedicated per-file storage location in the file system for this information. Unlike UTIs, there is also no way to derive this information from a file on disk. It's just plain absent.

Moreover, if any policy is to be based on these particular representations of file type and creator, there must be some way for a newly created file to be assigned these values. Since UTIs are primarily derived from filename extensions, applications have a way—albeit a heinous and barbaric one—to add this information to a file. But there is no Mac OS X API for assigning the bundle identifier of the creating application to a file.

Well, so much for our forward-looking Launch Services application binding policy. Though we can get file type information in the form of a UTI, it's not stored directly, and its derivation is based on another policy that may change independently. And we can't get the file creator information in the form of a bundle identifier at all.

This situation at least partially explains the historic Mac OS X application binding policy that referenced all available information: type and creator codes, file name extensions, and even a dedicated, per-file "ultimate override" field. The "legacy" type and creator codes may have been deprecated since Mac OS X 10.0, but when they're the most reliable data available on disk, they tend to win by default.

In all past versions of Mac OS X, file creator took precedence over file type in the application binding policy. If a file had creator metadata (and if it did not have a file-specific application binding override) then it would open in the creating application. The big change in Snow Leopard is that Launch Services no longer references file creator metadata at all in its application binding policy. There remains no way to assign or retrieve the bundle identifier of the application that created a file, and launch services no longer looks at the classic Mac OS creator code.

My opinion of this decision aside, it's important that people understand the parameters of the debate. There are three very distinct things at play here. There are the abstract concepts of file type and creator. What kind of data does this file contain? Which application created this file? Then there's the concrete representation of this information: classic Mac OS type and creator codes, UTIs, and bundle identifiers. Finally, there's the Launch Services application binding policy which may or may not reference any of these pieces of information when determining which application to use to open a file when it's double-clicked in the Finder.

Let me repeat that list because it's important: file type and creator as abstract concepts, their concrete representations, and the application binding policy based on them. Concept, representation, policy. These are three separate things. Conflating them leads to misplaced anger, unreasonable demands, and unhelpful recommendations.

Everything in its right place

Here's my take on the Snow Leopard changes, application binding, and file metadata in Mac OS X in general.

The classic Mac OS representations of file type and creator information should be retired. Those four-byte strings are vestiges of a bygone era when memory and disk space parsimony were more important than clarity and flexibility. The APIs for getting and setting these values and the file system storage locations for them can remain indefinitely, but their use should be heavily discouraged and removed from all Apple frameworks and applications.

Apple should add an official storage location for file creator information stored as a bundle identifier, plus APIs to get and set this value. All Apple frameworks and applications should set this value appropriately when creating or modifying a file.

Apple should add an official storage location for file type information stored as a UTI, plus APIs to get and set this value. All Apple frameworks and applications should set this value appropriately when creating or modifying a file.

The default Launch Services application binding policy should reference both file type and creator metadata, preferring the "modern" representations of each, and falling back to the classic Mac OS representations in their absence. The per-file "ultimate override" setting should be considered first. If that is not set, then the file should be opened by the application that created it. If that application is not installed, then the file should be opened by the default application assigned to that file type.

The Launch Services application binding policy should be configurable. Apple could provide a preference pane to do this, or it could merely expose the policy in the form of a property list and let third-party developers create a friendly interface.

All of the above—type as UTI, creator as bundle identifier, per-file application binding override—should be stored in appropriately named extended attributes.

Most of these are not new recommendations. I've wanted the officially blessed representation of file type information in Mac OS X to be something—anything—other than file name extensions since the earliest days of Mac OS X's development. When UTIs arrived in Tiger, they were so clearly superior to both filename extensions and classic Mac OS type codes that it was all the more tragic that they remained a derived, in-memory concept only.

The change in application binding policy in Snow Leopard pales in comparison to these earlier, more fundamental sins. Policy decisions can be reversed instantly in a point release. Official representations, storage locations, and APIs for getting and setting file metadata take much longer to create, document, and achieve widespread adoption. Poor decisions in these areas are now coming to roost. Apple clearly wants to close the door on type and creator codes, and I don't blame them. But that can't be done cleanly without putting their modern replacements on equal footing in terms of storage and APIs.

As for policy decisions, Apple continues to have a tin ear in this area. At best, we can hope for some timely backpedaling. At worst, not enough people will care and we'll be stuck with a crappy, non-configurable application binding policy for years to come.

One last thing. Recommendation number five in the list above might seem like a classic "just make it a preference!" punt, but a configurable application binding policy doesn't have to mean a vast, confusing interface. For example, Apple could add a single checkbox to the "Advanced" tab of the Finder's preferences: "Open files with their creating applications" (checked by default). That'd still leave a third-party opportunity to provide a more flexible configuration UI.

Anyway, I hope we're all on the same page now. You may disagree vehemently with one or more of my recommendations, and that's fine. As long as your desires and frustrations are expressed in the context of some minimal understanding of the concepts described above, I will declare victory.

I liked this article a lot. However ... now that I'm an Apple outsider :-) I can tell you with my years of hard-earned wisdom exactly where you've gone wrong.

quote:

Apple clearly wants to close the door on type and creator codes, and I don't blame them. But that can't be done cleanly without putting their modern replacements on equal footing in terms of storage and APIs.

Right here. You're implicitly assuming that Apple wants to keep the same behavior they've always had.

Wrong. Bad assumption. Apple doesn't want this. They never said they wanted it. In fact, I'd even go so far as to say they change things drastically all the time in other areas; why would creator info be any different?

Me, I'm betting that Apple wants to simplify the experience. Creator codes are too hard. They actually lead to weird behaviors -- why does a .txt file sometimes open this way and sometimes open another way?

If you were Apple and you wanted to simplify the way files are handled, ditching creator info entirely is a perfectly valid option. You may not like it personally, because you have N! years of experience with the way the Mac used to do things, but Windows has never had per-file creator information. On Windows you generally set your bindings correctly so that you use the default app 99% of the time. The few times you want to open it in a different app, it's just a right-click away.

You don't have to like it. But it's simpler. And arguably better, even, in its simplicity.

Now, are you telling me that at this point, the most simple experience is for the OS to open a *different* application than the one the user wrote the document in? That makes absolutely no sense at all to me.

Now, are you telling me that at this point, the most simple experience is for the OS to open a *different* application than the one the user wrote the document in? That makes absolutely no sense at all to me.

How about:1. macl0t opens photoshop.2. opens holiday pic.3. photochops the burro out and replaces it with teh steve.4. saves document.

The next day:5. macl0t double clicks on file.

now, according to you it should open up the file in big bloated photoshop, instead of some small elegant pic viewer.

Originally posted by Drew Thaler:Me, I'm betting that Apple wants to simplify the experience. Creator codes are too hard. They actually lead to weird behaviors -- why does a .txt file sometimes open this way and sometimes open another way?

Your problem is you are thinking in ms-dos. When you say opens a ".txt" file you are implicitly stating that you think of text files as ".txt" files. File extensions make sense in a command-line environment so you can - say - separate out your .c files from your .h files and your .sh scripts but why do you need files to be called ".cs" in Visual Studio or ".m" in XCode?

There's no reason in a modern operating system for file types to be controlled by a file extension. The only reason it exists in Windows is for backward compatibility. The only reason it exists on the Mac is because it exists in Windows.

I don't know why they don't go over to mime-types and actually introduce some consistency.

A user almost never wants a file to open in an application other than the one they have explicitly defined as the default for that file type. In the rare case that they do, they can simply drag the file to the correct icon in the dock.

Your assumption that Apple wants to retain the old, and in my opinion incorrect behaviour seems to be flawed. If that's what they wanted, they would never have made this change.

Instead it seems that Apple is thinking like I am: that applications on Mac should never deign to know better than I do, and should never override my choice of default app for a file type.

Which means that Apple have gone for simplification: an in-memory UTI representation, and a simple mapping from UTIs to file extensions (the default), magic numbers, MIME type, type-creator codes and what-may-you. It's simple, it's interoperable, it doesn't defy users' expectations and IT WORKS.

Originally posted by gypsumfantastic:Your assumption that Apple wants to retain the old, and in my opinion incorrect behaviour seems to be flawed.

I'm not assuming anything; I'm merely explaining the cause of all the consternation.

quote:

Which means that Apple have gone for simplification: an in-memory UTI representation, and a simple mapping from UTIs to file extensions (the default), magic numbers, MIME type, type-creator codes and what-may-you. It's simple, it's interoperable, it doesn't defy users' expectations and IT WORKS.

It doesn't defy your expectations, you mean. As I wrote, "Apple is faced with the daunting task of matching a single policy with thousands of different mental models of 'how computers should work.'" That's why I recommended that Apple make the application binding policy configurable. Your only remaining quibble is that I recommended that the default behavior stay the same as it as been for the past few decades. (Okay, and that I called your policy "crappy" )

As John states in the article, whatever policy Apple chooses is upto them (whether to open based on creator code, or file type).

Even if Apple chooses file type, this decision should be based on file-type based on the extended attributes of the file, rather than the extension. The extension should only exist for graceful degradation while transferring files to and from other OSes.

Now, are you telling me that at this point, the most simple experience is for the OS to open a *different* application than the one the user wrote the document in? That makes absolutely no sense at all to me.

How about:1. macl0t opens photoshop.2. opens holiday pic.3. photochops the burro out and replaces it with teh steve.4. saves document.

The next day:5. macl0t double clicks on file.

now, according to you it should open up the file in big bloated photoshop, instead of some small elegant pic viewer.

Yes. Because if you just wanted to preview the picture fast you'd hit the space bar after selecting the file in the Finder.

Originally posted by gypsumfantastic:A user almost never wants a file to open in an application other than the one they have explicitly defined as the default for that file type.

Sure is pull stats directly out of your ass around here. Where's your double blind random sampled study about what "a [Mac] user almost never wants" gypsumfantastic? Oh, you don't have one? You just made that up based on your own personal biases? In that case feel free to not make retarded blanket statements with no sort of clear evidence.

Where's your double blind random sampled study about what "a [Mac] user almost never wants" gypsumfantastic? Oh, you don't have one? You just made that up based on your own personal biases? In that case feel free to not make retarded blanket statements with no sort of clear evidence.

Are you being repugnant because you disagree, but know that almost everybody will agree?

I suppose part of why I love Ars is because it's one of the few places where as statement like "people want their computers to do what they tell them" is controversial.

Maybe you've done a study yourself which shows that users just ADORE it when their computer does something different from what they expect and ask it to?

Originally posted by divisionbyzero:The clarity of your exposition makes Apple's intransigence even more perplexing.

Not really. John's simply starting from a flawed premise: that Apple WANTS Mac OS X to have Mac OS 9-style behaviour but can't figure out how/hasn't got round to it yet.

Apple's declaration of intent with file extensions, UTIs and the ignoring of Type/Creator codes is pretty explicit to me. But for the dying breed of Old School Mac faithful, it seems that a decade-spanning body of evidence is not quite enough.

Opening a file of a particular type in the program you have explicitly asked the OS to open that type in shouldn't defy *anybody's* expectations, unless they're mad or used to the old, broken Mac OS 9 behaviour, or both.

And it's fair to say that Apple, quite rightly, doesn't care about those sorts.

Opening a file of a particular type in the program you have explicitly asked the OS to open that type in shouldn't defy *anybody's* expectations, unless they're mad or used to the old, broken Mac OS 9 behaviour, or both.

The problem with that theory is the "explicitly asked the OS" part. For example, people who upgraded to Snow Leopard did not consider that process to be an explicit instruction to change the application binding policy. This is the nature of a "default policy." Users experience the behavior without taking any explicit action.

Good, well-reasoned write up. I have been struggling with this since upgrading to Snow Leopard. There are definitely arguments to be made one way or the other. As for me, I was used to the old creator code system. It came in handy when I wanted to open simple notes from a meeting in text edit (where I created them), but wanted a .txt with some sample code, SQL, etc in it to open in Smultron (where I created it). I think the Photoshop example is the perfect counter example though. (Or Final Cut or something for a movie file.)

Apple has let us know which way they went on this debate (bye bye creator codes) but I am disappointed that they haven't included a way to easily manage the behavior of all your extensions. It's quite frustrating. And I find that the icon for files does not always match what it will open in.

And if anyone can explain how the heck the right click, "open with" dialog determines what programs to populate that menu with, I'll give you a cookie. I cringe every time I have to use that menu. Why, when I right click on CSV's does it suggest TextEdit and Excel in my Fusion VM and Excel in a Fusion VM that doesn't even exist anymore? What about my other text editors? What about Excel for Mac? And it doesn't matter if I go and manually choose a program, that option isn't added to the list (like it is in Windows). I have to go through the same process again and again and again when I open that file. And as for finding the program to open it with... ugh. You'd think it would be a simple Spotlight search on the Apps directory for the program I'm looking for, but inexplicably Spotlight will sometimes return documents in addition to the program. I presume these are READMEs and such that are multiple layers deep in the application folder, but the end result is I type "smultron" into the Spotlight search box in the application chooser windows and I have to scroll down and find the stupid program EVERY TIME I want to open this particular file. (I don't want to change the association for all files, I just want this particular one to always open in X program.) Gah!

Sorry, a bit of a tangent there. Long story short, as it currently stands it's the least elegant and most frustrating part of my OS X experience by far. Apple needs to make it more transparent and definitely add a preferences pane to control all this behavior.

The problem with that theory is the "explicitly asked the OS" part. For example, people who upgraded to Snow Leopard did not consider that process to be an explicit instruction to change the application binding policy. This is the nature of a "default policy." Users experience the behavior without taking any explicit action.

You're right there. But Apple has never shied away from making changes that break some people's expectations if it thinks the new way is the better and that their old expectations were wrong.

I understand that it can be wrenching for those so caught out, but let's be honest, we're Macheads. We should be well used to it by now.

To be honest, this change had been driving me batty. I have 3 different GUI editors on my system: BBedit, Textmate, and XCode. I use them for different things. Some file types I edit in BBedit all the time. Some I only edit in BBedit when they are remote, as Textmate and XCode really suck at remote editing. And that, right there, is the source of my frustration. I use ExpanDrive to access remote shares. I want to be able to set a policy that says:

"Use application X for file type Y except when on a volume mounted via ExpanDrive, in which case use BBedit"

Anyone know how to do that? I say "had been driving me batty" because I've developed a new habit of "drag file onto dock icon" style opening. But I really prefer keyboard filesystem navigation, and having to use the mouse to open a file irritates me. And no, using the "open -a App_I_Want " option isn't really an option.

If I may throw a couple extra pennies into the cauldron with a question - what is currently the predominant method a typical computer user engages to access their files, and how have software/OS vendors contributed to or reinforced that behavior over the years? With over a decade in IT for various industries, I would be so bold as to say that users don't utilize the GUI interface to the filesystem at all - they start with the application they want to use, and if they need to navigate to a file they wish to open, THEN they browse the filesystem in an open/save dialog - and that behavior, to the dismay of long-time Mac users everywhere (myself included), began with Program Manager in Windows 3.1, and continued to the Start menu...

Or...they save every damn document they ever use on their desktop....

But if you look at it fairly closely, you'll see that more and more applications, specifically the ones most commonly used by the computing public, are taking it upon themselves to abstract away the filesystem anyway, and Apple in many ways is leading the charge with the iApps (including the iPhone, where the filesystem is invisible until jailbroken ). the iPhoto "library" is a good example, as one of our beloved bundles, but how many users of this app will "view package contents" to get to their photos? Probably only users sophisticated enough to read Ars... But we won't let this thread devolve into how (in)consistently even Apple is at abstracting away the filesystem between their apps...

Suffice it to say, most users, when they want to open a file, are probably already in the application they wish to use to manage that file, and if they need to launch any sort of helper (or even know that's a possiblity), have already configured that application to give them a contextual menu to get them there. Sometimes I think the only reason the Finder, Explorer on Windoze, and other filesystem management GUIs are still around is because...well...they're still around (and who wants to lose the smiley Finder face? )...more and more, the paradigm is shifting to the heavily application-centric every day - and with that fact, default application handling behavior from the filesystem GUI becomes more and more a moot point.

I do agree that it should be trivial to add a preference for users who wish to retain the "application who created a file continues to handle it" paradigm, but for most, I don't think they even care, because frankly, they probably don't even know what the Finder is except that happy smile on the left side of their Dock...and remember how the structure of Apple's growing user base is changing - people like us, who even know what a filesystem IS, are losing or have already lost our claim to Mac-using majority, so the bulk of Apple's customer base is now spending most of their time in iTunes, iPhoto, and Safari, and even if they are moving to the next level and using iWork, they probably have a "Documents" folder full of 10,000 items with no organizational hierarchy whatsoever...

OK everyone, this is my first post on an Ars forum, and I can't wait to hear how I'm wrong, but please, be gentle!!!!

As I commented in the second blog post from John C. Welch, I'm making a similar proposition, that I in fact posted as a radar some time ago, and (since it was posted before OpenRadar) this decided me to put it on OpenRadar: http://openradar.appspot.com/radar?id=77403 (for, you know, duping or whatever). The "tl; dr" version is:- a new extended attribute to store the UTI of a file- a new extended attribute to store the MIME type of a file (for files saved from emails or downloaded from the web, as they both come with a MIME type), but the UTI xattr takes precedence- four-char type code and extension only used as fallbacks- a new extended attribute to store the creator as a bundle identifier, and used much like the creator code was.- keep the current system for setting an application for opening all files of a given type- a new extended attribute to store the application which the owner has set to open this particular file if the owner has overridden the application with which to open the file; if it is not present, the creator xattr is used to know which application to open the file with, and if there is no creator, then file type is used (why not use the creator xattr for that? First, so that users other than the owner still use the creator rather than the preference of the owner; second, so that when the file is edited by an application, this application will change the creator xattr but leave the preference untouched so that the file keeps opening with the application the user has previously explicitely specified)- if the user is not the owner of the file but wants to override the application with which to open it, then the preference is stored not in the file metadata but in the user preferences, with enough info to find the file even if it moves (similar to an alias).

the "tl; dr" version of that "tl; dr" version is "similar to what Siracusa said".

I am indeed afraid that what the "powers that be" actually want is to completely remove any sort of creator behavior; hopefully our discussions will show we do actually mind the removal of the functionality. But, while I don't know whether it's simpler, what I know is that it is a poorer experience. It's not a matter of having been a Mac user for 25 years either, because I wonder in which universe having the new SL behavior be mandatory makes sense; as Ross Carter said (via DF and others): "puh leez". I think it encourages "switching" applications for a given type, as if only one was supposed to be active at any given time, much like you would switch web browsers, and actually opening files only from within applications, making the system ostensibly file oriented (the new SL behavior is rather more file oriented, while the previous behavior is more application oriented) but actually more application oriented!

It is certain however that there actually are people who prefer the new way, but it's hard to tell if they actually have a point (most of their reactions leave out details), so I think we should try to confront the opinions, workflows, and use cases to try and reach a better model, or at least an understanding of each other. I'm not certain a preference switch would be best, but that's a possibility.

Originally posted by drinkthak00la1d:I would be so bold as to say that users don't utilize the GUI interface to the filesystem at all - they start with the application they want to use, and if they need to navigate to a file they wish to open, THEN they browse the filesystem in an open/save dialog - and that behavior, to the dismay of long-time Mac users everywhere (myself included), began with Program Manager in Windows 3.1, and continued to the Start menu...

I think you nail it quite well, unfortunately. Especially with anyone that's ever suffered with Windows, as that's the mental model it encourages. Even the Mac OS X "Recent Items" and Spotlight menus put Applications before Documents.

And if someone is creating a file from scratch then they *have* to select the application, unless they've left a few blank documents around to double-click on (which only "power users" tend to do.)

Even though most of the "iApps", and others using "bundle" library files (e.g. Aperture), support running the application with the file that has been double-clicked, many users are conditioned to instead expect to change the open library or catalogue by selecting it within the application.

(But, I do think that if a document has a Photoshop icon, say, then it should cause Photoshop to load when it is opened. It's just that, now, it's less likely that a file will have that icon even if it's been created from within the app.)

I've found some of the moaning from the likes of Macworld tiresome. However, I think the "bynkii" article and this one between them do succeed in showing that the current system is broken.

As the "bynkii" guy (what makes him think "shepherd" - someone who herds sheep - is spelt "shepard"? - never mind) points out, if you remove the file extension, the system doesn't know what to do with your file. That seems broken to me.

I just removed the ".html" extension from a spare webpage I had in ~/Documents. Snow Leopard now doesn't know what to do with it. If I double-click it a blank page (not the file) opens in Safari. But if I right-click it, I see that TextEdit is the first choice. (I also get offered OpenOffice, Safari and two instances of TextMate - I guess the doubling-up of TextMate just goes to show how broken Launch Services is.)

I just removed the ".jpg" extension from a graphic. If I click it, it opens in Preview. However, if I right-click it, the default application is, again, TextEdit ... although I'm also offered HoudahGeo, OpenOffice, Safari, and Xcode ... but not Preview.

In practice, users aren't likely to be removing extensions, but the fact that the behaviour of the OS is so bizarre and unpredictable when you do is telling. AFAIK, a Unix/Linux system makes some kind of attempt to look at the contents of a file to know what to do it with. It's not clear to me what Snow Leopard is doing: how it decides what to open in when double-clicked in Finder, how it decides what to offer on the "Open With" menu, and why the two don't match. And the blank page opening in Safari really takes the biscuit.

I just removed the ".jpg" extension from a graphic. If I click it, it opens in Preview. However, if I right-click it, the default application is, again, TextEdit ... although I'm also offered HoudahGeo, OpenOffice, Safari, and Xcode ... but not Preview.

Originally posted by Nyx:How about:1. macl0t opens photoshop.2. opens holiday pic.3. photochops the burro out and replaces it with teh steve.4. saves document.

The next day:5. macl0t double clicks on file.

now, according to you it should open up the file in big bloated photoshop, instead of some small elegant pic viewer.

nope, that wouldn’t open in photoshop, because it wasn’t *created* in PS. so PS should not set its creator code in the file.

It does open Photoshop if you saved the jpg as a new renamed file (steve_is_a_burro.jpg) This is a common workflow for many people. It means my folder full of images is totally random: some open in Photoshop and some in Preview. I have to select all and override the "open with" property in the get info panel, and I keep having to do this over and over to keep it cleaned up. I prefer the new way. You clearly prefer the old way. Hence, Apple should make it a configurable option or they have to tell one of us to shove it. As of now, it looks like they said it to you. Sorry! You can get the behavior you want by always using an application specific file type like psd until you are ready to save the final product as a jpg. Until 10.6, I had no easy way to get the behavior I wanted.

Originally posted by mat79:nope, that wouldn’t open in photoshop, because it wasn’t *created* in PS. so PS should not set its creator code in the file.

That's usually not true since editing a file and re-saving it is most often treated as the creation of an entirely new file. The obvious fix is to add "last modified by application XYZ" as yet another piece of officially supported metadata that the application binding policy can (optionally) reference.

Originally posted by drinkthak00la1d:With over a decade in IT for various industries, I would be so bold as to say that users don't utilize the GUI interface to the filesystem at all - they start with the application they want to use, and if they need to navigate to a file they wish to open, THEN they browse the filesystem in an open/save dialog - and that behavior, to the dismay of long-time Mac users everywhere (myself included), began with Program Manager in Windows 3.1, and continued to the Start menu...

You're arguing that Mac users don't use the finder to open files??? Maybe I'm an outlier but I'd guess that over 90% of the time I open files using the finder rather than the Open/Save dialog box. My guess is that in general, you're dead wrong.

Originally posted by Ilo:Until 10.6, I had no easy way to get the behavior I wanted.

And that is where you are wrong. In Leopard you can tell it at that point to always open all files of this type with, say, Preview, and from then on all JPEGs will open in Preview, ignoring the creator information.

About the .m issue, it may be an edge case, but it does demonstrate how hopelessly collision-broken the extension system is.

BTW, warning, this article has just been fireballed. Commenter influx is to be expected (and of people who will have an opinion on the matter).

I think Apple is moving in the direction of deprecating the idea of using the Finder to choose a document to edit. If you use the Finder you're going to get a basic least-common-denominator app. Apple's preferred approach seems now to let the user choose an app to manage each specific file type and turn the process of picking a file to edit on its head. For example, consider iTunes, iPhoto, xCode, etc. These apps are all about organizing files of a particular type without regard to how those files are stored. If you're going to work with music files you launch iTunes, you don't use the Finder to dig into your music folder.

At one point early in the life of Mac OS X, there was an idea floating around that the Finder could become some BeOS inspired general purpose metadata handling customizable workhorse. You wouldn't need iTunes because you could customize a Finder window to do everything iTunes does directly. I don't know if that would have been better or worse, but it doesn't look like it's going to happen.

Originally posted by ZPedro:I am indeed afraid that what the "powers that be" actually want is to completely remove any sort of creator behavior; hopefully our discussions will show we do actually mind the removal of the functionality. But, while I don't know whether it's simpler, what I know is that it is a poorer experience.

And I think this is really the gist that John is getting at. Anyone who's read his Metadata article should "get it". Metadata is a "Good Thing". Certainly too much metadata is a waste, but there is such a thing as just enough. Maintaining the 'creator' and 'kind' of a file makes as much sense as maintaining when it was created and when it was modified. I mean, that info is as important as when it was last backed up, no? Additionally, as many Mac users (content creators typically) have learned through the years, files often have different creators than utilizers. Both should be stored per file. If they were, John's suggested policy would work wonderfully.

Of course, the UNIX solution of 'magic' seems to point to a more elegant solution to me, not in the 'magic' binary, but in the idea that file structures should be including "public" metadata within them, like ID3 tags and EXIF data. Intelligent files would be better. To me, at least, Creator is more "inherent" to a file than Utilizer. One is a fact, the other is a choice. But 'magic' and its ilk won't work well in multi-user environments for metadata any more extensive than "facts". Clearly Apple needs to develop a multi-user friendly version of extended attributes, which it does NOT have right now, before they can go forward.

John is right, TLEs have to die. A horrible fiery death. They were inadequate from day 1, and the much more brilliant implementation on the Mac only spotlighted that. OS X's, nay Apple's comical intransigence towards moving forward from them is puzzling, especially considering how close they've come to killing them off. But without a multi-user solution, nothing much is going to change.

How about:1. macl0t opens photoshop.2. opens holiday pic.3. photochops the burro out and replaces it with teh steve.4. saves document.

The next day:5. macl0t double clicks on file.

now, according to you it should open up the file in big bloated photoshop, instead of some small elegant pic viewer.

If macl0t double-clicks the file, my assumption would be that he intends to photoshop it some more, so yes. Photoshop should open. This assumption is based on the idea that if macl0t wanted to simply look at the file, he would select it and hit space.

As you say, Mac OS X used to basically repeat the last action the user took, which for many users is what they expect to happen. The traditional behavior is more likely to be what most casual users expect. Save a document in application X, double-click it, application X opens the document.

As for non-casual users, what you prefer depends on your workflow. Both solutions cause problems. Since Mac OS X has always used creator codes, my assumption would be that most Mac users are either happy or okay with this; otherwise, they wouldn't be Mac users. So far, the change has only caused problems for me: .txt files which are associated with the wrong application (this is a problem I can't solve in Snow Leopard, since I use different text editors for different types of text files). .ogg files are especially problematic, too, because some of them are music files and should open in Audacity, while others are movie files and should open in QuickTime player. Then there are all the .xml files which I need to edit in different XML editors, depending on the content of the files. And the .html files, some of which I need to open in Safari, others I need to open in BBEdit.

The change has caused a ton of issues for me, and they are issues I can't possibly solve because Snow Leopard has removed the solution to them.

ScooterComputer's post above emphasizes a point I don't think I leaned on heavily enough in the article: more metadata is good. We should encourage the application of as many truthful pieces of metadata that we can imagine ever being useful or interesting. (Within reason, of course; I'm not advocating megabytes of metadata on tiny text files.) A symptom of conceptual failure is any discussion of applying false metadata or arguing against the addition of truthful metadata in order to trigger or avoid a policy decision.

The key (which I did emphasize in the article) is to understand and maintain the distinction between the metadata and the policies based on it. Metadata: good. Policies: maybe bad, maybe good, but always changeable—but absolutely hopeless if the metadata is missing or false!

There is still one remaining confusion, I think. On what basis do you distinguish between different files that are the same data type but are different file "types"? E.g. one text file is just a list of stuff to do. One is XML. Another is C code with a .c extension.

These are files where the user might "convert" the file from one kind to another just by renaming them. How does the OS keep up with this? Or must the user learn a new behavior?

quote:

"Open files with their creating applications" (checked by default)

It should be UNchecked by default.

I like the new change, and I would support storing creator information so that people can opt into John's preferred policy.

But it's nuts to think that the old way was suitable for the masses. The only people that want per-file or by-creator binding seem to be graphic designers and coders.

The lowly masses who use email, web browsing, and office applications want their defaults honored, almost always.

John Siracusa / John Siracusa has a B.S. in Computer Engineering from Boston University. He has been a Mac user since 1984, a Unix geek since 1993, and is a professional web developer and freelance technology writer.