Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
OS X Technology (Apple) Apple

Snow Leopard Snubs Document Creator Codes 214

Posted by timothy from the mind-the-new-mantrap-in-the-living-room dept.
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."
This discussion has been archived. No new comments can be posted.

Snow Leopard Snubs Document Creator Codes More

Snow Leopard Snubs Document Creator Codes

Comments Filter:

  • Problem? (Score:5, Insightful)

    by clone53421 ( 1310749 ) on Tuesday September 08, 2009 @12:03PM (#29352415) Journal

    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? (Score:4, Interesting)

      by gabebear ( 251933 ) on Tuesday September 08, 2009 @12:09PM (#29352511) Homepage Journal
      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.

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

      • Re: (Score:2, Insightful)

        by hattig ( 47930 )

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

      by nine-times ( 778537 ) <nine.times@gmail.com> on Tuesday September 08, 2009 @12:14PM (#29352601) Homepage

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

        by MMC Monster ( 602931 )

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

          by ari_j ( 90255 )
          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: (Score:2, Insightful)

        by proxy318 ( 944196 )
        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

      • Re: (Score:2)

        by Tacvek ( 948259 )

        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 applicat

    • 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: (Score:3, Informative)

        by clone53421 ( 1310749 )

        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: (Score:3, Informative)

      by tlhIngan ( 30335 )

      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 m

      • 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

        • Re: (Score:3, Insightful)

          by Jeremy Erwin ( 2054 )

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

      by ThrowAwaySociety ( 1351793 ) on Tuesday September 08, 2009 @12:30PM (#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.

    • 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

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

    • 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?

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

  • quicktime (Score:5, Informative)

    by e**(i pi)-1 ( 462311 ) on Tuesday September 08, 2009 @12:04PM (#29352437) Homepage Journal
    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!

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

      • 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: (Score:2)

      by Ma8thew ( 861741 )
      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.
    • Half the reason to use a Mac is software that's also available for Windows [apple.com]?

      • Re: (Score:3, Insightful)

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

    • Re:quicktime (Score:5, Informative)

      by mdarksbane ( 587589 ) on Tuesday September 08, 2009 @12:36PM (#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.

      • ...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'l


      • 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!

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

  • Not the UNIX way (Score:5, Insightful)

    by McDutchie ( 151611 ) on Tuesday September 08, 2009 @12:07PM (#29352485) Homepage

    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.

    • 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 (Score:5, Insightful)

      by AndrewNeo ( 979708 ) on Tuesday September 08, 2009 @12:16PM (#29352627) Homepage

      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)

      • 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

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

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

      by IntlHarvester ( 11985 ) *

      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?

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

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

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

      • 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, bu

        • 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 Windo

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

    • 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

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

      T

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

      by 99BottlesOfBeerInMyF ( 813746 )

      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 defau

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

      • 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 giv

  • It actually works just fine (Score:3, Insightful)

    by dbet ( 1607261 ) on Tuesday September 08, 2009 @12:34PM (#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: (Score:3, Informative)

      by 99BottlesOfBeerInMyF ( 813746 )

      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

  • 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,

  • 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?

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

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

  • Just Like Windows (Score:3, Funny)

    by Nom du Keyboard ( 633989 ) on Tuesday September 08, 2009 @01:18PM (#29353527)
    So now OS/X works just like Windows. Wow, what an advance.

Slashdot Top Deals

What is research but a blind date with knowledge? -- Will Harvey

Close