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

Comments

RIP

[Anonymous Coward]

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.

Re:RIP

[Jeremy Erwin]

Time to put them to rest for good? Why? What on earth for? I am puzzled by your joy.

Re:RIP

[mfnickster]

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.

Yes - but they should be retired in favor of something better, more reliable, and more elegant, and filename extensions AIN'T IT.

It remains to be seen if UTIs can fill those shoes. From the article, it looks like Apple doesn't yet know how to make good use of them. They certainly aren't easy for the end user to work with, since I never heard of them before today!

Re:We Know Best

[nine-times]

On the other hand, you could argue that Apple is protecting users from developers who say, "We know what's best for you. We're making it just work. Now just sit back and drink your kool aid."

If I want my text documents to open in BBEdit, I'll set them to open in BBEdit thankyouverymuch. I set my default for them to open in something else, and that's the way I want it.

Re:We Know Best

[MyLongNickName]

Care to explain what you mean here? Sounds like Apple is simply going the way of UNIX/Microsoft (I *think* UNIX used file extensions or part of the file itself). So how is Apple off base here?

Or were you just trying to make a snarky first post?

In Soviet Russia....

[Anonymous Coward]

In Soviet Russia, applications bind you!

Re:In Soviet Russia....

[Anonymous Coward]

Well you have no clue att all.

This has been the sole issue why i have hated all but MacOS.
Filenamn.extensions are so bluntly freaking unusable rubish that I cannot understand how evolution hasn't allready brought it down. Unless there is a God that allowes wickeness to happen in this world.

This is one of the GRAND features of Mac that have made Mac users, Mac users and ahead of others, never even steared at any other platform due to their usless unflexible file bindings trough stupid thing as a name.

Well maybe every one of you called .john want to work at microsoft and never be allowed to apply for a other job outside microsoft on your own initative.

I live next to Old Sovjet they been smarter than stupid american name.extensions bah. If i mett Jobs and he would back this I would give him my 41 in his back. Make sure it's a sharp 41.

Any platforms out there doing proper file bindings? Amiga OS 4??? Any???
GRRRRR RRRRRR RRRRRRRRRRRRRRR !!!!!!!!!!

FFFFF APPLE. The only thing that has been perfect since 1984, untill OSX 10.0 or developer release where it was at first cripled and slowly fixed to work now removed again. ARRRRRGH

I better boot my SE/30 to get proper file handling.
Mac Pro owner who is relly relly dissapointed.

Those who claim this is a fix "Simply have no IQ at all" even less understanding how a computer should handle documents.

It would be nice if they reomoved the creator code and gave us somthing better that wheren't from the times where every bit counted and every thing was optimised to the last drop, go ahead, but removing such a key feature fom the mac. I could as well go back to times of Windows 3.1. If this is the way MacOS starts to work in the future well then it is about as advanced as Win 3.1

I hope SJ reads this and I am writing a protest to Apple ATM.

Re:We Know Best

[Knara]

On the other hand, you could argue that Apple is protecting users from developers who say, "We know what's best for you. We're making it just work. Now just sit back and drink your kool aid."

If I want my text documents to open in BBEdit, I'll set them to open in BBEdit thankyouverymuch. I set my default for them to open in something else, and that's the way I want it.

QFT. Overriding my choice as the end user for default application open selection is a no-no.

Problem?

[clone53421]

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.

Re:Problem?

[Anonymous Coward]

Apple found the way that it worked properly. (Not that that would be admitting that they were wrong in the first place)

Re:Problem?

[gabebear]

It had uses, but I think it did complicate more than it helped.

Example of use:
I have a lot of AVIs, and a handful of them only play in Quicktime, or only play in VLC. I changed the creator code on those files so they open in specific player.

Re:Problem?

[nine-times]

The extra information was a stupid extra step. "Word document" is all the OS needs in order to figure out how to open it.

Well actually OSX still lets you set the proper application to open on a per-document basis, and it's kind of handy. AFAIK, what happens if you put a Word document on a computer that doesn't have word, but has OO.o, OSX will read the part that says, "open me in Word" and say, "Well I don't have Word but I have OO.o, so I'll open you in that instead." So there's no problem.

However, let's say you have both OpenOffice and Word installed on the same machine, and 9 times out of 10 you want to open your Word documents in OpenOffice, but you have that 1 document out of 10 that doesn't display properly in OpenOffice and you want to preserve the current layout. What's actually kind of nice IMO is that you can say, "I want my default to be to open all Word documents in OpenOffice, but I can set this one individual file to open in Word." And then the OS will open each document in the correct viewer when you double-click on it, automatically. It works great.

So what's being talked about here is that it has typically been set in the past so that, regardless of your default application, documents were set to open in whatever application you saved/created them in. So it's like lets say OpenOffice is my default application but I create a new document in Word. The old behavior is that document would automatically be set to open in Word when you double-click on it instead of OpenOffice, even though OpenOffice is your default application. It makes a certain amount of sense to do it that way, since you may have done layout work in Word that won't render properly in OpenOffice.

However, I personally want to set a default application for each file-type, and then only have them use a different application if I manually set them to do so.

Re:Problem?

[tlhIngan]

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.

What if you didn't have OO.o OR Office installed?

Type/creator codes were meant to replace "ugly" extensions, but in the Internet age, the only way to pass file metadata around is in the filename - MIME types get preserved, if you're lucky, but more often than not, the MIME type is just based on the filename (i.e., the extension).

This was probably due to limited namespace - what is a ".doc" file? These days, it's 95% certainty it's a MS Word document. But it can also be a plain text file since many older programs from the 80s/90s used ".doc" to represent a generic document, like a manual. You'd have README, README.TXT, README.DOC, etc.

So Mac came up with a way to use 2 32-bit identifiers - a creator code, and a type code. Creators are used to identify a creator, so double-clicking would open the same app that opened it (back in the days when compatibility was horrible, the general thinking is you want to open something in the app that created it). The type ID was a fallback in case you can't find the creator, you can try a type lookup, in case it was something another program could handle. If not, you could consult a small database of creator codes to application name mapping, and display an error like "The file 'my file.doc' could not be opened because 'Microsoft Word' was not found, nor any other program that could open it.", thus providing the user with a reason why the file can't be displayed/viewed/etc., and what the user could get to open it. (Would be nice for whoever did the "WINMAIL.DAT" crap...)

These days, it seems that creator codes aren't useful anymore since any number of documents can be created in any number of programs, and binding a document to who created it is less useful these days. Type codes are still useful, though, though the expressiveness of modern extensions makes even type codes obsolete.

Re:Problem?

[clone53421]

What if you didn't have OO.o OR Office installed?

Open it with whatever the default app is for Word documents. You still don't need to know what it was created by.

Type/creator codes were meant to replace "ugly" extensions

Extensions are oft-maligned, but underrated in my opinion. They're part of the filename, they're easily seen (if you have them turned on, which you of course should – hiding the extensions by default is a stupid, stupid move IMHO), and they're easily changed if necessary (granted, most users will never need to change one).

Creators are used to identify a creator, so double-clicking would open the same app that opened it (back in the days when compatibility was horrible, the general thinking is you want to open something in the app that created it). The type ID was a fallback in case you can't find the creator, you can try a type lookup, in case it was something another program could handle.

That's why PhotoShop has .psd, GIMP has .xcf, etc. Compatible formats are meant to be compatible. If they're not, you're doing it wrong.

Re:Problem?

[MMC Monster]

The problem is for those of us that didn't know that creator codes exist.

We would set .avi files to all open in VLC, and be confused when some opened in quicktime.

This is a bugfix.

Re:Problem?

[Anonymous Coward]

In other words it worked fine before, and had extra functionality that provided a convenience for the users. Now the extra functionality is gone, and you're saying "Finally!"

You must use Linux.

Here's a hint: the "extra step" you mention was completely invisible to the user, and provided useful functionality for them. Operating systems are supposed to be written for the sake of the user, not for the sake of the operating system writers.

Re:Problem?

[Anonymous Coward]

Funny? So you're saying that OSX will now work like Windows already does and allow you to set the default for a single file opening. Nice!

Re:Problem?

[clone53421]

It didn't work fine before, but plenty of other people illustrated that fact and I don't have any additional personal experience to attest to it, so I'll let them speak for themselves.

Re:Problem?

[ThrowAwaySociety]

The problem is for those of us that didn't know that creator codes exist.

We would set .avi files to all open in VLC, and be confused when some opened in quicktime.

This is a bugfix.

So let me get this straight.
1.You set the default AVI app to VLC.
2. You deliberately chose some AVI files, went into File Properties ("Get Info"), and individually set those to open with QuickTime instead.
3. You were confused when those specific AVI files actually opened with QuickTime?

Fine, whatever. Some people aren't going to get it. But the system should not be designed around such people.

Re:Problem?

[Mneme]

No, they were opening in QuickTime just because they were originally saved by QuickTime.

No one ever did Get Info.

It sounds like this previous behavior seems odd to you (since you misunderstood what happened), which supports the perspective that for most users, the behavior was odd and the change amounts to a bug fix.

Re:Problem?

[ari_j]

No, it's a work-around for a PEBKAC. That doesn't make it more or less worthy, it just isn't a bugfix.

Re:Problem?

[Anonymous Coward]

Personally, I just use right-click (OMG! Yes, Mac has a right-click) and "open with" if I don't want the default.

Re:Problem?

[Sandbags]

That might sound simple enough when refering to a doc file, or a compressed package. However, if my default document editor os OO, but someone sends me a file from office 2007 containing macros, OO is going to have issues with that. I'd like to know not only is it a .doc, but also that its a Word 2007 .doc file, so if it doesn't open in OO, or looks odd when it does, I can quickly identify the actual application used to make it and try opening it that app (if I have it or a compatible reader) instead.

This gets even more important when you look at files not typically opened by an end user as well. I occasionally search my system for folders containing files I can't itentify. Often uninstalling a program leaves crap behind, and if I find an unidentifiable folder, all the binaries in it should give me a clue as to the program they were associated with. I don;t want to guess...

Also, taking the type and creator away limits my ability to mess around with automator. it was yet another data point i could scan for without having to open the file first.

i agree Apple needed a method for giving the user control of how a program was opened, but taking away these options was not the best way.

Re:Problem?

[peragrin]

Snow leopards Text Editor app has support for ODT. Which is great but since text editor doesn't have all the feaTures of Open Office editing the file becomes harder. The "mac way" while not universally supported is farbetter than just extensions alone. Where if you have multiple apps for the file type fails the ease of use.

Re:Problem?

[proxy318]

