Slashdot Mirror
Snow Leopard Snubs Document Creator Codes
adamengst writes "In this TidBITS article, Matt Neuburg explores how Mac OS X 10.6 Snow Leopard changes how the operating system handles preferred application bindings, dropping support for the creator codes that have been part of the Mac OS from the early days. He also explains how to work around the problem, if you want, for instance, text documents created with BBEdit to open in BBEdit even when TextEdit is the default handler for text files."
While the good ol' File Type and Creator Codes served their purpose, it is finally time to put them to rest for good. I'm glad to see that it's finally happening.
We know what's best for you. We're making it just work. Now just sit back and drink your kool aid.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
The porn binding would be FUCK?
It's NOT me! It's the meds! I'm on 1000mg of Fukitol.
In Soviet Russia, applications bind you!
He also explains how to work around the problem
It's not a problem, it's a fix. This is the way it should work.
Suppose I put a Word document on a computer where OO.o is installed instead of Office. The document says "open me in MS Word". The OS says, "Word isn't installed". What happens? What originally should have happened: The OS looks at the document, says "Word document, open this with OO.o", and everything works great. The extra information was a stupid extra step. "Word document" is all the OS needs in order to figure out how to open it.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
This is especially annoying with Quicktime. The new quicktime in Snow Leopard is no match in comparison with the old Quicktime 7 Pro:
The editing features are now limited to trimming for example, the export possibilities rudimentary.
Fortunately, one can still reinstall Quicktime 7 additionally in Snow Leopard, but one can not change the default application binding for Quicktime. This is a serious problem.
For me, Quicktime pro is half the reason to use a Mac. Changes like this from Leopard to Snow leopard always make me nervous and I'm glad to have Linux catching up. Even apple might screw things up in future, possibly due to pressure of the movie and music industry.
One can for example suspect that the lack of cut and paste ability or export of sound only etc is due to such industry pressure. The average user can no more cut out advertisements for example. I do not see any technical reason why the new limitations are in place if quicktime pro is ditched. An other reason for the current limitations could be that a new QT pro is in the making. I hope this is the case. Still, one should be able to change the default application binding to an old version of quicktime!
(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.)
A UTI is not another piece of metadata attached to the file, it's just a unified abstract representation of a file type. The system knows that a file with the extension ".txt", a file with the MIME type "text/plain" and a file with the type code "TEXT" are all of type "public.plain-text", without adding any further metadata to the file itself.
File name extensions are definitely not the UNIX way. They are the CP/M way, copied later by DOS, then by Windows, then by UNIX graphical environments such as KDE, GNOME, and Mac OS X -- but still not by the under-the-hood UN*X running any of them; to UN*X, it's just an indiscriminate part of the filename.
It's very, very unfortunate that Mac OS X is now reverting to the primitive CP/M way. It causes a loss of essential functionality that Mac power users have always depended on: to know that a document will always be opened in the application with which you've created it.
For me, there is less and less reason to use a Mac as Apple keeps progressively emulating Microsoft. This is yet another nail in the coffin.
I'm in favor of this. I always hated when I had .png files created in fireworks that I wanted to view, and OS X tried to open fireworks up again instead of the default preview.
What's the point of making a default application if half the files will ignore it?
I have an old version of Word and Open Office and an older iWork. I prefer to open everything in openOffice. That is what I tell the OS when I set Open Office to be the default to open .doc files. I don't care if the original creator that emailed it to me preferred Word. I want to open it, by default by the application I choose.
Well.. maybe. Or Maybe not. But Definitely not sort of.
ma7 disturb other 486/66 with 8
To the transmission go of The minutiae clearly. There
He also explains how to work around the problem
It's not a problem, it's a fix. This is the way it should work.
Suppose I put a Word document on a computer where OO.o is installed instead of Office. The document says "open me in MS Word". The OS says, "Word isn't installed". What happens? What originally should have happened: The OS looks at the document, says "Word document, open this with OO.o", and everything works great. The extra information was a stupid extra step. "Word document" is all the OS needs in order to figure out how to open it.
That's always the way it worked. If you had a Word file (Type=W8BN, Creator=MSWD) on a system without Word (MSWD) installed, the system would identify any other applications capable of opening W8BN files, and open it using that app.
The extra information only came into play when there was more than one application capable of opening W8BN files. It prevented the common Windows practice of "hijacking" another application's file extensions.
You can flag a document to open with any application, regardless of the default. You can also change the default for any document type, including newly-created ones. Finally, you can right click and choose the app you want to open your doc with right there.
I think the complaint is that apps in 10.6 are not flagging their own documents to open with themselves. It should be easy to patch this in for any app that is currently being supported, but I suspect most won't care, because it's just not a huge deal.
anything they can do that will piss off their customers is fine by me.
Apparently, everyone has forgotten that UTIs have been in use since Tiger.
By the way, Slashdot, nice job not posting a link to Arstechnica's epic 23-page Snow Leopard review from last week. It's not like they put out the most detailed reviews in the industry or anything.
Although it is not the change to *nix that forced extensions upon us, it certainly was a major factor, along with the desire to interact with MS Windows. In any case it is nothing sudden or disturbing, just another step along the path of leaving OS 9 behind, and arriving at the OS to come after X.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
I double checked creator codes on wikipedia. They apparently also serve as a general file-type just like a filename extension. Except the file-type metadata is actually stored where it's supposed to be...with the other metadata.
So anyone know if this is just conceding to filename extensions, or if Apple is just dropping support for specific apps from claiming a _specific_ files no matter the OS wide filetype settings?
Once you start despising the jerks, you become one.
Of course, in the parent post, "In Apache's case I'm actually inclined to the former" should read: "In Apache's case I'm actually inclined to the latter". Sorry about that.
At first I thought it said "Snow Leopard Snubs Documentary Creator Code"...meaning some guy was doing a documentary about a Snow Leopard and there's some code of ethics between documentary creator and animal in that the animal is not supposed to eat the Documentary Creator.
Creator should be part of the application selection criteria, but it doesn't have to be Creator Codes. Creator Codes would be useful for file sharing over CD-ROM or MacBinary, but an ideal solution would be more a Unix-y one that allows plenty of user configurability.
I'd like to control the contextual menu. In that top section where the default is, I'd like to have all the apps I use most for that File Type. For html, cfm, js, xml and xsd documents, I want Dreamweaver, Eclipse and 3 browsers to show up there, with the default set by me. I should even be able to drag an item up to the top of the contextual menu to make it the new default on the fly. Creator Codes can do many-to-one (files-to-app), but they can't do one-to-many (file-to-apps). Let's just lobby for creator and/or current favorite apps to be part of the application selection criteria and leave it up to Apple to come up with a easy-to-use implementation that makes sense from an OS internals point of view.
I double checked creator codes on wikipedia. They apparently also serve as a general file-type just like a filename extension. Except the file-type metadata is actually stored where it's supposed to be...with the other metadata.
So anyone know if this is just conceding to filename extensions, or if Apple is just dropping support for specific apps from claiming a _specific_ files no matter the OS wide filetype settings?
As others have mentioned, Apple has a new metadata-based method for encoding file type ("Uniform Type Identifiers")... The new scheme allows for IDs to be much larger (arbitrary size, as opposed to the four-byte Creator IDs) - and because they're based on domain names (a system which is already centrally-managed) there's no need for Apple to centrally manage the set of possible type IDs to prevent conflict.
Bow-ties are cool.
Actually, I found this kind of strange, but on Snow Leopard, all application executable code is compressed and stored in a resource fork. The reason it's not left in the data fork is because it apparently would confuse Leopard to have a compressed data fork in the app. So now to Leopard, all Snow Leopard apps look like 0 byte files.
See here
http://dl.getdropbox.com/u/118359/ars/snow-leopard-indexed.html
In OS-X 10.5 Leopard, files open with the app that was used to create it. A jpg created in photoshop opens with photoshop and jpg files created in gimp open with gimp. It does not have the Window's limitation of totally tying down files solely by file type.
Hopefully Apple did not break this in OS-X 10.6 Snow Leopard.
So now OS/X works just like Windows. Wow, what an advance.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
From the referenced article in the story : "... 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... " The guy who wrote the article clearly has no idea what he's talking about and probably has never seen how this is done in Unix: it uses 'magic'. :)
Creator codes are going away, but UTIs (which have been available and preferred since Tiger) are the replacement.
It's the applications that must be updated to user UTIs instead of creator codes.
When was the bug reported & why did it take so long to fix?
Thank you. I think I would have enjoyed the summary more if they put less spin on it and included what you wrote. :D
Once you start despising the jerks, you become one.
I suppose xattrs are part of some specficiation, however the server software ecosystem doesn't seem to use them; you generally can't "round-trip" a file from a unix system and preserve the metadata.
Quite true. One of several reasons I don't think this change will come to Linux until it comes to Windows first, or something... But, still, I do hope we'll get there sooner than that.
I think xattrs are actually part of POSIX, but obviously at present they're not something one can rely on being present on any given server or filesystem... I suppose related features like ACLs could help drive more widespread adoption of xattrs (though in the kernel the two features are enabled separately, I believe...) - but right now it's not enabled by default because nobody uses it, and nobody uses it in part because one can't assume it'll be enabled...
I think that a lot of Unix users these days have a DOS or Windows background, though, so people tend to expect filenames to include extensions. Personally I'd like to see Linux move toward a scheme of file type identification based on xattrs, but it would be a long time before such a scheme would catch on...
Hmm. Some *nix things like *.c and *.o files go way back, however this might still reflect a DOS influence.
There certainly are times that having a visible file type is useful, and times when the old Mac "secret metadata" approach is a pain in the butt. I don't think it's a clear win either way even ignoring Windows.
The "secret" aspect of file-typing-via-metadata is really just an application problem. The fix is simply to add type identification to your file chooser dialogs, file browser, and command line tools like "ls"...
*.c and *.o are kind of an interesting problem... The compiler needs to create a new file, clearly related to the original, but with a distinct filename. File extensions do the job pretty well there, IMO - and I've wondered how one would deal with situations like those without them... I think there's no particular motivation to come up with such an alternate system - the main thing is simply that this file naming convention needn't (and, IMO, shouldn't) be tied to the file typing system...
Bow-ties are cool.
Apple also had to do a complete overhaul of Finder to re-write it in Cocoa (among other major changes to the older-than-Quicktime Finder).
They didn't try shoving out a missing-features version of the Cocoa-based Finder back in Leopard though, so why would they rush an intentionally-incomplete Quicktime X out the door ... unless they don't plan for Quicktime X to ever regain the QT 7 Pro feature set.
It might make a lot more sense (to Apple) to re-implement the dropped functionality that FCP/FCE need inside future FCP/FCE versions.
Which is exactly the problem. These are different things: creating, viewing, and editing, which are all being lumped together under the default "opener".
What's really needed is a default application for each verb: the default editor, default viewer, etc., and a simple way to express which you mean to do. Something like the tabbing in blender to switch modes might work: tab to create/edit mode, your pointer changes to one with an edit motif, double-clicking opens files in your editor; tab to research/view mode, double-clicking opens files in a quick viewer.
On OS X 10.6 look at your custom install options. I did when I upgraded.
No big deal. Rosetta is still there too.
Killing off meta-data was a truly boneheaded move for Apple. Type & Creator were extraordinarily handy for a developer. Even if you eliminate creator codes and rely on some system preference to decide what app to launch when you double-click, three-character extensions aren't enough to distinguish files. You might as well go back to the old 31 character file name limit. Feh!
You really don't get this, do you? The guy had a few files that'd been created in QuickTime. He wanted all such files to open in VLC, regardless of what program had created them. Whenever he'd double-click a file to open it, OS X had been cheerfully ignoring his settings of "use VLC for this filetype" and opening them with QuickTime because that's what created them.
That scenario is extremely unlikely, since QuickTime is not generally used to create AVIs. You have to actually go out and buy QuickTime Pro to even do that. And if you're the kind of person who's willing to pay $30 for an enhanced media player, you probably aren't then going to want to open it using a free/OSS player like VLC by default.
The other possible scenario (that he just happened to get an AVI file--not a native MOV file, but an AVI-- from another Mac user who was a QT Pro fan) is also unlikely, since creator codes don't usually survive downloads across the Internet. You download an AVI off the web, or through LimeWire, it picks up your preferred file associations. No creator codes involved.
Your average VLC-using Mac owner might come across a QuickTime Pro-created AVI file once in a blue moon. Nowhere near enough to cause confusion.
The simplest, most likely explanation is that he manually changed the association himself. And no amount of dumbing-down the OS is going to fix that.