>> What I really would like is a filesystem that can store a mime-type for >> every file... That way no magic databases are required. In addition, the >> kernel could be configured to assign default mime-types for different >> file extensions, or something. >> >> This would mean instead of having lots of different programs trying >> to determine file types (each with a very different method - some use >> extensions, others use magic databases or a combination of the two). >> Programs like Apache wouldn't have to work out the mime type from the >> extension, but could just look at the value given by the filesystem. >> Changing the mime-type for one file would automatically effect >> all programs. >> >> [ runs for cover... ] >> > >Apples MacOS does nearly that (not really MIME types, but a proprietary >code with the same intention). First I liked the idea, but after some time >the whole thing started to suck deadly and when I work on a Mac now, one >of the most important utilities I use is named 'Set its type!'.
Where Macintosh fails, IMHO, is due to - No easy way to change the file type. - The information it proprietary, and not used anywhere else. - I am not very familar with the operating system, so there might be more points that I have missed. Perhaps there are difficulties loading a file for one application inside another application? - AFAIK, Macintosh doesn't really store "file type" but rather "which application is this file associated with". So if you have multiple programs that deal with the same file type, the file has to be associated with *exactly one* application. (not sure about this) - just curious: what other times do you need to change this file type? If you did what I proposed, instead of having to configure each and every program manually that "mypicture" is image/gif, you would just set the mime-type ONCE. If at a latter date, you suddenly realize that PNG would be a better format, you don't have to change the name of the file, and you want break any links to that file (especially external http links). When you loaded that image, whether you used apache, gimp, xv, or something else, it would automatically know what file type it is without any excessive overhead. Currently most programs use the file extension, which IMHO is very similar to my proposal, except: - mime types are standard, not just defacto standard. - not part of the file name, ie a seperate attribute, like the date and time. Put another way, the filename is independant of what type the file is. >I think file(1) does quite a good job and I believe that specifying >what you want to do with a file is much better than 'click it and wait for >the magic'. There are far too many useful actions available for some file >types. File is not used by many programs that check the file type. I think it is too slow for some applications (Apache), while for others (eg magicfilter) I can't remember the reasons given (but I know that good reasons exist). I am not proposing any "click it and wait for the magic" type think here, that was more related to the binfmt_misc proposal, where executing a file would automatically open the file with the correct program. However, this is already done with WWW, and I don't see any problems there (except misconfigured MIME types on some servers - something that would benifit from my proposal, at least for HTTP). I don't know how reliable file is either, but I strongly suspect that there will be files which will confuse it. -- Brian May <[EMAIL PROTECTED]>
