Mac OS X: File extension and type/creator non-sense

Posted by Pierre Igot in: Macintosh
August 1st, 2003 • 10:44 pm

What it’s going to take for Apple to finally see the light about all this file type/creator and extension non-sense, I don’t know. But I do know that things can be a royal pain in Mac OS X.

Case in point: I do most of my web development in BBEdit, so I want all my “.html” files to open in BBEdit when I double-click on them. This is fine for files newly created by BBEdit, because the Bare Bones folks were wise enough not to embrace Apple’s new “philosophy” and to stick with the tried and true methods of the classic Mac OS, in which files are assigned a type and creator that have nothing to do with how they are named.

For some reason, however, I have some files whose type/creator Mac OS X has obviously decided to remove without my consent. Right now, I am looking at a folder of .html files that were all created with BBEdit several years ago. Most of them have a BBEdit document icon, but a couple of them have the default “Safari document” icon. Why? I don’t know. I don’t recall ever doing anything that would remove the file/creator DATA from these files, but of course it might have happened during an FTP upload/download activity, for file synchronization reasons.

So I figured I would play nice and adopt Apple’s way of doing things, i.e. simply tell it to open all files ending with the “.html” extension with BBEdit. I opened the Get Information window, and I looked under the “Open with” heading. It gave me a list of possible browsers, with “Safari (1.0)” as the currently selected and “(default)” option, plus TextEdit, for some reason, but no BBEdit. Obviously BBEdit is not part of Mac OS X’s default thinking when it comes to HTML files. So I went to the “Other…” command in the menu and chose the BBEdit application. It let me select it, I clicked on OK, and… the “Open with” menu now said “Not applicable”. What the hell? So now BBEdit is “not applicable” as a file for opening HTML files?

Even worse: a few minutes later, I went back to the same menu for double-checking purposes. This time, the menu of “applicable” options contained something like 30 or 40 options, including weird things such as Adobe Illustrator, Microsoft PowerPoint, and PageMaker 6.5 (and other Classic apps). But still no BBEdit?

At this point, I am thinking that either Mac OS X 10.2 is seriously screwed when it comes to deciding which files to open with which applications — or something in my hard drive directory has become corrupted… I guess the only way to find out will be to try to run a disk repair utility. The problem is, of course, that I have better things to do right now than to shut down my whole system and restart from another volume. My system has been up for 18 days with no a single restart or even log out! I have windows open in Safari that are several days old and there is no way to make Safari “remember” all these windows and reopen them after a restart, short of sifting through several screens of browsing “history” and trying to locate each and every visited site manually… Instead of the much-touted “SnapBack” feature, a much more useful feature in Safari for me would be something that takes a “snapshot” of all currently loaded pages (in windows and tabs) and recreates this exact same environment after having quit and relaunched Safari. I remember reading about an AppleScript script that did just that in earlier (tab-free) beta versions of Safari, but apparently the current AppleScript dictionary in Safari 1.0 doesn’t give access to individual tabs within windows, so that’s pretty much hopeless at this point in time.

But I digress. The bottom-line is that I hate having to deal with file/creator/extension issues, and I hate the fact that Mac OS X is forcing me to, and even getting in the way when I try to circumvent the obvious limitations of the default system architecture.

I haven’t heard anything about things improving in Panther on that particular front, I am afraid…


