See here: http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/Documents/Tasks/SavingHFSTypeCodes.html

1 – when I “Save” a file, I want it to open in the same app it was saved. When I “Export” a file, I want it to be opened by the default handler of that type.

2 – that Apple and the developers sort it out. I’m postponing upgrading to Snow Leopard and buying any new Macs (except for a Mini Server) for as long as I can just for that reason.

Some people can say “You’re not upgrading only for that?”, well, since I don’t need to upgrade for any reason whatsoever, doing that and breaking my workflow for no reason at all would be just stupid, no? ;)

I should perhaps have been clearer here: I was thinking of myself as a potentially hijacking editing app, not as the user. (You could imagine a scheme in which user file ownership was itself a sub-subtype, still deeper than file creator, but even lowest-denominator filesystems have native file ownership, so that’s a bridge we need not cross.)

So, in the above analogy, imagine that the car is a “Joshua’s discount garage yellow sports car.” Joshua’s discount garage bears a relationship to Ferrari analogous to the relationship that BBEdit bears to the original creator app when it rebinds a file.

as both a designer and a coder, i’m sad to see creator codes go; but for years now Apple has junked up the system enough that i have been using drag & drop (first to DragThing, then to LiteSwitch, rather than Dock) because of how many files i receive from which HFS metadata has been stripped, for which it was never present, or where it is incorrect for my environment

i can envision a better solution involving multiple attributes — perhaps type, editor, local-editor, viewer, local-viewer, quick-viewer, etc. — plus a more evolved mechanism for acting upon a file — maybe separate gestures for view and edit; that’s not a fully formed idea, but an example of what i think is missing: articulation and handling of the use-cases of people acting upon files; currently drag & drop comes closer than double-click or even Open With to efficiently addressing my needs; i would even propose removing double-click, as it is a crutch that makes user thinking too simple — the idea that one can simply “do the file” and the right thing will happen is like a language with only one verb; but then i think that Apple is nowadays really embracing the crutch-ness of its OS

OS evolution is really too slow to catch up with, and perhaps help define, the growing non-verbal language we use with computer interfaces; OS designers should look at how the Web experience is evolving at a much faster rate, and also at the fundamental thinking shifts that are happening with the generations that have grown up with GUIs and mobile devices

I don’t see this. Your file would in this example would be a public.text (its type, so any text application knows it can edit it), perhaps also a public.text.frob-ml (some imagined well-known markup subtype, which only fancy text applications can frob) and also a com.example.ahruman.ahruml (your private sub-subtype, which only your app knows what to do with). You have your preferred AhruML editor installed, so this file will open in that editor for you. If AhruML catches on and someone else makes a competing editor that understands it, this file might open in that editor for me (just as in single digit MacOS some competing app might hijack your creator code for me). More likely, I don’t have an app that understands AhruML, so your file opens in my favorite FrobML editor, or if I don’t have one of those, in my favorite text editor. So far this is just like creator codes, except that we can have many hierarchical decision points (in my example, three) instead of the two that type/creator enforces.

So now, as in your hypothetical, let us suppose that I deliberately try to bind this file to BBEdit — as you say, I would change its sub-subtype to com.barebones.bbedit.txt, a subtype of either public.text or (if BBEdit groks FrobML) of public.text.frob-ml. This, I claim, enforces correct behavior. Henceforth, the file is associated with BBEdit, and if your AhruML app tries to open it again, we have lost the knowledge that it was once a com.example.ahruman.ahruml file — it’s just a generic text subtype FrobML, which AhruML knows how to read and knows how to hijack back again.

You might claim that we have lost something, because AhruML files have special gifts unknown to generic FrobML, and after BBEdit stole the binding your app has no way to know that it used to be AhruML. This is a feature, not a bug. As soon as BBEdit took over control of the file, while ignorant of its ahruml-ness, it can be assumed that BBEdit may have screwed up the content in a way that makes the file broken AhruML. BBEdit has only promised to understand text, and the FrobML subtype of text, and so what BBEdit touches is text, dialect FrobML, subdialect “BBEdit style FrobML,” no matter what it was before BBEdit got involved.

