Re: linking binfmt_misc with mime-types
>> 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 <bam@snoopy.apana.org.au>
Reply to: