Filename Extensions Must Die
Determining the type of a file by its name is a practise which should be phased out.
Rationale
- Aesthetics - it is nicer and more readable to see "Sales Report" than "Sales Report.gnumeric"
- Consistency - types of files obtained via HTTP are determined by Content-Type HTTP header, not filename extension
- Protection - people can no longer accidentally change the type of their file by changing its name. Changing a file type would require explicitly changing its type via other means (e.g. Nautilus properties page)
- Reduced confusion - removes file type from unique key (name) in a directory
Implementation
The obvious solution right now is to go with hooking an extended attribute lookup into the GNOME VFS local filesystem file type lookup routine, rather than sniffing file contents. Interestingly, the HTTP backend already implements this much more reliably than the local backend, as it uses a HEAD request to ask the web server for the type of a particular resource.
If a proper type lookup cannot be done, then a fallback to the current implementation should be in place.
"gnomevfs-ls --type=major/minor" to filter based on type.
Hiding filename extensions in Nautilus is not a valid solution, as the appearance of two distinct files "My Web Page.htm" and "My Web Page.html" would be indistinguishable.
Outstanding Issues
- Interoperability - with foreign filesystems and operating systems especially. Perhaps filename extensions can be added automatically when transferring files to a system that does not support an explicit file type field. This is quite similar to what some web browsers do when saving resources from the web to permanent storage, i.e. when a file name extension does not exist or does not match the advertised media type, one is added to it automatically.
- Low level tool support - some CLI tools would be required for type manipulation - "chtype", perhaps?
Comments
Please discuss!
I agree with the first three points of the rationale whole-heartedly. However, file type is a necessary element in the unique key of a file so that users and applications can cache the different formats of a file side by side. For example, file.c and file.o, or report.txt, reprot.html, report.doc, report.tex, report.pdf.gz, &c. I think that storing a MIME type in an extended attribute (as when you download a file with wget or firefox) and using that data when available (as with gnome-open) to avoid typical confusion and user error is a fantastic idea, but as long as the extension is a part of a file's unique key, it is also imperative that it be transparent to the user and edited with the file name as one. - KrisKowal
Bear in mind that this does not necessarily mean that you have to stop using extensions for the purposes of, e.g., differentiating a C source code file from a compiled binary object. Given that, I still don't think file's name should really have any authority over a file's type. The use cases you specify are perfectly compatible with this, it's just that, in my mind, renaming a file between "Report", "Report.html", "Report HTML" and "Report.2006" should have no effect on its actual media type. With that in mind, what do you think? -AlexJones
I do not agree at all. This is what Apple has tried and because they were the only ones it has led to multiple problems. I agree that file extenstions should not always be the preferred way to determine the file type, but an ODP file is a ZIP file internally. The problem is that you have to add additional meta data like Apple did. If every operating system will do it, we can consider this - if not - lets not make the same errors Apple had done. -- ThiloPfennig 2006-12-20 23:05:52
So if your ODT (which is actually Zip) file, "My Report" has type "application/vnd.oasis.whatever", where does the confusion lie? Interoperability is indeed an outstanding issue, I already wrote about this above. Can you suggest anything that would get us closer to the goal or do you simply and fundamentally disagree with the idea? -- AlexJones
I approve of the notion of storing the MIME type as an extended attribute, providing a chtype CLI, augmenting ls and Nautilus to use this attribute for the file type column, augmenting gnome-open to open and edit files with appropriate applications based on those appropriate for its extension and optional file type extended attribute, augmenting the web browser to store MIME types as passed in the HTTP response when downloading files, and augmenting applications to store their MIME type with files they create. I do not believe that this will have the idealistic effect intended. It does not solve the aesthetic issue since files would and should still largely have extensions, consistency would not be well served, and confusion would be rampant. Consider the implications of sharing files with other operating systems, or migrating files among file systems. Consider the implications of opening a ".zip" file only to find that it was really an image. The only purposes well served would be protection from user error when renaming files and it would be increasingly convenient to store more and more specific information about the file type. A non-modal notification that you've changed the file's type serves well for protection, and most file types have taken versioning or magic numbers for type distinction upon themselves. All this said, I do think that the aforementioned developments would be net positive. -- KrisKowal 2006-12-20 23:49:18
- One problem I see is that currently, mime-type detection with Nautilus is slow. Files in an open folder change their icons when I click on them, for example. I don't know the internals, but it seems that Nautilus only inspects the file's contents at that point. The net effect is that it feels messy - Joachim
The exact problem is that GNOME VFS has to sniff the file's contents to determine it's type. I am proposing we replace that with a simple file type extended attribute lookup where possible, which would be more or less instantaneous. --AlexJones