Bah, if I want to open a file with something other than the default app, I'll just right-click -> open with, done. Or start the program and go to file->open. Or drag the file to the program's icon. The creator codes just cause me problems. If I want to open a PDF file in a shared folder, what do I care that someone else prefers to open it with Adobe Reader? Most of the time I'd rather open it in Preview since it's far less of a steaming pile. The creator codes just seemed to be the OS not doing what I told it - I'd say, open all PDFs with Preview, and it would most of the time, but then sometimes it would go "surprise bitch! adobe reader!". So if they're gone, good riddance.

Re:Problem?

[Jeremy Erwin]

Apparently, that's also why Word, Wordstar, WordPerfect, DisplayWrite and Framemaker all have used the .doc extension for their proprietary file formats.
 

Re:Problem?

[Tacvek]

In other words, you like this change, as it uses the following in order: an explicit file specific default, an explicit file type default, or an implicit file type default.

The old way was in order: Explicit file-specific default, explicit file type default, the application that made the file, an implicit file-type default.

(Yes, according the the Apple documentation the creator code never overrode an explicitly set default application for a file type, but would override the implicitly chosen default application.)

Re:Problem?

[Anonymous Coward]

That's why god created command-line.

Re:Problem?

[Just Some Guy]

So let me get this straight.

Fail. The GP was saying that he'd set all AVI files to open in VLC. In spite of that, some would open in QuickTime anyway because that's what the creator code indicated, which confused the GP greatly because he didn't know that such a mechanism existed.

Re:Problem?

[ThePhilips]

That is (if RTFA to be believed) is unchanged in SL.

Re:Problem?

[ThrowAwaySociety]

No, they were opening in QuickTime just because they were originally saved by QuickTime.

No one ever did Get Info.

It sounds like this previous behavior seems odd to you (since you misunderstood what happened), which supports the perspective that for most users, the behavior was odd and the change amounts to a bug fix.

Since when does QuickTime save AVI files?

Re:Problem?

[ThePhilips]

LOL. And RTFA illustrated that it worked perfectly fine before. And now is broken. Very few commenter here managed to bring an example which was actually broken. Rest are simply "what if"s.

Sole example of old behavior being broken I have read above: QuickTime was used to create .AVI, VLC is associated with .AVI, yet the created file would be open by QuickTime due to creator code.

Example from RTFA is similar but goes backwards: files created with PhotoShop are being by default open with Preview. Changing .PSD association to PS makes it open all files with PS, not only the ones you work with.

Both are valid examples. Both can be mitigated if tool to change association of multiple files would have been provided. And PS patched.

Re:Problem?

[hattig]

You mean you set the "Open with..." in the Get Info window? That still works, the article says so.

The real problem is that everyone needs five media players on their computers just for handling bad videos, but they all have the same extension. Quicktime, VLC, mplayer, niceplayer, etc, etc, etc. It's a shame that the "vague short extension" mechanism of identifying files has won, especially now we have container files with variant contents.

Re:Problem?

[wiredlogic]

It isn't a stupid extra step. If the creator app isn't installed then it's wise to use whatever available app can handle the document. On the linked page someone made the important observation that this will completely break the proper behavior when using multiple graphic design apps that use their special flavor of eps with metadata as their document format. Without using a creator code you can't launch the right app for a document.

Re:Problem?

[clone53421]

Sole example of old behavior being broken I have read above: QuickTime was used to create .AVI, VLC is associated with .AVI, yet the created file would be open by QuickTime due to creator code.

You missed the comments which mentioned similar behaviour where Photoshop was launching to open JPEGs and PNGs.

Example from RTFA is similar but goes backwards: files created with PhotoShop are being by default open with Preview. Changing .PSD association to PS makes it open all files with PS, not only the ones you work with.

Photoshop documents should open with Photoshop. If you only want to preview it, that should be a right-click menu choice, not a file-by-file setting that overrides the "Open in Photoshop" default action.

Re:Problem?

[pwfffff]

http://www.dummies.com/how-to/content/importing-and-exporting-files-with-quicktime.html

Re:Problem?

[FooAtWFU]

Bah, if I want to open a file with something other than the default app, I'll just right-click -> open with, done.

Whoawhoawhoa, slow down, buddy...... right-click? You're scaring me with your crazy-talk!

;)

Re:Problem?

[ThePhilips]

Photoshop documents should open with Photoshop. If you only want to preview it, that should be a right-click menu choice, not a file-by-file setting that overrides the "Open in Photoshop" default action.

.PSD is not PS-only file format anymore. Probably in Windows or from POV of end-users. But nor on Macs or among designers.

It is quite often used as a plain image file format. There are many applications which can read it (Mac OS X's vanilla Preview can, any decent image editor) and many applications which can write it (same list).

So this was a quite normal work flow: all PSDs you create yourself would be open by PS, rest - by default Preview.

Re:Problem?

[clone53421]

I'd argue that the amount of time lost by having to right-click and choose "Preview" (which should be the 2nd choice, the first being "Open") is worth it for the added benefit of always knowing what the file will open with. Double-click to open with PS (or other default editor), right-click and Preview to preview. (If you usually work the other way around, you could of course set it the other way around... default "Open" could be Preview, and "Edit" could be PS.)

Otherwise, it's impossible to know how the file will open – will it open with Preview, or will it open with Photoshop? Depends on what created it, and if you didn't create it, ...

Re:Problem?

[Anonymous Coward]

I agree. Being able to set globally plus per-file is enough for me. I always thought the creator codes felt like the application (usually Adobe something-or-other) was hijacking my associations.

Re:Problem?

[Anonymous Coward]

I'm left handed, you insensitive clod!

Re:Problem?

[ThePhilips]

I'd argue that the amount of time lost by having to right-click and choose "Preview" (which should be the 2nd choice, the first being "Open") is worth it for the added benefit of always knowing what the file will open with.

And users know how file will open. If I created file yesterday in Photoshop, I can be sure that reopening it today would also start Photoshop, not Preview.

OS doesn't know why file is there nor can it know which application (of many choices) to use for the file.

But user does.

Otherwise, it's impossible to know how the file will open â" will it open with Preview, or will it open with Photoshop? Depends on what created it, and if you didn't create it, ...

... and if you didn't create it - then use default application.

So finally you understand why it was implemented so? :)

OS can't know what file is for - instead of deciding for the user, follow the history of file.

As RTFA says, there were no technical reasons for the change. There is no point in technical discussions. Apple's management decided to clean up the handling, make it more aligned with the rest of systems.

"There are no reasons for it. It's just our corporate policy." (c)

Re:Problem?

[clone53421]

And users know how file will open. If I created file yesterday in Photoshop, I can be sure that reopening it today would also start Photoshop, not Preview.

Easily solved by right-clicking. And if you didn't create the file, you have no idea what it will open with.

... and if you didn't create it - then use default application.

If the file contains metadata telling the OS what to open it with, it won't use the default application. Attached to an e-mail or downloaded from the web, probably fine (the metadata isn't included). Shared via LAN or removable device? Probably has the metadata.

OS can't know what file is for - instead of deciding for the user, follow the history of file.

Not deciding for the user: allowing the user to decide. Setting a universal setting is more consistent than assuming that because a file was created with PS it should be opened with PS, because the file type is easily seen but the associated program is not. The user might not know/remember what program was used to create that particular file.

Re:Problem?

[noidentity]

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.

What you describe is how it's worked since around Mac OS 8 or so, and perhaps Mac OS 7 with Easy Open. The creator code just lets you customize which program it opens with, allowing you to have for example a folder full of text files, some of which open in TextEdit, the rest of which open in BBEdit.

It's two separate pieces of information: type and preferred application. If you eliminate the latter, it must be approximated by making a new type. In the example, you'd have to create a new "BBEdit text file" type to have them open separate, but then other programs wouldn't know of this new type you created.

Re:Problem?

[mattack2]

Personally, I like extensions, and I use them.. but I'm a geek.

Why should the filename, which should be the user's domain, be overloaded with info about what is in the file/what to open it with?

According to the man page on 10.6 (just for reference), UNIX has attempted to glean file type info from the contents of a file since at least 1973. Shouldn't the file info be somewhere else, at least optionally, than the filename?

Re:Problem?

[gabebear]

Ya, I finally read the article and realized you can still do the "open with" thing... I always figured that it just changed the creator code.

Anyhoo, this is definitely a better setup, but where is the "open with" info/metadata stored?

Re:Problem?

[Tokerat]

It's not a problem, it's a fix. This is the way it should work when the default application is not found

Fixed that for you. Can you please explain how saving a file in Photoshop and double-clicking it later only to have it open in Preview is anything but annoying? Now, I agree it's rather silly for JPEG files to behave that way, but I should be able to at least set a default there, as in "Files saved with Photoshop always open with Photoshop", and maybe even add an "Except JPEGs". They way it is now is going to surprise many users, and then annoy them until it's changed. Not a great example of "works as expected".

Re:Problem?

[turbidostato]

"Extensions are oft-maligned, but underrated in my opinion."

Extensions are oft-maligned in Windows-world, and overrated in my opinion.

"They're part of the filename"

They are a constant on the file name, thus if you can get rid of it the more significative the name gets to *you*, the user.

"hiding the extensions by default is a stupid, stupid move IMHO"

Why? I bet you meant it's a stupid, stupid move *on Windows*.

It is the computer the one that needs to know what to do with a storage format (be it related to a disk partition or a file) so it's better not to throw such uneeded information at the user, unless he needs/wants to deal with it for their own reasons, so it really makes sense to either hint what the file is by its header (Unix' magic tests), by its MIME/type (Internet downloads) or by some other usually hidden metadata. Then you are right that once the computer knows about what kind of data is stored it is up to the computer (in lieu of its human user -that still should be able to overrule the default choice) to decide what's the best way to deal with it, not the producer.

Re:Problem?

[jonadab]

> Whoawhoawhoa, slow down, buddy...... right-click?
> You're scaring me with your crazy-talk!

Yeah, no fooling. This is slashdot. If you want to open a document in a particular application, you're supposed to grab one of the several terminal windows on your desktop and launch the app from the command line with the document path and filename as an argument. It's quicker and easier than fooling around with context menus and junk.

Re:Problem?

[jonadab]

> That's why PhotoShop has .psd, GIMP has .xcf, etc. Compatible formats
> are meant to be compatible. If they're not, you're doing it wrong.

That's just what he was saying, though: Microsoft was doing it wrong when they chose .doc (previously the single most popular extension for 8-bit IBM Extended ASCII text files, which were VERY common prior to the misguided and short-sighted switch to ISO-8859-1 as the default codepage in Windows 95[1]) as the extension for early versions of MS Word. And it is worth pointing out that there are several mutually incompatible MS Word formats, all of which use .doc for the extension.