19 Responses to “Mac OS X: File extension and type/creator non-sense”

  1. Rainer Brockerhoff says:

    Indeed, #2 should apply in your case. If it doesn’t, either there’s some extra factor we’re not aware of, or your binding cache files may be corrupted somehow.
    There’s a way to delete these files in Jaguar, but it’s somewhat hacky and involves rebooting… I can e-mail you details if you wish.
    All the same, if I may plug another product of mine, have a look at Zingg! (and it’s freeware). What I usually do with it is to set BBEdit to “open always”, so you’ll always be able to open anything with BBEdit from the Finder’s contextual menu.
    Also, I’ve pretty much stopped opening documents with double-clicking in Mac OS X; I usually either drag them onto the app’s icon – I’ve got most of what I use fixed in the Dock or in the Finder’s toolbar window – or use Zingg!. There’s no way things can go wrong with that…

  2. Pierre Igot says:

    I’d be interested in fixing the problem… So I’d appreciate it if you could email me the hack for deleting the binding cache files.

    Unfortunately, I haven’t be able to shake off the habit of double-clicking on files to open them… It might have to do with the fact that I have quite a bit of screen real estate (dual monitor setup) and the application icon is often a bit far :).

  3. Pierre Igot says:

    Very informative stuff, thanks. (I am aware of XRay — but I have a copy of Super Get Info on my machine. :))

    The situation I have is that the affected files have a type (TEXT) and no creator and an extension (.html). You didn’t cover that particular case. If I assume that #2 applies (has no creator but an extension), then the binding with BBEdit should work. But it doesn’t :-/.

    As I said, the Info window says “Not applicable”, but changes the doc icon to a BBEdit doc just the same, but when I click on “Change All”, the doc icon reverts to the Safari doc and Open With reverts to “Safari (default)”.

    What a mess.

  4. Rainer Brockerhoff says:

    Hi Pierre,

    This whole issue is indeed very complex, and (if you’ll allow me a plug) out of frustration with it I wrote XRay, a shareware application that shows exactly how it’s implemented. Have a look at the product page: http://www.brockerhoff.net/xray

    The online documentation explains some ramifications. In effect, extension overrides type (but creator overrides extension). You can change the system’s binding using a sample item, but there are some non-obvious rules when you do so (either in the Finder or in XRay):
    1) The item has no extension and no type: you canít change the binding. If thereís a creator, it is bound to that; if thereís no creator either, XRay will show that no application exists for that item.
    2) The item has no creator but has an extension: all items with that extension and no creator will be bound, irrespective of type. Items with a creator wonít be affected.
    3) The item has no creator or extension, but has a type: all items with that type, but no creator or extension will be bound. Items with either a creator or an extension wonít be affected.
    4) The item has both a creator and an extension: all items with that creator and extension will be bound, irrespective of type.
    5) The item has both a creator and a type, but no extension: all items with that type and creator will be bound. Items with an extension wonít be affected.
    I’ll be very interested in your comments…

  5. Henry Neugass says:

    I was initially horrified at the thought: We’re back to Window-style extensions in MacOS X!

    In practice, I’ve not had any problem with the way X works in this respect: Generally, everything just works the way I expect it to, even if I don’t fully comprehend how.

    Possible exception: Recently, I found that opening certain folders crashed the Finder. Eventually I found some very old data files (from Claris Draw and another archaic app) were the cause; apparently any operation that caused the system to look up the icon associated with the files –and there are more of these than you might expect– fatally confused the Finder. I was able to find some information about this issue and suggestions about some files to trash, but none of these solutions worked. Ultimately I fixed the problem by creating a new user account and switching to that.

    Having read the foregoing, I’m a bit more convinced that the problem was somewhere in the associations mechanisms.

  6. Pierre Igot says:

    There’s no denying that Apple’s way of handling extensions is more elegant than in Windows. (The fact that it is so easy in Windows to have two extensions on a single file name is highly problematic, and is a significant source of confusion that virus creators are exploiting.)

    OTOH, the very fact that there are so many different “rules” as described by Rainer above is an indication that extensions have significantly increased the level of confusion regarding file naming conventions and their impact in Mac OS X.

    As for the particular issue being discussed here, and your own trouble with association mechanisms, it is unfortunate that there are no user-friendly fixes that do not require creating an entirely new user account (a rather tedious task).

  7. Henry Neugass says:

    This is the paradox: We want mechanisms to “just work” so we don’t have to think of them. Steering wheels and brakes, for example. On the other hand, especially in computing, each of us seems to have at least one exception case where a detail is of utmost concern.

    People who are “pro Apple” generally seem to feel Apple does a better job at making things “just work” — I know I do. As for the details, it seems that Apple conceals them more often than is justified by commercial interest, and maybe more or less as much as any other vendor.

    In this case, I’m torn between conducting experiments with Rainer Brockerhoff’s utility to better understand the details, and the alternative, somehow inducing Apple to make the mechanism “right”.

    One side comment: file versioning. I think it is sensible (especially with some less reliable applications) to save “reportv1.23.xxx” say, an hour after starting work with “reportv1.22.xxx”. But this isn’t always made as convenient as it might be, and interacts with the general issue of extensions. Sigh. It was easier in OS9…

  8. Pierre Igot says:

    The analogy with brakes is interesting in so far as brakes do eventually break down and need to be fixed… after a long time. We probably have a similar situation with certain aspects of Mac OS X. While overall the performance and reliability do not degrade over time as quickly as they used to do in Mac OS 9 — there are things that can break down after a (long) while, because of preference/cache file corruption and other similar issues.

    The question is: Is the only possible solution for this to go to a garage and get the brakes fixed, or can/should we learn how to do it ourselves?

    I haven’t noticed that the use of periods inside file names causes problems with extensions in general. But I am sure there is one specific “rule” in which they would. I guess I just haven’t come across it yet.

  9. Henry Neugass says:

    My problem with periods within file names: In file save and similar dialogs, there’s an inconsistent tendency to consider the first item to the right of the period as the extension, or at least it looks that way. Since such dialogs are usually drawn by the system (right?) but sometimes as modified by the application, it is difficult to assign reponsibility. This is an annoyance, though, especially compared to the issue with file icon associations crashing the Finder I mentioned earlier.

    So one day a brake pad disintegrates and (by analogy) some file associations begin crashing the Finder.

    In the auto repair environment, I think auto companies make their part specifications available to the world, as well as actual parts, enabling almost any repair shop to do the replacement — allowing even the most hardware-ignorant driver to resume driving if there’s a neighborhood shop. In the modern computer business… we’re trying to build our own equivalent here and in newsgroups and so on.

    This level of problem is in turn is less significant a problem than what I’ve observed in some applications, e.g. MS Word: you’re driving down a smooth, straight road in a well-maintained, late model car, and –without warning– the steering wheel comes off in your hands.

  10. Pierre Igot says:

    FYI, I tried the hack suggested by Rainer and it worked:

    https://www.betalogue.com/index.php?p=43

  11. Henry Neugass says:

    I compared the file deletes Rainer recommends in my notes for fixes in this area — and found different ones.

    I doubt I’ll go back to try to fix the user account I discarded when I had an associations problem. But I’ll certainly keep the notes up to date in case the issue arises again. It seems to occur fairly frequently, unfortunately, in some form or another.

    It sure would nice to see what Apple had in mind instead of deleting preference files somewhat somewhat blindly. How did Rainer decide to whichfiles needed to go?

    Has anyone done a search of the technical literature on the Apple developer site?

    I’ll note that the last time I went there, I was trying to understand clipboard contents in OS X, and I didn’t find anything. Strange? Seems the new term for developer use is “pasteboard” and no one thought to leave a bridge from old the old term. A bad experience that doesn’t encourage me to dive into that material again.

  12. Pierre Igot says:

    I understand that, as a software developer, Rainer is on a number of mailing lists about Mac OS X software development and go this tip through discussion on these mailing lists. It’s actually referred to in Apple’s own documentation at:

    http://developer.apple.com/documentation/Java/Conceptual/Jar_Bundler/Packaging/chapter_3_section_2.html

    and also referred to on this mailing list:

    http://www.omnigroup.com/mailman/archive/macosx-dev/2002-October/030609.html

  13. Henry Neugass says:

    Thanks. Not sure how the first (…Jar_bundler…) applies. The second makes sense. (Thanks to Omnigroup for being such a good community member!) There’s also a similar one on the Apple site. These are all rather general groups and the effective data rate for any particular subject is usually very low.

    Digressing: This reminds me that I have been looking for a method of executing just a tiny bit of code, a call to IOKitLib to rescan the SCSI bus. (Application: accessing my SCSI scanner –normally powered down– without rebooting MacOS X). I am a software developer so I can certainly do it, but installing and learning the entire development environment to make one function call seems a bit out of proportion.

    Again, I must keep in mind that my object is to drive my virtual car down the road to my destination. Problems with file associations and with SCSI peripherals are not important. Installing a virtual repair shop is a distraction.

  14. Pierre Igot says:

    The first one applies in so far as the procedure is for the same purpose (flushing the cache for associations/bindings).

    It sounds as if you’re demanding a bit much for your SCSI thing… You want an SCSI connection with the flexibility of a FireWire connection? (= ability to turn off and on on demand) There might be hardware issues here…

    The file associations is important in so far as it’s obviously something that can happen to anyone at any point.

  15. Henry Neugass says:

    OK, I’ll re-examine Jar_bundler.

    The SCSI thing… appears to be fixed. (!) The scanner vendor, EPSON, finally released the OS X driver in the past week. (File dates show they held back the drivers for something like 9 months, but that’s another mystery.) It’s possible they built SCSI rescan into the driver, or I’m just lucky, because I can now turn off the scanner, turn it on later and still access it, without rebooting. I may be that I have to have the scanner powered during each boot, but I’m not going to reboot OS X just to check _that_.

    I think the file associations issue merits a bit of homework; it smells like something that _will_ happen again. That’s why I’m keeping notes.

  16. Pierre Igot says:

    Sounds like a resource fork problem. Depending on the type of server and transfer protocol, it’s quite possible that the resource fork is stripped during the transfer, and that Macromedia uses the resource fork in its Flash files for Mac.

    If that’s what the problem is, then you need to upload/download the file in a way that preserves the resource fork. One way is to compress the file before transferring it. Either with StuffIt DropStuff or with Panther’s Create Archive command, which creates a Zip archive that includes the resource fork in the data fork — hence ensuring that it’s preserved.

    HTH.

  17. F. C. Brummer says:

    This is both related and a bit different;

    I’m developing content for a cd-rom in flash mx 2004 on Jaguar. I’ve got 2 versions of the projector file; one for Win and one for Mac (run.exe and run.app). The problem is this: when I publish the projector from flash it opens smoothly with a simple double-click, however when i upload it onto our server and download it again osX no longer knows what to do with it. It will not open as an application, even though it is one. I have to insure that this cd-rom will be functional cross-platform, and I have no idea how to get around this… any info would be greatly appreciated.

  18. Rainer Brockerhoff says:

    F.C., if the Mac application is a bundled app (which in reality is a folder), uploading and downloading it usually will break it. Either zip it or put it on a disk image (.dmg) file and be sure to configure the server to treat .dmg as a binary format.
    If it’s not bundled, uploading and downloading will certainly lose the ‘APPL’ file type, so the same solution applies.

  19. F.C.B. says:

    Thanks

Leave a Reply

Comments are closed.