Le 30 mai 2011 à 05:03, Chris Young a écrit :
On Sat, 14 May 2011 20:49:10 +0200, François Revol wrote:
> [const?] char *fetch_mime_by_ext(const char *filename);
Personally I hate detecting filetypes by filename/extension - it's
prone to errors/hacking. Look at all the problems on Windows,
renaming a file makes it think the filetype has changed, you can trick
things like Outlook so easily just by renaming files.
+1, that's why we use MIME types on files in xattrs and have a MIME sniffer in Haiku,
just like BeOS did for 15 years. :p
I also realise that sometimes the filename is the only way to
determine a filetype. I think an "integrated" approach would be
better, one function which passes the filename and the data. I see no
reason why the data (or at least the first few bytes) couldn't be
available before you need to work out what type it is.
Sometimes the file is empty :p
Well, there are several cases:
- existing files (file:) that can have a mime xattr, the BeOS port already checks them for
- virtual files (not yet downloaded urls or in-memory cached data not downloaded) where
the OS didn't yet sniff the mime, for which we have to sniff ourselves.
Ideally we would:
- check if the file is real, and it has a MIME info,
- try to sniff it,
- fallback to extension matching.
The API doesn't have to provide separate functions indeed, it can be a global one
which can have the data buffer be optional, if NULL then we just don't sniff.
Of course there are some corner cases like directories (BeOS also has a mime type for
those but different than NS'), and usual types like text/html which the OS might
differentiate a bit too much sometimes or identify differently (text/xml+html for
For ex, Haiku uses text/x-source-code and usually doesn't differentiate between
python, perl, bash, C++ or whatever source language.