September 2009 Archives

Creator Codes Are Not Replaced by Uniform Type Identifiers

| No Comments

There’s some press about suggesting that Creator Codes are replaced by Uniform Type Identifiers (UTI) which is rubbish.

They’re not.

Uniform Type Identifiers are just a type. To be able to work out the type of something you have to look at some metadata which for the vast majority of things isn’t a UTI. For most files on your Mac, it will be the extension of the file that determines what type of file it is. About the only place that you’ll see a UTI is within the property list of an application where it says what types it supports.

As far as I know, there is no direct replacement for creator codes. There is no other metadata that you can put on the file that tells the system what application created it, and even if there was, UTIs would have little to do with it since UTIs represent types, not applications.

There is metadata on a file that is used to say what application should open the file (on a per file basis). This is stored within the resource fork of the file in a usro resource. This simply stores the path of the application (no UTI is involved) that should open a file and yes, this could be used to replace creator codes—I don’t know if there’s an API for setting them, I haven’t checked. Launch Services has a private API that you could use to set the binding:

extern OSStatus _LSSetStrongBindingForRef(const FSRef *inItemRef,
                                          FSRef *inAppRefOrNil);

I don’t know why Apple have got rid of creator codes but it is a shame they haven’t replaced them with something. Perhaps they haven’t had time to figure out what to replace them with. Thinking about it, what you probably want is to store the bundle ID of the application that created the file in some metadata somewhere (as an extended attribute or within the resource fork). I haven’t thought it through, but there might also be security issues with creator codes—malicious programs could set them behind your back and cause bad stuff to happen.

AppleGlot on Snow Leopard

| No Comments

To get AppleGlot to work properly on Snow Leopard, apply this patch to /Developer/Applications/AppleGlot/ /AppleGlot.framework/Resources/ibtoolWrapper.

(It’s broken because ibtool runs as a 64-bit app. and can’t load AppleGlot’s plugin which is 32-bit).