Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Snow Leopard Snubs Document Creator Codes

timothy posted more than 4 years ago | from the mind-the-new-mantrap-in-the-living-room dept.

OS X 214

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

cancel ×

214 comments

RIP (0, Insightful)

Anonymous Coward | more than 4 years ago | (#29352241)

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 (3, Insightful)

Jeremy Erwin (2054) | more than 4 years ago | (#29352771)

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

Apple is the worst company in the world (-1, Troll)

Anonymous Coward | more than 4 years ago | (#29352897)

anything they can do that will piss off their customers is fine by me.

Creator codes have been deprecated since 10.4 (3, Informative)

bonch (38532) | more than 4 years ago | (#29352943)

Apparently, everyone has forgotten that UTIs have been in use since Tiger. [arstechnica.com]

By the way, Slashdot, nice job not posting a link to Arstechnica's epic 23-page Snow Leopard review [arstechnica.com] from last week. It's not like they put out the most detailed reviews in the industry or anything.

We Know Best (-1, Flamebait)

Nom du Keyboard (633989) | more than 4 years ago | (#29352283)

We know what's best for you. We're making it just work. Now just sit back and drink your kool aid.

Re:We Know Best (4, Insightful)

nine-times (778537) | more than 4 years ago | (#29352329)

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 (2, Insightful)

Knara (9377) | more than 4 years ago | (#29352373)

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.

Re:We Know Best (3, Informative)

DudeTheMath (522264) | more than 4 years ago | (#29352441)

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.

Re:We Know Best (2, Informative)

TheRaven64 (641858) | more than 4 years ago | (#29352753)

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 (1)

mortonda (5175) | more than 4 years ago | (#29352967)

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.

Re:We Know Best (2, Informative)

TheRaven64 (641858) | more than 4 years ago | (#29353075)

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

Re:We Know Best (1)

Neil Hodges (960909) | more than 4 years ago | (#29353331)

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 (1)

Jeremy Erwin (2054) | more than 4 years ago | (#29353701)

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

Re:We Know Best (1, Informative)

Anonymous Coward | more than 4 years ago | (#29353817)

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.

Re:We Know Best (5, Insightful)

nine-times (778537) | more than 4 years ago | (#29352417)

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.

Re:We Know Best (1)

93 Escort Wagon (326346) | more than 4 years ago | (#29353139)

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

Re:We Know Best (1)

lukas84 (912874) | more than 4 years ago | (#29353301)

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!

Re:We Know Best (0)

Anonymous Coward | more than 4 years ago | (#29353345)

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.

Re:We Know Best (1)

poetmatt (793785) | more than 4 years ago | (#29352597)

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?

Re:We Know Best (1)

nine-times (778537) | more than 4 years ago | (#29352799)

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.

Re:We Know Best (3, Insightful)

fuzzyfuzzyfungus (1223518) | more than 4 years ago | (#29352965)

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 (1, Informative)

nine-times (778537) | more than 4 years ago | (#29353321)

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 (1)

moosesocks (264553) | more than 4 years ago | (#29353467)

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.

Re:We Know Best (1)

MyLongNickName (822545) | more than 4 years ago | (#29352359)

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?

Re:We Know Best (0, Troll)

Millennium (2451) | more than 4 years ago | (#29352685)

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 (2, Interesting)

Overly Critical Guy (663429) | more than 4 years ago | (#29353063)

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

Re:We Know Best (1)

jedidiah (1196) | more than 4 years ago | (#29352749)

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.

Binding for porn? (-1)

NoYob (1630681) | more than 4 years ago | (#29352353)

The venerable Mac way of binding a document to an application is the creator code, a four-letter (actually integer) value, unique to an application, attached as metadata to a document.

The porn binding would be FUCK?

In Soviet Russia.... (1, Funny)

Anonymous Coward | more than 4 years ago | (#29352365)

In Soviet Russia, applications bind you!

Problem? (4, Insightful)

clone53421 (1310749) | more than 4 years ago | (#29352415)

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? (0)

Anonymous Coward | more than 4 years ago | (#29352459)

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

Re:Problem? (4, Interesting)

gabebear (251933) | more than 4 years ago | (#29352511)

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? (4, Insightful)

nine-times (778537) | more than 4 years ago | (#29352601)

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? (2, Insightful)

MMC Monster (602931) | more than 4 years ago | (#29352859)

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? (1, Insightful)

ThrowAwaySociety (1351793) | more than 4 years ago | (#29353435)

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? (5, Insightful)

Mneme (56118) | more than 4 years ago | (#29353595)

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? (2, Insightful)

ari_j (90255) | more than 4 years ago | (#29353723)

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? (0)

Anonymous Coward | more than 4 years ago | (#29353319)

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? (0)

Anonymous Coward | more than 4 years ago | (#29353729)

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? (2, Insightful)

proxy318 (944196) | more than 4 years ago | (#29353835)

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? (1)

Tacvek (948259) | more than 4 years ago | (#29353929)

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

Even better. (1)

Bill, Shooter of Bul (629286) | more than 4 years ago | (#29352625)

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. (2, Informative)

clone53421 (1310749) | more than 4 years ago | (#29352711)

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

Bill, Shooter of Bul (629286) | more than 4 years ago | (#29353361)

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

Anonymous Coward | more than 4 years ago | (#29353403)

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:Problem? (2, Informative)

tlhIngan (30335) | more than 4 years ago | (#29352701)

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? (1)

clone53421 (1310749) | more than 4 years ago | (#29352801)

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? (2, Insightful)

Jeremy Erwin (2054) | more than 4 years ago | (#29353867)

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

File Association Hijacking (5, Informative)

ThrowAwaySociety (1351793) | more than 4 years ago | (#29352809)

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 (0)

clone53421 (1310749) | more than 4 years ago | (#29353017)

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 (2, Insightful)

ThrowAwaySociety (1351793) | more than 4 years ago | (#29353493)

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:Problem? (0)

Anonymous Coward | more than 4 years ago | (#29353087)

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? (1)

clone53421 (1310749) | more than 4 years ago | (#29353421)

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? (1)

Sandbags (964742) | more than 4 years ago | (#29353775)

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? (1)

peragrin (659227) | more than 4 years ago | (#29353827)

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.

Bugfix (1)

Frankie70 (803801) | more than 4 years ago | (#29353921)

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?

quicktime (4, Informative)

e**(i pi)-1 (462311) | more than 4 years ago | (#29352437)

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 (1)

AndrewNeo (979708) | more than 4 years ago | (#29352565)

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 (1)

e**(i pi)-1 (462311) | more than 4 years ago | (#29352667)

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 (1)

larry bagina (561269) | more than 4 years ago | (#29352795)

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 (1)

Ma8thew (861741) | more than 4 years ago | (#29352631)

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 (2, Funny)

larry bagina (561269) | more than 4 years ago | (#29352763)

Half the reason to use a Mac is software that's also available for Windows [apple.com] ?

Re:quicktime (0)

Anonymous Coward | more than 4 years ago | (#29352893)

> 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 (5, Informative)

mdarksbane (587589) | more than 4 years ago | (#29352899)

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 (1)

markringen (1501853) | more than 4 years ago | (#29353203)

quicktime x isn't finished yet..

An error in TFA (1)

Shin-LaC (1333529) | more than 4 years ago | (#29352449)

(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 (1, Offtopic)

superdana (1211758) | more than 4 years ago | (#29352559)

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

Not the UNIX way (5, Insightful)

McDutchie (151611) | more than 4 years ago | (#29352485)

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 (1)

clone53421 (1310749) | more than 4 years ago | (#29352569)

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 (4, Insightful)

AndrewNeo (979708) | more than 4 years ago | (#29352627)

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 (1)

goodmanj (234846) | more than 4 years ago | (#29353931)

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 (1)

Attila Dimedici (1036002) | more than 4 years ago | (#29352659)

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 (1)

clone53421 (1310749) | more than 4 years ago | (#29352837)

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 (1)

magnusrex1280 (1075361) | more than 4 years ago | (#29352675)

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 (2, Insightful)

Jeremy Erwin (2054) | more than 4 years ago | (#29353463)

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 (2, Insightful)

IntlHarvester (11985) | more than 4 years ago | (#29352983)

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 (1)

McDutchie (151611) | more than 4 years ago | (#29353207)

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.

Correction (1)

McDutchie (151611) | more than 4 years ago | (#29353259)

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:Not the UNIX way (1)

Tetsujin (103070) | more than 4 years ago | (#29353275)

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 (1)

IntlHarvester (11985) | more than 4 years ago | (#29353815)

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 (1)

Sandbags (964742) | more than 4 years ago | (#29353875)

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 (0)

Anonymous Coward | more than 4 years ago | (#29353895)

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.

Change for the Better (1)

Ksevio (865461) | more than 4 years ago | (#29352567)

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 (2, Insightful)

99BottlesOfBeerInMyF (813746) | more than 4 years ago | (#29352713)

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 (1)

fulldecent (598482) | more than 4 years ago | (#29352851)

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.

Fri5t 4sot (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#29352697)

ma7 disturb other 486/66 with 8

It actually works just fine (3, Insightful)

dbet (1607261) | more than 4 years ago | (#29352861)

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 (2, Informative)

99BottlesOfBeerInMyF (813746) | more than 4 years ago | (#29353015)

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.

Resources have been gone since OS X (1)

fermion (181285) | more than 4 years ago | (#29352971)

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.

Resource fork making a comeback (2, Interesting)

yabos (719499) | more than 4 years ago | (#29353491)

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 [getdropbox.com]

Is this just half an article? (1)

pizzach (1011925) | more than 4 years ago | (#29352997)

I double checked creator codes on wikipedia [wikipedia.org] . 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: Apple Urinary Tract Infections (UTIs) (1)

Tetsujin (103070) | more than 4 years ago | (#29353393)

I double checked creator codes on wikipedia [wikipedia.org] . 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:Is this just half an article? (0)

Anonymous Coward | more than 4 years ago | (#29353503)

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.

Snow Leopard Snubs Documentary Creator Code (1)

Elwar123 (1053566) | more than 4 years ago | (#29353309)

At first I thought it said "Snow Leopard Snubs Documentary Creator Code"...meaning some guy was doing a documentary about a Snow Leopard and there's some code of ethics between documentary creator and animal in that the animal is not supposed to eat the Documentary Creator.

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

WebManWalking (1225366) | more than 4 years ago | (#29353387)

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.

Should open files with the app that was used (0)

Anonymous Coward | more than 4 years ago | (#29353515)

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.

Just Like Windows (2, Funny)

Nom du Keyboard (633989) | more than 4 years ago | (#29353527)

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

WTF ? Unix uses file extensiojns ? (1, Informative)

Anonymous Coward | more than 4 years ago | (#29353535)

From the referenced article in the story : "... The Unix approach (or what I'm calling "Unix" for purposes of this article; its history actually goes back to DEC and DOS and is in fact merely optional in Unix) is to use file extensions, which are abbreviations following a period in a document's name... " The guy who wrote the article clearly has no idea what he's talking about and probably has never seen how this is done in Unix: it uses 'magic'. :)

Creator Codes and UTIs (0)

Anonymous Coward | more than 4 years ago | (#29353539)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...