Now, the extension for MS Word is one of the worst cases. (Not the worst, though; that honor probably belongs to .dat or perhaps .sav.) But in general the problem is that there's no central registry of which extensions are taken and what they mean. I'm not sure there *should* be, either: that would create other kinds of problems. Nonetheless, the current situation does create some unfortunate ambiguities. Another example is .scr, the main extension used for transcript files (a text format, usually plain 7-bit ASCII), and also for Windows screensavers (executable).

So yeah, there *are* problems.

I don't think creator codes are a good solution, however. They don't really tell you what kind of file it is, which is what you need to know. They tell you only what application created the file, and that's ABSOLUTELY not the same thing, nor does it really matter. I do NOT want to go back and live in a world where every application only really fully supports its own custom file type that nothing else can read or write properly. File formats should be completely independent of the applications that read and write them, and in the modern era they mostly are, and this is good, and it makes creator codes irrelevant. Also, creator codes don't survive transfer via most internet protocols very well, on account of the fact that Unix doesn't have them.

Magic numbers (or strings, like the shebang line on Unix-style executable text files) are a significantly better solution IMO, especially when used in conjunction with filename extensions. All file formats SHOULD include a magic string or number at the beginning that clearly identifies the specific file format *and* the version of the format. Even formats that aren't intended to have later versions should have a version number, because you can never predict for certain whether you're going to need to slightly extend the format later.

---
[1] Microsoft *should* have waited just a bit longer and gone directly from Extended ASCII (as the default) straight to full-blown Unicode. It was already obvious that they would eventually need to move to Unicode, and the introduction of Latin-1 as an intermediate step caused unnecessary problems, IMO, in addition to making old documents more difficult to handle at the time. All of which is neither here nor there now.

Re:Problem?

[clone53421]

Photoshop documents open in Photoshop; JPEGs open in Preview. That's totally easy to predict (you don't have to know what the file was last saved in, for one thing). To open Photoshop documents in Preview or JPEGs in Photoshop, you can right-click and choose a non-default application. This, to me, is the best solution: you get the desired behavior as default in most cases, and easily (one extra click) get the non-default behavior on the rare occasions when you want it.

Re:Problem?

[clone53421]

Your argument is dangerous. "Hide the information from the user" is not a good solution.

An executable can have whatever icon you give it. If someone creates a malicious executable with a standard Word document icon, at least the extension will tip off the user (even at a glance, if they're paying attention) that this isn't an innocuous Word document. If the extension is hidden, or if the OS determines file-type "magically" and doesn't use extensions, how can you tell at-a-glance?

Yeah, hiding extensions is a bad move on Windows, but anything that obscures the file type is a bad move on any OS.

Re:Problem?

[CrashNBrn]

You have to be joking right? How is it possible that mac has something like codecs so messed up that you need different players for different content of the same extension...

Re:Problem?

[Anonymous Coward]

You missed the whole point, didn't you? Read the article again, or use a Mac after gradeschool, and proofread your comment.

The Mac already does this. If you _do_ have both apps installed it should open in the one which created it, unless you specify otherwise.

The new OS breaks this, so it always opens in the one the OS thinks is right- like Windows. Oh, that explains it, Mr Ballmer, sorry

Re:Problem?

[clone53421]

The Mac already does this. If you _do_ have both apps installed it should open in the one which created it

No, it should open in the one I specified for that type.

unless you specify otherwise.

Can't – except on a file-by-file basis.

So yeah, they fixed it.

Re:Problem?

[turbidostato]

"Your argument is dangerous. "Hide the information from the user" is not a good solution."

Hide the *unneeded* information to the user is *always* the proper solution. Not only on IT but on every engineering realm.

"An executable can have whatever icon you give it. If someone creates a malicious executable with a standard Word document icon, at least the extension will tip off the user"

Why in hell should the user need to be aware that a file is executable? It is the computer the one that decides what to do with the file when the user double-clicks on its visual representation, so it is the computer the one that needs to know about that, not the user.

"If the extension is hidden, or if the OS determines file-type "magically" and doesn't use extensions, how can you tell at-a-glance?"

Why should I need to tell at-a-glance? I don't mean to be unpolite, but you are so deep on Windows prejudices that you take "the usual Windows behaviour" as a must instead of what it is, a made up convention (and by the obvious results, a bad, easily exploitable one).

"Yeah, hiding extensions is a bad move on Windows, but anything that obscures the file type is a bad move on any OS."

Why is it then that I haven't had a problem in years (decades) on Unix-like systems where there's no way to say what a file content and intention is at-a-glance?

Re:Problem?

[Anonymous Coward]

The Mac already does this. If you _do_ have both apps installed it should open in the one which created it

No, it should open in the one I specified for that type.

This is assuming that "one application per file type" is a good idea, which the article and many other comments point out is very problematic.

Ideally, there should be a default application for a file type (easily selectable by the user), and an option to set files of a given type to either A) open with the default application or B) open with a user-specified application. Each file should individually have the option of overriding the default setting.

Thus, you could dictate "all JPEGs open in Preview, but PNGs open in the application that created them" and be able to preserve the creator information for JPEGs, to that you can restore them to opening with the creator app easily. Apple completely dropped the ball on making this process consistent and easy for the user to specify.

Re:Problem?

[gabebear]

Actually all the AVIs play in Quicktime, but for some reason the aspect ratio is wrong on some of them (16:9 plays as 4:3). Perian gives you pretty much every codec from VLC.

http://perian.org/

Re:Problem?

[clone53421]

Each file should individually have the option of overriding the default setting.

No, they shouldn't. Overriding the default setting is easy enough as it is: right click and select a non-default opener. It takes one extra click and removes any question as to which app is going to launch to open the file. Anyway, if you want a override-default flag on the files themselves, I want a global override-override-default to dictate that regardless of what app a file says to open it with, the default app is going to be used, like I said it should. Currently, that's impossible.

Thus, you could dictate "all JPEGs open in Preview, but PNGs open in the application that created them"

No, you can't! JPEGs without opener codes will open in Preview. Furthermore, there's no readily-apparent indication of what the default opener for a file is. You have to go into its properties to find out whether it has one.

And yes, I just said exactly the same thing as I said in my last post.

Re:Problem?

[Doctor O]

It's always the same ignorance and know-it-all. *sigh*

You still don't need to know what it was created by.

Yes you do. Look at this file, called "whathefark.eps". What is it? An Adobe Illustrator file with layers and stuff which can only be processed in Illustrator? Or a Quark EPS export file, which is useful for nothing except for being placed as an image inside of Quark XPress? Or maybe a Freehand EPS, only editable in Freehand? It might as well be a Photoshop bitmap image saved as EPS to keep the clipping paths (which none of the above applications can edit).

There are lots of ambiguous file formats. In case you haven't noticed, .doc is one of them. Try to open, for example, a Word for Windows 2.0 .doc file containing styles and images in the newest version of Word, and be surprised how different the same file can look.

Knowing in which application (and which version of it) a file was created (and should be opened in when double-clicked) is part of what made the Mac the superior publishing platform it used to be. If Apple really has removed this feature, it would be a huge step backwards, and only to remove a PEBKAC effect.

Amazon is fucking up my Snow Leopard delivery, so I can't test it myself, but I imagine that applications still can set their creator codes if they insist on it. After all, it's a FS feature.

Re:Problem?

[Anonymous Coward]

Overriding the default setting is easy enough as it is: right click and select a non-default opener. It takes one extra click and removes any question as to which app is going to launch to open the file.

But I'm not talking about that - I'm talking about the difference between file-based defaults and creator-based defaults. When you're bypassing the mechanism, it doesn't matter which code you use to determine the default.

I'm saying that the "global" application default should be separate from the file's default, which should be based on the creator code unless the creator is unknown, in which case it should be based on the file type. All this should be easily determinable and selectable by the user.

Anyway, if you want a override-default flag on the files themselves, I want a global override-override-default to dictate that regardless of what app a file says to open it with, the default app is going to be used, like I said it should. Currently, that's impossible.

Then I want a global override to your override override! <g>

Thus, you could dictate "all JPEGs open in Preview, but PNGs open in the application that created them"

No, you can't! JPEGs without opener codes will open in Preview. Furthermore, there's no readily-apparent indication of what the default opener for a file is. You have to go into its properties to find out whether it has one.

You can't right now, because there's no obvious difference between the "global" default app and the file's default app.

Anyway, I think we're really in agreement except for the issue of whether the OS should default to a file-type global default or creator-type.

When you choose "change all" for a file of a given type, the system should prompt you whether you want to use the "global" default for all files of this type. Then it would behave as you suggest - no exceptions for individual files. The "open with" selector would then be grayed out until you uncheck that box and return to creator-based selection for that file type. That's what I meant by "each file having an individual override setting" - you don't have to go into system preferences to change it.

Re:Problem?

[ThrowAwaySociety]

So let me get this straight.

Fail. The GP was saying that he'd set all AVI files to open in VLC. In spite of that, some would open in QuickTime anyway because that's what the creator code indicated, which confused the GP greatly because he didn't know that such a mechanism existed.

Epic fail. How did those creator codes get set? He had to have changed them himself. There's no magic creator code fairy that sprinkles creator codes around.

Re:Problem?

[Just Some Guy]

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.

The new logic replaces that with "use the default program unless the user specifically set that particular file to open with something else".

Re:Problem?

[Anonymous Coward]

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.

Exactly - this is where Apple dropped the ball. They added the "Change All" button to make it possible to set the default application for a file type, without any indication that the creator code trumps the setting. In fact, in Mac OS X to date, it has truly been impossible to universally set the default app by file type!

Re:Problem?

[bhiestand]

You could have just said "Quicktime". It's a terrible player, and I wish I could remove it entirely. I play my music in iTunes, and I play my videos in VLC. Period.

Re:We Know Best

[nine-times]

Just to explain this, for me where I really think this is an issue is not text as much as graphics. I work with graphics and often enough, the application that created the graphics is Photoshop. However, I never want to actually open the file in Photoshop unless I actually want to edit it. Why open a JPEG in photoshop when it's going to take a full minute to load?

So I've set Preview to be the default application for viewing graphics, but still, any graphics I make in photoshop are set to open in Photoshop. If Snow Leopard is going to ignore that it was made in Photoshop and open it in Preview instead, as I've set the OS to do, that seems like a "bug fix" to me.

quicktime

[e**(i pi)-1]

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!

Re:quicktime

[AndrewNeo]

I'm sure Apple would rather sell you a (more expensive) version of Final Cut or somesuch instead, anyway. I was disappointed to find out they took the Pro features out of Quicktime X, and had to make do with iMovie in a limited timespan.

Re:quicktime

[Ma8thew]

