“It seems that UTIs are in the news again. It all started with a change in application binding in Snow Leopard. In a scant few weeks it’s degenerated into a sometimes-angry bout of cross-blog debate. I have an opinion about the changes in Snow Leopard, and I’ll get to that eventually, but my main goal is to clarify the issue. It’s really not that complicated, and seeing all the confusion on the web has been disheartening.”
NIce, clear and concise explanation of the situation. Apple could’ve gone about this much more gracefully; it does make sense that the old Mac OS creator and type codes fall by the wayside but Apple should’ve had APIs in place for the new UTIs and app bundle ids long ago. This has actually affected a few programs in unexpected ways, take Vuescan as an example. When you set an external viewer, all it does is change the creator code of the scanned picture file to that application and then open the file, letting the os handle the rest. Needless to say, this no longer works in Snow Leopard and the scan always opens with the default app. I never actually liked files to open with their creator apps, as I’ve found it got in the way more than it helped. I didn’t realize though that I did use it via Vuescan until sl changed this behavior; granted, Vuescan should have never used this hack and just allowed opening with various applications in the normal way, but it’s still a good example of an unexpected side effect of this change by Apple.
So I haven’t seriously looked into it, but I had heard that MacOS(X) stores this information in the resource fork of a file, which causes bad behavior when you send a file over the network and it forgets its icon and type and stuff.
What is stored in the resource fork, if not the type and creator information?