No not that .com, the old DOS executable one. Apparently when you print to Distiller (a program that creates PDF files via a Windows printer driver among other methods), and it asks for a file name, if you supply an extension it overrides the default .pdf instead of tacking on the .pdf to whatever you enter. This has entertaining consequences when an employee supplies the name somecomany.com (yes that .com). Acrobat then saves the PDF as somecompany.com instead of somecompany.com.pdf) and runs it. You then get either an empty DOS box and a message about inadequate conventional memory (Win98), or a DOS box will flash by briefly and nothing else happens (W2K).

It would appear that Distiller "runs" the file and relies on whatever file association Windows supplies rather than running Acrobat with the filename as a parameter.

The fact that the DOS box's title was "somecompany" also hinted at the solution.

We're going to be stuck with filename extensions for a thousand years, aren't we?

It might, but it will still have to to deal with files going in and out of the system to other non-Longhorn computers (or maybe it just won't. Could be fun). This of course what holds back advancement in this area for all platforms (and is why Apple has pretty much abandoned type and creator codes on MacOS X much to the consternation of many long-time developers).

BeOS had a nice system where incoming files would be checked for magic bytes indicating the file type and falling back onto extensions. It would then store the MIME (like email attachments) file type in a file attribute (BFS has indexed file attributes). NTFS has file attributes (or are they just those alternate file streams?) and I'm sure whatever WinFS adds onto NTFS would be capable of storing this. We shall see.

IIRC the Linux desktop file managers work similarly to BeOS but just check the file type or extension on every opening as they have nowhere convenient (ie: LCD) to store the MIME type.

XFS supports attributes (but not indexed). I have a design for a "just enough to show how nice it could be, and ignore the tricky legacy/interoperability problems" level Linux desktop shell using XFS, LUFS (a Linux file system kernel module that forwards all of its calls to a user mode shared library via Unix Domain Sockets), Python and Qt percolating in my head. We'll see if any of it ever makes it to "actual code".

A file listing which magic bytes within a file indicate the likely file type Those magic bytes are then mapped to a mime type. the file command uses a similar (the same?) database.

I suppose it isn't all that different to just check the magic whenever the user opens a file but I have had at least one occasion where I wanted to change the mime type of a particular file that Nautilus (the Gnome file manager) didn't guess right. With BeOS's scheme, the magic check is only done when there isn't a mime type attribute already associated with the file. Once that attribute is created you can tweak it if you wish. And I was mistaken. BeOS checks the extension first, then the magic byte signature.

According to the Nautilus user manual (I don't have a working Gnome here to verify), you can assign primary and secondary actions to either a general mime type or to a particular file. I don't know why I missed this in my case. The UI for such things in Gnome is rather bad at the moment.


OT PS: The is the wrong mime magic: [link|http://www.annamime.com/wow.html|http://www.annamime.com/wow.html]