Don't worry. Apple had to do a complete overhaul of Quicktime at some point, given that it is almost 20 years old. Although it's missing features at this point, they'll return. The biggest user of Quicktime on the Mac is Apple themselves, in Final Cut. That gives them a big incentive to get Quicktime X up to Quicktime 7 standards.

Re:quicktime

[e**(i pi)-1]

The nice thing about QT pro is that it is fast and small. I can edit and trim a movie in the time final cut etc has started up. I like small, minimal and powerful tools. Anyway, the QT episode had the effect that the transition from Leopard to Snow Leopard had a rather chilly effect on me ...

Re:quicktime

[larry bagina]

Half the reason to use a Mac is software that's also available for Windows?

Re:quicktime

[larry bagina]

Quicktime X is a total rewrite, so it's not a matter of removing functions so much as not adding them yet. But if you want to use Quicktime 7 (pro) why don't you use Quicktime 7 (pro)?

Re:quicktime

[Anonymous Coward]

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

Ummm... you can set quicktime files to automatically open with Quicktime Player 7... what more do you need?

Re:quicktime

[mdarksbane]

According to the Ars write-up, the features are missing because Quicktime was completely rewritten to be a more modern codebase. Among other things, this was required to be able to get it to run on the iPhone. Unfortunately, this also means that some features are still missing. Apple has told developers that they intend on bring Quicktime X back to the level of Pro soon.

Also, some of the awesome features of Quicktime Pro were so embedded in the system that they caused a real problem for movie viewing. Most media formats stream data in a way that quicktime doesn't like - it wasn't to know when the beginning and end are so it can do all of its fancy frame-by-frame selections. So if you read in a divx avi file with an mp3 soundtrack, it had to load the entire file, generate its editing information, and convert it to a .mov in the background to even play it. Hopefully they can find a way to do the best of both worlds in the new version once it finally gets up to snuff.

Re:quicktime

[markringen]

quicktime x isn't finished yet..

Re:quicktime

[alanQuatermain]

...if you read in a divx avi file with an mp3 soundtrack, it had to load the entire file, generate its editing information, and convert it to a .mov in the background to even play it. Hopefully they can find a way to do the best of both worlds in the new version once it finally gets up to snuff.

Actually, the issue around that is that the original QT code always generated all that information, because there was no concept of a 'playback-only' stack there. In QuickTime X there *is* that concept, so this information gathering can be skipped completely. At present, QTKit enforces this, so to get the cleaner and more advanced QTX playback rendering engine you can initialize a QTMovie for 'playback only' purpose, at which point the movie will be initialized using the QTX stack. If you want editing, it'll launch using the QT7 stack (or as a proxy to a 32-bit background service, if your application is running in 64-bit mode).

Re:quicktime

[Toonol]

In fairness, Apple's software ported to Windows nearly uniformly sucks, so it may still be a selling point for Macs.

Re:quicktime

[Col Bat Guano]

Hopefully they can find a way to do the best of both worlds in the new version once it finally gets up to snuff.

Personally I don't want to watch up to snuff movies, thank you very much!

Re:quicktime

[mdarksbane]

What I meant was that hopefully future version of QTX will be able to handle this directly instead of hacking it off to QT7.

Re:quicktime

[Anonymous Coward]

Quicktime 7 is still there in SnowLeopard, just moved to the utilities folder. so you can still "get in deep" with channels layers etc...

-Si

Re:quicktime

[Ma8thew]

It seems fairly obvious that that will happen. I don't think Apple likes keeping an ancient piece of 32 bit only code hanging around any more than the end users do. Especially since they rely heavily on Quicktime in Final Cut.

Re:quicktime

[Adm.Wiggin]

I usually describe it as "Viral". It sinks its grimy teeth deep into your system settings and requires someone with at least some technical understanding to change that. (Disable the tray icon, not take over all media files, etc.)

Re:quicktime

[arminw]

....An other reason for the current limitations...

is that Apple has only made a small portion of Quicktime 64 bit. As they get around to doing the rest, they will not use quicktime 7 which is old carbon based and only 32 bit. That is why Snow Leopard has the old version also still. The new quicktime is all written in cocoa.

Re:quicktime

[LanMan04]

It's a good thing that when you're upgrading from Leopard to Snow Leopard, and have Quicktime 7 Pro installed, the system gives you BOTH QT X and QT 7.

Re:We Know Best

[DudeTheMath]