The UTI system provides an infinitely extensible, hierarchical means of identifying everything about the type of a file, and allows partial public and partial private knowledge to coexist within that hierarchy. The single-digit MacOS legacy claim here appears to be that creator/opener is a different kind of thing than file type, rather than the deepest subtype in a file type hierarchy. I just don’t see what this conceptual model buys you; it seems to me that hierarchical subtypes do all this and much more, and are conceptually cleaner. This is a car, it’s a yellow car, it’s a yellow sports car, and it’s my yellow sports car. When I transfer title, the innermost subtype changes, and the new owner puts maps in the wrong glove compartment. If he transfers title back, it’s still a yellow sports car, but I can’t assume it retains the map storage properties that make it a my yellow sports car. And, especially, if it started life as a “Ferrari yellow sports car” (creator code!), I can still keep that code by promising to understand it (I read the whole owner manual, it’s now a “my Ferrari yellow sports car”) or I can replace that code by ignoring it (I don’t know Ferraris too well, this is just a “my yellow sports car”). When I take it in to the shop, Ferrari can infer by the presence or absence of their subtype whether I was aware that the car was meant to be treated like a Ferrari.

In short, creator codes capture a particular sort of metadata: this file, in addition to everything the type data tells you, came from app X. Creator subtypes can capture exactly that data, and also an additional useful datum: this file, in addition to everything the coarser type data tells you, came from app X and has never been hijacked by any application that was ignorant of app X’s special subtype enhancements. This looks like a pure win, even for hardcore type/creator fans. Please, tell me what you lose.

(Note that, for this to work, any application that creates files should characterize those files in the UTI data by maximally informative hierarchical public types and then, at finest level, by its own private “creator” type. Also, apps that rebind other apps’ files should adhere to the convention of retaining type information they understand, and overwriting private “creator” subtypes that they don’t understand, while apps that simply display or nondestructively edit other apps’ files should leave the creator subtypealone.)

By now, they should have created a new way to do all this that is so much better in so many ways that everyone who likes either past system is satisfied and productive with the new one.

> separate exporting a file from saving it in the creator application

This is already how the guidelines are structured, but very few developers do this. Apps seem ignore Creators or use them all the time.

Also, has any of you thought about why some people are upset that files of the same type get opened by different applications, but have no problem with files of different types being opened by different applications? Think about it: they consider the former the same, because they have the same icons. QuickLook is fine and all, but I consider the loss of the information of what is going to open the file a regression; and obviously no policy is going to match everyone’s expectation (and that’s expected, that’s why it’s a policy, otherwise we’d call it something else), and if you can predict using the icon (or something else) a policy/expectation mismatch is only one extra drag and drop in this particular case, but if you can’t, then this mismatch becomes a huge inconvenience as the application that opens isn’t the one you expected, and you now have to suit it and drag and drop the one you wanted; the result is much more tension on the policy, which would pretty much need to read your mind (even if the policy can be set by preference) to not infuriate anyone, and a more heated debate than is healthy. So sure, the icons have become poorer in information with QL, so now let’s just make the policy poorer to match. But why not the other way round?

The first problem, metadata, is something that Siracusa has bitterly complained about since just about day 1. And I’m right with him. Almost every bone-headed design problem I’ve ever encountered watered down to missing information that was once in hand. Ignoring and destroying factual and near-factual information about a file is just plain dumb, and that’s what Apple is doing by relying on TLEs. I mean, c’mon, TLEs have been a dumb idea since their inception. (A file’s NAME is somehow supposed to completely DEFINE it??? Imagine if people were treated in such a way, Joe The Plumber notwithstanding.) The ‘creator’ of a file is pertinent information, final. How that information is used is a different point. The fact that Windows Explorer can display and sort audio files by ID3 information yet the Finder cannot, embarrasses me. Really. The fact that Apple so “doesn’t get” metadata that their “special” apps are the only ones that act upon it is beyond disappointing…it is, in short, a flawed design philosophy.

