Bruce Horn Interview
Adam Engst interviews Bruce Horn, who’s been working on a smart Finder-like browser called iFile:
iFile tracks any changes to the contents of the folders and automatically updates the database as required. For example, the user can drag in the Pictures folder and be able to browse all the images, create collections, etc., without actually copying any files or moving any data. iFile respects your directory structures and never modifies anything directly, in contrast to iPhoto, which copies images into its own directory hierarchy.
He also talks a bit about his contributions to the original Mac OS and how they translated to Mac OS X.
It turns out that Mac OS X still needed a creator mechanism by which individual documents could be opened by specific applications, so this information is stored in the resource fork of the file (of all places, since Apple is discouraging use of the resource fork), rather than simply in a creator code.
I had always thought that Launch Services stored these preferences in the ~/Library/ tree, but it turns out that choosing an application to open a file adds ‘icns’ and ‘usro’ resources to the file (and leaves the creator code intact). How odd. Changing the application back to the one whose creator code tags the file does not delete these resources.
3 Comments RSS · Twitter
I suspect the "preferred app" resources might contain redundant info, in case the files are manipulated on Mac OS 9. Mac OS X probably stores/caches the values elsewhere for performance reasons. I have to question why the perfectly good mechanism of the creator field was not used. Also, changing the preferred app changes the file's modification date--an undesirable side effect.
The Launch Services database file(s) that contain the default document-to-application binding information are the following:
Panther:
/Library/Caches/com.apple.LaunchServices.6B.csstore
Jaguar:
/Library/Caches/com.apple.LaunchServices.LocalCache.csstore
/Users/~/Library/Caches/com.apple.LaunchServices.UserCache.csstore
When you choose a particular file in the Finder, open the Show Info window and use the "Open with:" section to choose a custom non-default application to open the file with, the Finder makes note of that preference by adding a small resource of type "usro" (user override?) to the file's resource fork. (In order to do this, you must have write permission for the file, and for the folder containing the file. This is why you might sometimes get a "You don't have privileges to change the application for this document only...." and you're prompted to make a global change (see below), which doesn't involve modifying the individual file). This "usro" resource contains a pointer to the application with which you've chosen to open the file. To provide you with visual feedback, the Finder will change the icon from the previous application to the new one you've chosen. It does this by adding a custom icon resource of type "icns" (Icon Suite) of the corresponding non-default application you chose.
If you then click on the "Change all..." button in the Show Info window, OS X makes note of this custom global-override preference by adding it to the following file:
Panther & Jaguar:
/Users/~/Library/Preferences/com.apple.LaunchServices.plist
Hope this helps....
This is an absolutely terrible mechanism. While I don't agree that multiple-fork files are a Good Thing anymore for obvious reasons, I do think that a better mechanism is in order.
Be had a wonderful way of associating an application by MIME type ("application/x-vnd-Buzzlabs.Underworld") with the MIME types for the file types it understood ("text/plain", "image/jpeg", etc.). It first looked at MIME type information (generally stored as BFS attributes, I believed), and then fell back to filename suffixes and looking at the magic number/structure of the file.
Much better solution, if you ask me.