It's the developer, not the end user, that applies the creator code that's being ignored (I can't remember the last time I manually changed a creator code--it was long before OS X, anyway). The end user can always do a "Get Info" to change the default app for any individual document.

That said, I agree that it's a pain to have to do that for every specific document you want opened with a particular app; I just saw a nit that needed picking.

An error in TFA

[Shin-LaC]

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

Re:An error in TFA

[superdana]

Well, strictly speaking, a UTI is a burning need for cranberry juice.

Not the UNIX way

[McDutchie]

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.

Re:Not the UNIX way

[clone53421]

a document will always be opened in the application with which you've created it

It will, if you save it in the appropriate format. If you use a generic format like JPEG, it should open in a generic JPEG viewer (e.g. Preview) by default.

Re:Not the UNIX way

[AndrewNeo]

While you are right that file extensions are not the UNIX way, from TFA and the other comments, it seems OSX uses Uniform Type Identifiers (a variant on MIME types) to identify files, rather than by their extension or creator code. I would assume extensions are still used When All Else Fails (for example, when reading files from FAT32 with no metadata attached)

Re:Not the UNIX way

[Attila Dimedici]

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.

Suppose I don't want the file to open in the application I created it in? I know of several applications that I only want to open a document in when I want to edit the document, the rest of the time I prefer opening the document in alternative applications.

Re:Not the UNIX way

[magnusrex1280]

I *don't* always want a document to open in the application that created it, thus this change in the OS is a great improvement. Knowing (or being forced to accept) that a document will always open in the app that created it hardly seems like a power user situation. It seems more like a casual user situation, where the user doesn't understand the underpinnings, and just wants the document to open however the OS says it should open.

Re:Not the UNIX way

[clone53421]

I know, I know! You could have a sort of hidden menu, attached to that file, with options like "Open" and "Edit" and "Open With..."

Re:Not the UNIX way

[IntlHarvester]

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

Let's be clear - under-the-hood, *nix does not have any standardized way of tracking file types. Unlike MacOS/OSX, there's no type metadata stored with the file.

However, there are many *nix applications which use file extensions. Apache, for example, uses extensions to map to MIME types. Is this because the authors of Apache were enamored with CP/M? Or because there's no other practical way to handle it in standard unix?

Re:Not the UNIX way

[McDutchie]

Let's be clear - under-the-hood, *nix does not have any standardized way of tracking file types. Unlike MacOS/OSX, there's no type metadata stored with the file.

That is correct, but there is a standard way of determining the type of a file without tracking it: the 'file' command (which uses metadata stored in /etc/file/magic). For most applications this would be perfectly practical.

However, there are many *nix applications which use file extensions. Apache, for example, uses extensions to map to MIME types. Is this because the authors of Apache were enamored with CP/M? Or because there's no other practical way to handle it in standard unix?

In Apache's case I'm actually inclined to the former. Using /etc/file/magic would probably be an unacceptable performance hit for a webserver. At least, it would have been when the web started.

However, for most other applications, I think it's because people think of the DOS/Windows way as the "only" way. It's unfortunate. Extensions are unreliable; it's easy for a file to have an extension that doesn't correspond with its format. Also, they can easily be exploited by malware (like file.jpg.exe, which will hide the .exe). Actually inspecting the file itself to determine its format, like the 'file' command does, is safer and more reliable.

Of course that still wouldn't give us classic Mac-like functionality, in which not only the file format but also the application that created the file was tracked.

Re:Not the UNIX way

[Tetsujin]

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

Let's be clear - under-the-hood, *nix does not have any standardized way of tracking file types. Unlike MacOS/OSX, there's no type metadata stored with the file.

However, there are many *nix applications which use file extensions. Apache, for example, uses extensions to map to MIME types. Is this because the authors of Apache were enamored with CP/M? Or because there's no other practical way to handle it in standard unix?

Depends on what "standard unix" means...

There are other approaches to dealing with file types on Unix, of course. These days there's things like xattrs which could be used to store the file type, or (if one is willing to waste the time) there's always file magic...

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

Re:Not the UNIX way

[Jeremy Erwin]

Matlab and octave use .m files for scripting. Objective C class files also use .m. It's annoying when xcode opens up matlab files, but an editor suitable for working with matlab files is suboptimal for Objective C files. Yes, I know emacs supports objective C, but xcode is easier to work with.

Re:Not the UNIX way

[IntlHarvester]

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.

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.

Re:Not the UNIX way

[Sandbags]

A cross-over solution was needed. Keep the functionality. If you created the doc in an app, you shouold expect it to open in that app if you still have it insdtalled. Same if someone sends you a word doc, you'd expect word to open automatically if you have it installed. However, we needed a solution for not-installed or default appications as well. If someone sent me an XLS document, but I don;t have office installed, i got an error, not a set of options... Users need it both ways.

Let me set a defualt. Let me have an alternate option (say, use a 2 finger double click to open that instead opens using the prefered app instead of my default selection. Now if I open the app in my default, ind it translated poorly, i simply close it, then 2 finger double click to reopen in the originating app.

Go a step further, publish the universal list of type/creator strings, and through an online resource, provide me a list of apps available online that can open the offending file if I do not have a compatible reader/editor.

For files that "belong to" and are not "created by" a program (associated installed binaries, graphics files, and program subcompoenets), the creator should be encoded so i allways know what app put those files on my system.

Re:Not the UNIX way

[Anonymous Coward]

Join the club. For me there is less and less reason to use new versions of Windows as Microsoft keeps progressively emulating Apple. I guess us extremists are going to get squished out of a compromised middle.

Re:Not the UNIX way

[goodmanj]

In theory, OSX uses MIME types. In practice, it often doesn't. If I have Preview set up as my default PDF viewer, and I take an ordinary PDF file and change its extension from ".pdf" to ".doc", it might try to open in Word. Or in Acrobat Reader. Or Illustrator. Lord only knows.

The argument for creator and type indicators for files would be a lot stronger if OS X had a coherent type system that actually worked. In practice it's got at least two overlapping systems.

I'll be happy to have *one* that works, whether it's a relic of CP/M or not.

Re:Not the UNIX way

[IntlHarvester]

The problem with 'file' is that it's system-dependent. If I create a new file type ("application/x-intlharvester"), there's no way I can transfer that across a random *nix system without losing the type info ... unless I also use a file extension.

So while extensions are not really the Unix way, Unix doesn't give you any other way either.

Re:Not the UNIX way

[Anonymous Coward]

[Rolls eyes] I know you're trying to be funny, but Mac OS X users have had something like that since, oh, version 10.2 or maybe earlier. If you right-click or control-click on a file, you are presented with a menu that includes "Open" and "Open With...", the former opens the file with the default application and the latter provides a list of applications that can open that file type, or you can pick "Other..." at the bottom of the list (and it's much more reliable than Window's usually brain-dead guesses about which applications can open a given file type, so, unlike Windows, you don't have to resort to "Other..." and then hunting for the program half the time). "Edit" is kind of superfluous when you can pick whichever you want.

PS: "Open With..." is enabled by default, unlike in some versions of Windows.

Re:Not the UNIX way

[clone53421]

I know, and I know, and yes, I'm just suggesting that maybe this clever trick was a better idea than hiding some option in the file properties where most users won't ever find it.

and it's much more reliable than Window's usually brain-dead guesses about which applications can open a given file type, so, unlike Windows, you don't have to resort to "Other..." and then hunting for the program half the time

FWIW, Windows only does that the first time. It remembers your selection and includes it in the Other list for files of that type in the future.

Re:Not the UNIX way

[Guy Harris]

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

(Actually, CP/M picked them up from various DEC OSes, such as TOPS-10, so they're older than that.)

And KDE, and possibly GNOME, also use file-style mechanisms to identify files based on their content; when my main desktop was FreeBSD+KDE, my PDFs, for example, had no file extension (so that the file names didn't have an ugly ".pdf" at the end), but I could double-click on them to open them. When I moved to OS X, I had to put the ".pdf" back (at least I can tell the Finder not to bother me by showing it).

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.

That's because "the under-the-hood UN*X running any of them" doesn't know about the file manager, Portable Document Format, or double-clicking on documents. The "under-the-hood Windows kernel, kernel.dll, and low-level graphics and widget layer" that the Windows desktop is built on doesn't know about that sort of stuff, either.

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.

Well, functionality that some users have always depended on. Apparently, other users have at least wanted to have documents opened by the standard viewer for that document type, regardless of the application with which it was created. I.e., I think this is a case where particular people can argue passionately in favor of the system working the way they like, convinced that it's the "right" way; unfortunately, once you have two groups of people, each convinced that their way is the "right" way, and the two ways are different, you might have to choose to piss one of the two groups off.

Re:Not the UNIX way

[konohitowa]

I think you're possibly overstating things out of frustration, and I pretty much agree with some of your points. However, I'm relatively certain that file name extensions are a PDP/TOPS-10 thing (and later PDP/DOS-11/RT-11 followed by VAX/VMS) that CP/M copied along the way. In much the same way that C and 68xx/68xxx copied the DEC instruction set.

Some of the issue is that Apple does have to live in a DOS inspired world, where files are flat and extensions embed information. Although I think I might have read that in a Linux README.txt file somewhere.

Re:Not the UNIX way

[Anonymous Coward]

The fact of the matter, as illustrated so well by the foo.c/foo.o example, is that there are conceptual entities where the type is a significant part of its identity. You want to be able to see their inter-relationships by common name prefix but also distinguish them with separate names. An ideal system will have both type encoded into name and proper type metadata on hand to inspect for truth. The same problem is happening on the web, where HTTP allows "representation type" to be requested in request headers, but you often want to be able to pass around a URI to a specific representation, i.e. bake that aspect of the request into the name itself.

Eventually you tie yourself in knots on issues like this and then realize it is all arbitrary. I could use some other namespace technique such as foo/o and foo/c to store the separate representations of my foo C program module, and really it wouldn't matter at all to well behaved applications whether that meant separate files with a "/" in them, or separate files under a directory called foo, or even seperate forks in a single resource called foo.

There are many ways to name the same collection of entities with inter-relationships. The alternative to our capricious hierarchical file systems is to have a graph of objects with many different application-oriented normalizations but no inherent canonical name for the objects. I am sure that before too long someone will propose something preposterous like an RDF filesystem and using SPARQL queries to select files by their inter-relationships. I will probably take up drinking again if that happens.

Re:Not the UNIX way

[Tokerat]

If I have Preview set up as my default PDF viewer, and I take an ordinary PDF file and change its extension from ".pdf" to ".doc", it might try to open in Word.

Not sure how it is in Snow Leopard (I'm still PPC), but I'm pretty sure when you change the filename extension, the Finder switches the UTI if it's known.

Filename Extensions where added to aid in compatibility with URL based documents, which also have a MIME system but can't seem to lose the extensions. We've had a viable alternative for 25 years, people. This is one idea I'd wouldn't talk any shit about if Microsoft stole it and everyone jumped on the bandwagon (well, maybe an "about f'n time!" or two).

Re:Not the UNIX way

[bill_mcgonigle]

The problem with 'file' is that it's system-dependent. If I create a new file type ("application/x-intlharvester"), there's no way I can transfer that across a random *nix system without losing the type info ... unless I also use a file extension.

So while extensions are not really the Unix way, Unix doesn't give you any other way either.

We should say it's not yet prevalent. I think you could use, e.g. ReiserFS or ext3+ user_xattrs and rsync to do that, no problem.

But, maybe cp doesn't work. Or anything using libc, or most applications. Perhaps if Apache, Mozilla, GNOME, KDE, and GNU all jumped on the concept simultaneously, it could get some traction. Trouble is, most people who haven't worked in a high-network-value System 7(8,9) environment don't get how useful preserved metadata is. OK, the BeOS guys do. All six of them.

Apple's cathedral approach was actually useful on this one (maybe it was a spill-over from PARC). But with that lineage, old DOS geeks will typically laugh at the idea based on composition alone.

Re:Not the UNIX way

[IntlHarvester]

Eventually you tie yourself in knots on issues like this and then realize it is all arbitrary

Yep. (People lower your thresholds to read the above post.)

Re:Not the UNIX way

[Anonymous Coward]

Because it's the fastest way. You can actually look up the type without hitting the disk at all (because you have the file name from the request).

The Unix way is magic numbers, a system quite similar to the Mac type codes (without the application codes), but placed in the main file, rather than in the resource fork, because Unix doesn't have resource forks.

Re:Not the UNIX way

[Guy Harris]

That is correct, but there is a standard way of determining the type of a file without tracking it: the 'file' command (which uses metadata stored in /etc/file/magic).

(We're talking about Mac OS X, so that's /usr/share/file/magic.)

file uses heuristics to try to guess the file format; most of the heuristics are encapsulated in the magic file. A lot of the heuristics are based on unique or pretty much unique magic numbers, so they're good enough to identify a lot of file types (and Konqueror, as I remember, uses magic as one way to identify file types). They might not be able to identify all file types reliably, however, so they might not be sufficient.

Re:Not the UNIX way

[jp10558]

It would be great for me, though, if I could tell Windows to open a specific file (and saved as copies of that file) in a particular program. I have PDF files I need to open, quite a lot. I generally like to open them in PDF-X-Change Viewer because it supports Tabs and is faster than Adobe Reader in opening a new tab vs a new window, and doesn't seem to get exploited as often.

However, I have one PDF file that contains a form with scripting to do some automated calculations that I have to submit regularly. This only works in Adobe Reader. So THIS one internal form that I trust I need to open, multiple times a week and sometimes multiple times a day, would be nice if it opened in Adobe Reader without the right click, hunt for the open with, hunt for Adobe Reader.

Re:Not the UNIX way

[clone53421]

Right-click –> New –> Shortcut –> "%programfiles%\Adobe\Reader 8.0\Reader\AcroRd32.exe" "form.pdf"
(Adjust for Acrobat Reader version)

Or just keep a shortcut to Reader handy – next to the PDF – and drag the PDF onto it to open it.

Re:Not the UNIX way

[clone53421]

Actually, the "correct" way to do it would be to create a new action for PDF files:

Tools –> Folder Options –> File Types –> PDF –> Advanced –> New –> Action: Open with &Acrobat Reader, Application: "%programfiles%\Adobe\Reader 8.0\Reader\AcroRd32.exe" "%1"

That way, you can right-click any PDF, hit the "A" key, and open it with Acrobat Reader. (If that shortcut letter is already assigned, use a different letter.)

For just one file, though, I'd probably do one of the other things I suggested.

Change for the Better

[Ksevio]

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?

Re:Change for the Better

[99BottlesOfBeerInMyF]

What's the point of making a default application if half the files will ignore it?

The idea was application developers had the power to make files they made open in that application by default and if you didn't like it you could file a bug with the application provider. Now, application providers don't seem to have a way to do this, which many people are unhappy about as they relied on that ability of applications.

The "right" solution is for Apple to have provided a way for applications to claim files and given the user the option to honor or not honor that choice (regardless of the default). This change has lost functionality for some while not giving users or application developers a choice.

Note, I don't really care much on this one as it doesn't really impact my workflow, but I'm generally against changes that remove user choice altogether. Flexibility is good.

Re:Change for the Better

[fulldecent]

This wont affect me, but one problem the new implementation has is that it encourages applications to save in their own proprietary format or with a proprietary file extension.

Re:Change for the Better

[multimed]

Note, I don't really care much on this one as it doesn't really impact my workflow, but I'm generally against changes that remove user choice altogether. Flexibility is good.

But it's not really that clear. It's reasonable to argue that this way gives the user more choice, not less. It will no longer allow application developers to be able to override the user's settings. While your idea of giving the option to honor or not honor the applications claims is a middle ground and allows both, I would think it would add another layer of complexity without getting much in return. If you say, "should OS X allow the App to ignore my settings" you're sort of giving them the choice to give up their right to choose.

Re:Change for the Better

[99BottlesOfBeerInMyF]

But it's not really that clear. It's reasonable to argue that this way gives the user more choice, not less. It will no longer allow application developers to be able to override the user's settings.

Except users (at least competent ones) already had that option. Moreover, even if I except your premise that they're just changing what choice you have, that's still a choice that changes the way things are done now and disrupts existing user's workflows. That is to say, a lot of people depend upon applications making such assignments so there files open in the application they want.

Graphics people in particular are really pissed about this if you read the forums. A lot of them have 5 or 6 different graphics programs they use to edit different types of graphics, photos, paintings, buttons, Images of text, etc. Now they have to completely change how they open all those files because every file has forgotten which program has been opening it for the last 5 years.

If you say, "should OS X allow the App to ignore my settings" you're sort of giving them the choice to give up their right to choose.

I disagree. You're giving them the choice to let the application handle a job for them which they otherwise have to do manually. If users don't like an application making that assignment, even without any option, they can always stop using that program or file it as a bug and developers have a direct, financial motivation to do what the user wants. Hopefully Apple thinks they have the same motivation and will respond to all their upset users and make an official mechanism and user controls.

Re:Change for the Better

[SoupIsGoodFood_42]

When you're talking about usability, choice is not always good. Sometimes it's even lazy. I think the idea was good, but it seems that it confused more than it helped. If that's the case, then I think Apple made the right decision. Flexibility can be good, but so can clear behavior.

Re:Change for the Better

[99BottlesOfBeerInMyF]

When you're talking about usability, choice is not always good. Sometimes it's even lazy.

In this case there was an option to let the application handle the work instead of the user. Now, the user has to manually manage it. I agree that unneeded choices can be problematic, but users are losing real functionality here, which some professionals depend upon.

I think the idea was good, but it seems that it confused more than it helped.

There is no doubt that there was confusion created by Apple's inconsistent handling of file identifiers (three mechanisms per file) and lack of accurate documentation. Further, while I have no problem with their changing the default, when you do that it's nice to give advanced users a control to easily make things work they way they have been, even if it is on a per application basis.

Flexibility can be good, but so can clear behavior.

I have no problem with Apple clarifying the behavior or changing the default. What's clear to me though is now many users have to do more work to get the same result. They have three choices:

• manually change the setting on each file every time they create a file.
• learn some obscure scripting to do the same and then run that script regularly while experiencing random problems for newly created files; or hope a third party writes something to fix this.
• stop opening files by double clicking on them since that behavior is now broken for their workflows.

I've actually worked as a usability testing expert in the past, so I'm not unfamiliar with this sort of situation. I feel Apple handled it poorly and basically decided to ignore current power users such as graphics pros. It doesn't really affect my workflow, which is nice, but Apple should really address this failing and provide an option for application developers and users alike. There's no reason users should have to do all the heavy lifting manually.

Re:We Know Best

[poetmatt]

I think I read from the article that there's a way to set it for all existing files, although I think it's a total PITA method. More acronyms.

Maybe someone will (sadly), have to create an apple app/script that will do this every reboot, or something?

Even better.

[Bill, Shooter of Bul]

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.

Re:Even better.

[clone53421]

The only meta-data attached to a file sent by e-mail is the extension and the mime-type. If your default .doc opener is OO.o, it should work fine.

You'll only see this problem when you get files in storage formats that support file meta-data. Some compression formats support it, and removable storage may or may not.

Re:Even better.

[Bill, Shooter of Bul]

I think I may have been thinking about files extracted from a dmg. You're right email probably would strip those out.

Re:Even better.

[Anonymous Coward]

Most OS X mail programs have an option to encode the Macintosh metadata (as AppleDouble or BinHex).

e.g. in Apple Mail, disable "Windows Friendly Attachments".

Re:We Know Best

[Millennium]

Apple is off-base because they had a superior technology that was robust enough to at least be able to survive something as basic as a filename change. But it seems that, as has been typical for them over the last decade or so, they've gone with cheap-over-good yet again.

This is why I got off the wagon. If I'm not going to get anything better from a Mac than anything else, then I'll at least get my money's worth out of another system.

Re:We Know Best

[jedidiah]

They are going out of their way to break things for users that might have actually used this feature in the last 25 years.

This is a great example of "consistency over time" being more important than trivial details between different apps.

That said, a decent file manager makes the point moot. If you don't want to use the default file handler, you can setup others and use them as you see fit.

Re:We Know Best

[TheRaven64]

This isn't the default application. Documents now open with the application that is set as the default, not the application that happened to be set as their creator code. This now means, for example, that the PDF manual for Final Cut Express 2 will open with Preview (because that is my default application for displaying PDFs) not with Adobe Reader (because Acrobat 5 was set as the creator code when it was produced).

Re:We Know Best

[nine-times]

I think I read from the article that there's a way to set it for all existing files, although I think it's a total PITA method.

Sure, but I don't want to continually set the proper application for a given file-type. I want to set one default, and have the OS respect that decision unless I manually set a different application for a particular document. I think that's the proper behavior.

File Association Hijacking

[ThrowAwaySociety]

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.

Re:File Association Hijacking

[clone53421]

It prevented the common Windows practice of "hijacking" another application's file extensions.

That's a feature, not a bug. If I install a new app, I want it to open such-and-such file types. The only problem is apps that silently re-associate themselves with all their file types when they open, and anyone who writes such an application should be flogged and rubbed with salt IMHO.

Having your file types stolen by another application should be responded to with a warning popup specifying the file type(s), the apps with which they're now associated, and giving the following options: (1) Reassociate the types. (2) Don't reassociate, and stop checking these file types. Yes, popups are annoying as hell, but if two apps are fighting over the file type you'll only see the warning twice: once from each app. Consider it part of the installation process.

Re:File Association Hijacking

[ThrowAwaySociety]

It prevented the common Windows practice of "hijacking" another application's file extensions.

That's a feature, not a bug. If I install a new app, I want it to open such-and-such file types. The only problem is apps that silently re-associate themselves with all their file types when they open, and anyone who writes such an application should be flogged and rubbed with salt IMHO.

Having your file types stolen by another application should be responded to with a warning popup specifying the file type(s), the apps with which they're now associated, and giving the following options: (1) Reassociate the types. (2) Don't reassociate, and stop checking these file types. Yes, popups are annoying as hell, but if two apps are fighting over the file type you'll only see the warning twice: once from each app. Consider it part of the installation process.

God, what a mess. You're seriously advocating this behavior? Do you work for RealNetworks?

When I install an app, if and when I want it to open such-and-such file types, I will make that change myself.

Re:File Association Hijacking

[clone53421]

When I install an app, if and when I want it to open such-and-such file types, I will make that change myself.

Never said I don't agree with that. In fact, I do. Give me a list of the file types and let me choose which ones to associate, if any. Do it during installation so I don't have to later.

The scenario I described is what superseded app X should do when it discovers that I installed app Y and changed some files that it thought belonged to it. You really shouldn't even get the warning more than once: If it was a legit change, I only see one warning, and tell it "ignore". If it was not legit (i.e. they were "stolen", not re-distributed by myself), I have it take them back, and I try to find out how to make the offending app (the one that took the associations without my knowledge) stop doing that (uninstalling it if necessary).

It'd be nice if no warning was necessary, but since I don't trust other apps to not steal file types I'll put up with the warning in order to catch the ones that do. As I said, you should only get the warning after you install a new app and re-associate file types.

Re:File Association Hijacking

[Galestar]

But then how would MS get anybody to use Media Player? ie. I opened Media Player by accident the other day, and was annoyed at the welcome screen and just said use standard settings because I wanted to get rid of it. It stole all my VNC associations and I had to reset them. So no, I don't think MS will be doing anything like that any time soon.

Re:File Association Hijacking

[Anonymous Coward]

> That's a feature, not a bug. If I install a new app, I want it to open such-and-such file types.

That's a bug.

If I install a new app, I want its associations to be totally separate from the file formats - like with the old Type/Creator codes!

Re:File Association Hijacking

[Tokerat]

That's a feature, not a bug. If I install a new app, I want it to open such-and-such file types. The only problem is apps that silently re-associate themselves with all their file types when they open, and anyone who writes such an application should be flogged and rubbed with salt IMHO.

Having your file types stolen by another application should be responded to with a warning popup specifying the file type(s), the apps with which they're now associated, and giving the following options: (1) Reassociate the types. (2) Don't reassociate, and stop checking these file types. Yes, popups are annoying as hell, but if two apps are fighting over the file type you'll only see the warning twice: once from each app. Consider it part of the installation process.

That would be good, but someone should really invent a system with some kind of flag in the file that would tell the OS which application to open the file with, unless the user specified another by right clicking, or setting the designation permanently from the Get Info window.

Re:File Association Hijacking

[cbhacking]

If you sincerely think that the average user is happier to hunt down a option somewhere in their new program that sets what file types it opens (as opposed to being presented with a one-time dialog during installation) you are so far out of touch with the reality of how people use computers that I honestly can't help but wonder if you're just trolling. Real *used* to just hijack all the extensions (I don't think it does anymore, but I can't say for sure as I don't use it) but a one-time dialog makes perfect sense. Do you walso think that every time you install a new web browser, it shouldn't have an option for making the newly-installed browser your default?

Besides, you're still not addressing the main point of the GP. On a Mac, you're not even able to set those defaults. They're part of each file's metadata, editable only on a case-by-case basis. If a file happens to lack such metadata you can change what the preferred fallback is, but you can't say "I just installed VLC because I like it, now make all my media open in it."

Re:File Association Hijacking

[bar-agent]

Having your file types stolen by another application should be responded to with a warning popup specifying the file type(s), the apps with which they're now associated, and giving the following options: (1) Reassociate the types. (2) Don't reassociate, and stop checking these file types. Yes, popups are annoying as hell, but if two apps are fighting over the file type you'll only see the warning twice: once from each app. Consider it part of the installation process.

That would be good, but someone should really invent a system with some kind of flag in the file that would tell the OS which application to open the file with, unless the user specified another by right clicking, or setting the designation permanently from the Get Info window.

Hm, yeah, that would be good. We could call it a "creator code." Seriously, that's what we already had (except for the highjack warning) until Snow Leopard, apparently.

Re:File Association Hijacking

[Anonymous Coward]

Bugs in Apples are features

Re:File Association Hijacking

[clone53421]

That would be good, but someone should really invent a system with some kind of flag in the file that would tell the OS which application to open the file with, unless the user specified another by right clicking, or setting the designation permanently from the Get Info window.

With the exception of the last thing, the file type does that. As far as the last one is concerned, I think it's a bad thing. It should be obvious which application is going to be used to open the file.

It actually works just fine

[dbet]

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.

Re:It actually works just fine

[99BottlesOfBeerInMyF]

I think the complaint is that apps in 10.6 are not flagging their own documents to open with themselves.

That is not the complaint in the article. The complaint is that Apple removed the old way applications flagged documents to open in themselves and does not seem to have provided any way for applications to do that using the new method. Rather, applications can tag documents, but the user must still go through and select the files by hand or using a non-obvious script to open in the application after each file is created. It could be that the article writer is mistaken and there is such a method, but no one has yet pointed it out that I've seen and the documentation from Apple is vague and does not seem to provide a method.

Re:It actually works just fine

[pongo000]

The complaint is that Apple removed the old way applications flagged documents to open in themselves and does not seem to have provided any way for applications to do that using the new method. Rather, applications can tag documents, but the user must still go through and select the files by hand or using a non-obvious script to open in the application after each file is created.

Huh...I have to do that under 10.3.9. What, exactly, has changed?

Re:It actually works just fine

[99BottlesOfBeerInMyF]

Huh...I have to do that under 10.3.9. What, exactly, has changed?

In 10.0-10.5 Photoshop or BBedit or some other program can set itself as the default for files it creates, when it creates them, so the next time you double click the file, it opens in Photoshop or BBedit.

In 10.6, those programs can no longer set themselves as the default program. That means you can set all text files to open in TextEdit or all to open in BBedit, but if you want most files to open in TextEdit but the ones you create in BBedit to open in BBedit, you have to go through each file after you create it in BBEdit and set it to open in BBedit. There is no way for BBedit to set itself as the default for a specific file when it makes it.

Re:It actually works just fine

[Anonymous Coward]

Mod parent up. In all of the discussion so far, this is the first comment I have seen that succinctly states the problem.

Creator codes have been deprecated since 10.4

[bonch]

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.

Re:Creator codes have been deprecated since 10.4

[bonch]

Hmm. Why was I modded off-topic for linking to UTIs, introduced in Tiger, which describe types without using file extensions or creator codes?

Re:Creator codes have been deprecated since 10.4

[ThePhilips]

But UTI is in no way a replacement for a creator code.

The most useful aspect to me was that one can tell that the particular file has to be opened by different application.

E.g. for most of smallish stuff I'm using QuickTime Player. But most of my movie collection is marked as to be opened by MPlayer. Files types are the same - but different applications are used to open different files.

Or bigger (to organization of my personal information) example are plain text files. On my Mac OS X MacVim is used as default editor. But I also have number of text files which I open and print only from TextEdit.

Creator code was allowing to set non-default application to open the file.

P.S. That was BTW one of the most missed features when I worked under Windows: allow shortcuts to have customized application and customized action for opening the file. After gaining access to Macs I naively thought it was another cool feature. It doesn't look like an ancient artifact to me.

Re:Creator codes have been deprecated since 10.4

[ThePhilips]

Oh... I digress. The RTFA explicitly says that Finder's "Get Info" window still allows to change application to be used to open the file. IOW, I'm on safe side as it is how I usually do it anyway.

P.S.

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.

If Apple did it right, then I'm pretty sure one can programmatically change the per-file association. Or probably even with the AppleScript.

After RTFA it seems to me the issue was greatly exaggerated.

Re:Creator codes have been deprecated since 10.4

[digibud]

From what I gather it is NOT easy or possible to duplicate the functionality that existed previously. I have tens of thousands of images. One huge nicety of Mac OS has always been my ability to allow a family member open a jpg in something like Adobe PhotoDeluxe and work on it with that program and save it, then double click on it and have it open in that program, while I do similarly with Photoshop and it will open properly in Photoshop. I now have thousands of images that open in this program or that program...even some that are only used in Final Cut Pro that I can double click on and FCP will then open. I don't think there is any way to transition so my old ability to double click and have the correct application open for all these thousands of files. If I had never taken a picture or written a .txt file with BBEdit it would be less of an issue. But this change would have a huge impact on my workflow and over time would cost me a lot of wasted time. This is one update I will pass on and for me a it's a huge loss of functionality that just drives one more wedge between me and OSX.

Re:Creator codes have been deprecated since 10.4

[melatonin]

If Apple did it right, then I'm pretty sure one can programmatically change the per-file association. Or probably even with the AppleScript.

No, they didn't do it right, they just chopped the functionality out. This is determined by the launch services database and the LaunchServices framework. The only thing you can use to "set" something using LaunchServices is the function LSSetItemAttribute, which only supports kLSItemQuarantineProperties. There's also stuff like LSSetExtensionHidden, but they didn't add anything for this.

There is no way to programatically influence what application a file should open in when running on Snow Leopard, and there was before. This is a significant loss of functionality. Text files are a great example of this; if I have a set of text files (or even XML) files that I like to create using with BBEdit because of BBEdit's feature set, I want to open them in BBEdit again. I don't want to save one, open an info window in the Finder, and select BBEdit from the popup menu, that's just stupid.

If I'm saving PDF compatible files in Illustrator with a .pdf extension, I still want them to open in Illustrator! Not with Preview or Acrobat.

There are only two ways to set a file type in OS X: using a file extension (which is stupid, but supports the lowest common denominator) or HFS+ meta data (which is actually a good idea, because it's file meta data). There's no new extended attribute where you can set a UTI or other attribute that influences launch services other than quarantine (if you happen to find one, run to the top of a very large hill and yell loudly, preferably screaming the name of the attribute; then put a recording of it on YouTube).

Ideally, you'd have more file-system metadata to determine this kind of behaviour, but the "change" popup in the Get Info window only modifies the .DS_Store file next to the file you're inspecting.

Re:We Know Best

[fuzzyfuzzyfungus]

The trouble, and what seems to be irking the faithful, is that treating documents simply by type leaves no way to treat some documents of a given type in one way, and others of the same type in a different way.

If, for instance, you prefer one graphics program for editing .jpgs and a different one for viewing them you are now screwed. You can either set .jpgs to open in one, or the other; but you can no longer have ones created in photoshop open in photoshop while ones from outside are just opened in a lightweight viewer(or whatever the use case happens to be).

Sort of a niche thing; but sounds like the people who relied on that class of configurations are out of luck.

Re:We Know Best

[mortonda]

My problem is that I cannot seem to set defaults for files without an extension. Some perl scripts for example that look like commands, leave off the .pl extension. My mac wants to execute them instead of opening them in a text editor.

Resources have been gone since OS X

[fermion]

It seems to me that codes such as this has been on the way out since the OS X arrived and began to give credence to the kludgy extension convention. With a resource fork all the data related to a file, it's icon, type, any meta data, was right there. Resedit was always there to help you make any changes.

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.

Is this just half an article?

[pizzach]

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?

Re:Is this just half an article?

[Anonymous Coward]

That's not strictly true. What you're describing is the type code. A Macintosh file has both a type code and a creator code. The type code serves as a general file type, like an extension, but it's stored in the metadata. The creator code indicates what application the file was created with. (In theory, there's a one-to-one mapping between Macintosh applications and their creator codes.)

So, for instance, Word files created with MS Office and Open Office would both have the "Word" type code, but one would have the MS Office creator code and one would have the Open Office creator code. It used to be that the former would open in MS Office and the latter would open in Open Office. Now, they'll both open in whatever the handler is for "Word" files.

Of course, it's more complicated than that. Type and creator codes are more or less deprecated, and filename extensions as type indicators have had to be supported for compatibility's sake for a long time. So the steps that go into figuring out how to open an arbitrary document are no longer simple.

Re:We Know Best

[Overly Critical Guy]

Man, there are a lot of uninformed people posting to this article. Apple has used Uniform Type Identifiers since 10.4 Tiger. Creator codes have been deprecated for years.

Re:We Know Best

[TheRaven64]

Clear the execute bit and it won't try to execute them.

Re:We Know Best

[93 Escort Wagon]

So I've set Preview to be the default application for viewing graphics, but still, any graphics I make in photoshop are set to open in Photoshop. If Snow Leopard is going to ignore that it was made in Photoshop and open it in Preview instead, as I've set the OS to do, that seems like a "bug fix" to me.

Amen! I have always found this behavior annoying for exactly the reason you specify, and this new behavior seems like CORRECT behavior. Just because I edit an image in Photoshop doesn't mean I want to always open that image in Photoshop from then on out - yet that was what happened. And not all applications would reset that anyway - so it seemed to me this was more of an "Adobe being Adobe" thing than a fundamental issue with the OS (Apple's apps did seem to always honor whatever settings I'd made in terms of default apps for photos, text docs, etc.)

So now I'll be curious to see if Adobe pushes out a patch for CS4 that will automatically reassign all jpgs, tiffs, etc. to Photoshop...

BTW I didn't realize this had changed in Snow Leopard - I actually learned something from Slashdot today! Whoa, glad I was sitting down...

Correction

[McDutchie]

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.

Re:We Know Best

[lukas84]

Why open a JPEG in photoshop when it's going to take a full minute to load?

Well, it all makes sense now! It's a conspiracy to sell more hardware!

Snow Leopard Snubs Documentary Creator Code

[Elwar123]

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.

Re:We Know Best

[nine-times]

If, for instance, you prefer one graphics program for editing .jpgs and a different one for viewing them you are now screwed. You can either set .jpgs to open in one, or the other...

Well not exactly. You can still have your default jpeg viewer be Preview, and still have only particular jpegs open in Photoshop. That's easy enough to accomplish. The difference is just that jpegs saved in Photoshop are not automatically associated with Photoshop regardless of the default that the user has set.

And it's not that I fail to recognize how it might be useful to have jpegs created in photoshop always open in Photoshop, automatically. It's just that I don't think it's a very sensible way to handle things. If I really want to use Photoshop most of the time, I can set that as my default jpeg viewer. If I have particular files that I'm opening all the time and want to open them in Photoshop, I can set that manually on a per-file basis. However, when I set a default viewing application for a particular file-type, it's nice for that decision to be honored by the OS.

Re:We Know Best

[Neil Hodges]

The easiest solution is to use the command-line to run the text editor with the script's path as the argument.

Re:We Know Best

[Anonymous Coward]

You can use Quick Look to view documents, regardless of what program would be started when opening it. If Quick Look functionality would be expanded to allow zooming and full-res viewing, the need for a 'viewer' application with filetype bindings would disappear.

Then, you could view the file by hitting space bar, and edit the file by opening it.

Creator should be considered, but in a Unix-y way.

[WebManWalking]

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.

Re: Apple Urinary Tract Infections (UTIs)

[Tetsujin]

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.

Re:We Know Best

[moosesocks]

If, for instance, you prefer one graphics program for editing .jpgs and a different one for viewing them you can now right click, or drag the icon onto the dock.

Fixed that for you.

I do quite a bit of coding and graphic design, and view this as a very good thing.

There are limited use cases in which the old scheme made more sense. However, I find myself right clicking .JPGs to open in Preview more often than the other way around.

Resource fork making a comeback

[yabos]

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

Re:Resource fork making a comeback

[cybernanga]

Not exactly true.

I'm running Leopard at the moment, and when I look at the default apps on a Snow Leopard Drive, they are NOT 0 byte files. They display a grayed out generic application icon with a Circle & Diagonal over them, indicating that they are not usable by Leopard, but the file sizes report correctly both in the Finder, and in the Get Info Window.

The executables show up as 0 byte files in the Terminal, but display correct size information in the GUI.

Strange.

Re:Resource fork making a comeback

[velen]

Why the fuck are you copying John's article from Ars Technica to dropbox and driving traffic to it? Websites like Ars can use the exposure & ad. revenue so people like John can make a living.

The original article is here.

http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars

Re:Resource fork making a comeback

[yabos]

Does it look like I copied it dumbass?

Should open files with the app that was used

[Anonymous Coward]

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.

Re:Should open files with the app that was used

[clone53421]

No, it shouldn't.

I want assurance that an arbitrary JPEG will open in Preview, not Photoshop. Lightweight image viewers were created for a reason. If I want to open it in Photoshop or GIMP instead of Preview, I'll right click it and choose that from a menu, or I'll already have the app open and I'll just drag the file in.

I'm a Windows user, in case you can't tell. Yes, I like the way Windows does this.

(Arbitrary JPEG: one which I got from you on a USB drive, or any JPEG which I don't remember what app I created it in – or don't know whether or not I remembered to reassign the default opener to Preview instead of PS which I apparently must do for every single JPEG I export.)

Just Like Windows

[Nom du Keyboard]

So now OS/X works just like Windows. Wow, what an advance.

WTF ? Unix uses file extensiojns ?

[Anonymous Coward]

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'. :)

Re:WTF ? Unix uses file extensiojns ?

[Guy Harris]

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'. :)

So that means that compiler front ends on UN*X systems run file or equivalent code on source files to figure out what language they're in, rather that treating .c files as C, .cpp/.cxx/etc. files as C++, .f files as FORTRAN, etc? :-)

In addition, whilst I think the major UN*X+X11 desktops might determine file types by doing file-style processing on the file, the OS X desktop, for better or worse, doesn't.

Creator Codes and UTIs

[Anonymous Coward]

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.

Re:We Know Best

[Jeremy Erwin]

"foo.pl" is a perl library. "foo.pm" is a perl module. "foo" is a perl script.

Re:We Know Best

[Anonymous Coward]

The Mac OS type system is absurdly complicated.

Determining the application takes into account:
Creator Codes (4 character codes), the file type determined, the file type code, a piece of metadata known as a UTI, the available applications, the UTI's the applications claim to support, the file extensions the application's claim to support, any application explicit bound to the file, The creator codes the applications claim to support, the version numbers of the applications, the classic/OSX status of the apps, of the app, if the app is on a local or network drive, which local drive the app is on, and a few other things.

The result was that unless you bind a file specifically, or explicitly chose a default program for a filetype, it would normally be opened with the prograqm that saved it, but not always.

One can still explicitly bind an application to a specific file, which will override all other considerations. One can still set the default applications for specific types, Which take precedence over other information, except file specific bindings. File types, UTI's, and (I think) file codes are still in use.

So now generally speaking, the preferred app is: the explictly bound app, the explict default app for the file type, or an implicit default app for the file type which is almost impossible to pre-determine, but remains consistent for all files of that type.

To specify a specific app for a specific file, use Finder's Get Info Dialog for that file. That dialog can be opened through the context menu (among other ways).
To set a default app for a file type, use the open with dialog, and check the "Always Open With" box. The open with dialog can be access from the "Other applications" option in the context menu.

Bugfix

[Frankie70]

It's not a problem, it's a fix. This is the way it should work.

When was the bug reported & why did it take so long to fix?

Re: Apple Urinary Tract Infections (UTIs)

[pizzach]

Thank you. I think I would have enjoyed the summary more if they put less spin on it and included what you wrote. :D

Re:We Know Best

[Knara]

That said, I agree that it's a pain to have to do that for every specific document you want opened with a particular app; I just saw a nit that needed picking.

This is what I was speaking about in particular.

TBH, I can't say it's ever been an issue for me, but still.

Re:We Know Best

[ThePhilips]

I overall agree with you except that:

They are going out of their way to break things for users that might have actually used this feature in the last 25 years.

If you haven't noticed the feature in Mac OS X before it might mean only one thing: it is so well implemented that you hadn't even knew you were using it.

All what have happened in SLeopard is a clean up and making default different system, one similar to e.g. KDE.

Though most important aspect - as I'm concerned - is retained: one can still assign a different application to open the particular file.

Re:We Know Best

[tyrione]

Clear the execute bit and it won't try to execute them.

Correct. We wouldn't want to know anything about Unix file permissions or nothing.

File type identification on Unix

[Tetsujin]

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

Re:File type identification on Unix

[Guy Harris]

I think xattrs are actually part of POSIX

I don't, because I didn't find anything about them in the 2008 Single UNIX Specification, although perhaps I didn't search for them correctly.

I suppose related features like ACLs could help drive more widespread adoption of xattrs

The same underlying mechanism might happen, on some particular file systems, to be used to store extended attributes and ACLS; however, the two are not inherently related.

(though in the kernel the two features are enabled separately, I believe...)

To which particular kernel are you referring?

Re:File type identification on Unix

[Tetsujin]

I suppose related features like ACLs could help drive more widespread adoption of xattrs

The same underlying mechanism might happen, on some particular file systems, to be used to store extended attributes and ACLS; however, the two are not inherently related.

This is how it's done on XFS and on Linux in general... But really the whole "ACLs might help promote xattrs" thing is just wishful thinking on my part. The feature will be embraced when people think they have a reason to embrace it.

(though in the kernel the two features are enabled separately, I believe...)

To which particular kernel are you referring?

Heh, good point...

I was referring to Linux, in particular the features for xattrs and acls are separate on the ext2/ext3/ext4 family of filesystems... I think the situation on BSD is similar.

Re:We Know Best

[tyrione]

Why open a JPEG in photoshop when it's going to take a full minute to load?

Well, it all makes sense now! It's a conspiracy to sell more hardware!

PSD is the native file format in Photoshop. JPEG is a standard output format. Photoshop or any other application like GIMP is overreaching ownership on an operating system when it is not the only application that can natively render JPEG files; hence if I want Preview.app to render them or Safari or Pixelsight, et.al then the .plist association file for that format should be configured and stored in my account's preferences.

Re:We Know Best

[hattig]

I agree. I've usually found myself similarly annoyed when the bulky application loads when you just want to view a file and Preview loads instantly and is thus the natural default viewer.

Certainly the default opening command should be set to the system-wide setting, which by default would be a light weight viewer supplied with the operating system (Preview, Quicktime (well, maybe not lightweight), etc).

Right/ctrl-clicking should open a menu. There it should have "Open (with Preview)" (default application), "Open (with Photoshop)" (creator application), and then "Open with..." with all the other registered handler applications in a submenu.

You could extend this - "Open (to view)", "Open (to edit)" where viewer and editor are default viewer and editor, if different.

The article goes on about applications stealing other application's files. In actual fact they're MY files.

Re:We Know Best

[tyrione]

If, for instance, you prefer one graphics program for editing .jpgs and a different one for viewing them you are now screwed. You can either set .jpgs to open in one, or the other...

Well not exactly. You can still have your default jpeg viewer be Preview, and still have only particular jpegs open in Photoshop. That's easy enough to accomplish. The difference is just that jpegs saved in Photoshop are not automatically associated with Photoshop regardless of the default that the user has set.

And it's not that I fail to recognize how it might be useful to have jpegs created in photoshop always open in Photoshop, automatically. It's just that I don't think it's a very sensible way to handle things. If I really want to use Photoshop most of the time, I can set that as my default jpeg viewer. If I have particular files that I'm opening all the time and want to open them in Photoshop, I can set that manually on a per-file basis. However, when I set a default viewing application for a particular file-type, it's nice for that decision to be honored by the OS.

Another scenario is that files associated in Photoshop sent to you on your machine without Photoshop have to open in something compatible to view them, no? It makes sense to bind native application formats to that specific application and standard formats to be bound by order of precedence you set. This debate is decades old.

Re:We Know Best

[tyrione]

Man, there are a lot of uninformed people posting to this article. Apple has used Uniform Type Identifiers since 10.4 Tiger. Creator codes have been deprecated for years.

Truth to people can be a real bitch I suppose. They could always live like it was 1997.

Finder wasn't left half-done...

[Anonymous Coward]

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.

Re:We Know Best

[Anonymous Coward]

Or, on the command-line:

open -e perlscriptname

Which will open it in your default editor (the -e option). man open for more (e.g., you can specify the application with -a). Since it is common to run scripts from the command-line, I often find open -e faster than fiddling with the mouse, especially with filename completion turned on in the shell. And, of course, depending on your shell, you can usually "source perlscriptname" to run it even if its execute bit isn't set, as long as you've done the #! thing at the top (or just feed to the interpreter).

In the GUI, drag the file onto the relevant application or right-click/control-click to bring up a menu and select the application for editing ("Open With..."). There's always a way.

Re:We Know Best

[nine-times]

Another scenario is that files associated in Photoshop sent to you on your machine without Photoshop have to open in something compatible to view them, no?

I think in those circumstances, OSX is smart enough to figure it out. Like if I created a JPEG with Photoshop and associated the file with Photoshop, and then I sent it to you and you didn't have Photoshop, it would just use whatever your default JPEG viewer was.

Re:We Know Best

[Anonymous Coward]

Drag and drop to the icon for the application you want to open the file.

Re:We Know Best

[Siker]

Yes seriously. I have lost count of how many times I had to force quite Photoshop just to get it to stop loading when all I wanted was to bring up a picture in Preview.

Open = Create | View | Edit | ...otherN

[CarpetShark]

This now means, for example, that the PDF manual for Final Cut Express 2 will open with Preview (because that is my default application for displaying PDFs) not with Adobe Reader (because Acrobat 5 was set as the creator code when it was produced)

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.

Re:We Know Best

[node 3]

My problem is that I cannot seem to set defaults for files without an extension. Some perl scripts for example that look like commands, leave off the .pl extension. My mac wants to execute them instead of opening them in a text editor.

Get Info works just fine for me, as does right-click "Open With"

Re:We Know Best

[jrumney]

I was thinking the same thing for video files. For Documents, the previous behaviour might have made some sense (even then, not for PDF), but for media files where simple lightweight viewers vs complex heavyweight editing programs are the norm, the new behaviour is much better.

Re:We Know Best

[Tirhakah]

To make this easier, you can put applications into the finder toolbar. For example, I have textedit sitting up there for when I want to force a document to open in that rather than, say, Safari for .html files.

Re:We Know Best

[dangitman]

Why open a JPEG in photoshop when it's going to take a full minute to load?

Photoshop takes a full minute to load? What year are you posting from?

You can still install QT 7 Pro

[Anonymous Coward]

On OS X 10.6 look at your custom install options. I did when I upgraded.

No big deal. Rosetta is still there too.

Dumbasses

[RogueWarrior65]

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!

Re:Dumbasses

[clone53421]

Who said anything about 3 characters? HTML much? JPEG? MPEG? TORRENT?

Re:We Know Best

[bhiestand]

Agreed. I hate the fact that I can't seem to do anything to make VLC the default for videos on my computer.... screw quicktime!

YOU don't get it

[ThrowAwaySociety]

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.