The second issue comes into focus as “solutions” to the issue at hand start to be investigated. All the “other side” commenters here are right: it is confusing to have files open in–or attempt to open in–weirdo apps. Which is why a second piece of metadata is required: the Utilizer code. A file necessarily has a TYPE which defines its internal structure, a CREATOR which can be used to modify/edit that structure, and a UTILIZER–the app that you want to open the file, for whatever reason. That could be further editing, ongoing editing, viewing, etc. But that is, typically, an INDIVIDUAL choice. Hence that piece of data should be attached on a user-by-user basis, not stuck inside the file or a file-system fork. Additionally the UTILIZER could be assigned system-wide. As Siracusa pointed out, with that much metadata, a definable policy could then be used to replicate ANY of the “preferences” mentioned in this debate! (As an aside, the act of “exporting” would necessarily be a mechanism by which a file’s CREATOR would undergo change…when a Web Designer finishes a site in Dreamweaver and exports it, the HTML files would then become “owned” by a public UTILIZER, a web browser.)

I think Siracusa’s, and ilk’s, argument is NOT that what Apple has done is right/wrong from the -user’s- perspective (John isn’t saying if you LIKE this way you’re dumb). What he is saying is that by going this route of fundamentally ignoring the merits of good metadata usage, Apple has now committed an act that has become very hard to undo. It is though, quite simply, Apple has said metadata be-damned. By not implementing Cocoa APIs that even PERTAIN to manipulating creator metadata on a file in 10.6 (the beneath the hood update, remember) yet still making the change to forgo the only creator metadata mechanism left, that’s pretty much the only conclusion to be drawn.

However, given the criticism that Apple has been getting for the past several years from Rixstep over UNIX file permissions and the liberties that Apple has been taking with them, I think we are seeing through to Apple’s true colors: they don’t care. Some of these changes are so specious and arbitrary–I’d say amateurish–that it belies a complete lack of an overriding design principle. Which is odd, given the thought behind technologies such as Grand Central, etc, from the same engineering division.

For details, see the article John Siracusa wrote here.
http://arstechnica.com/staff/fatbits/2009/09/metadata-madness.ars

If most of the the policy could be user set, we wouldn’t be having these discussions. Or, at least, they’d be less intense. As an example, if you could just go to “system preferences >file system >settings policy, and make change thus, and so”. Then everybody’s happy. Keep creator codes (an option could even make them permanently ignored), UTI, 8.3, or anything else.

Customize your system OS per this example, or in any other order you wish:
1) open file abc in application xyz (if set)
2) open file per UTI
3) open file in app creator
4) open file per file extension
5) open file in last app used
6) allow/do not allow any user set file info to override system wide preferences
7) anything I’ve forgotten
8) ASK
9) API for additional criteria. (As Apple, I’d avoid this option like the plague…)

Put a check box telling the system ignore all items but 8.3 and ASK, if you wish.

e.g., let it degrade gracefully. Unless the user sets the policy to do so, don’t ignore included file info. The OS POLICY should use all file info (in whatever order Apple desires) as a default. Then, let the user change the details as needed.

This way, everyone can set the system to open a file using the info available in your prefered order.

The system’s POLICY is what’s whacked. 10.6 should not be ignoring file info unless EXPLICITLY TOLD TO to by the user. I understand Apple’s wish to simplify the system. Many users don’t have any need to know about this, but if they ask, it’s there. Just make sure this is clear to developers, with clear API’s to use in carbon, cocoa, 32bit, and 64bit. This isn’t something to be used for forcing an upgrade (or downgrade in this case).