Re: Assuming "text/plain" for text-like MIME sniffing buffers often leads to problems

[Christophe Fergeau <teuf gnome org>]

Le jeudi 20 avril 2006 �7:17 +0200, Alexander Larsson a �it :
> On Fri, 2006-03-24 at 20:31 +0100, Christian Neumair wrote:
> > When no MIME type is found to match for the contents sniff of a file and
> > the buffer looks like text, "text/plain" is assumed. When the
> > subclassing information isn't correct (for instance, the current
> > shared-mime-info release 0.17 doesn't have "text/plain" =>
> > "application/pdf" associations), this will make the contents sniff take
> > precedence over the extension and for instance evince can't handle the
> > file, and  Nautilus will bail when activating the file.
> > I therefore propose to always return XDG_MIME_TYPE_UNKNOWN if the result
> > can't be determined.
> 
> A pdf sniffed as text? That sounds strange.
> 
> Anyway, I think this sounds wrong. We'll detect far less text files if
> we do this, meaning you'll be unable to open them instead. Getting the
> mime info fixed seems like a better solution.

There's a bug explaining what goes wrong in the pdf case: there was a
change done to make gnome-vfs return MIME_TYPE_UNKNOWN when multiple
sniffing pattern matches (it used to return the first match I think). In
the pdf case, s-m-i contains 2 sniff patterns for % (yep, % alone), and
one for %PDF-, and the current code decides it's an ambiguous case, and
return MIME_TYPE_UNKNOWN. 
1) having single character sniff patterns isn't a great idea
2) in ambiguous cases, we should use the mime type coresponding to the
longest matchinig pattern, and only return UNKNOWN if there are several
matches of the same length.

Christophe