Shared-mime checking order

David Faure dfaure at trolltech.com
Fri Aug 24 07:15:21 PDT 2007


On Friday 24 August 2007, Alexander Larsson wrote:
> On Fri, 2007-08-24 at 15:39 +0200, David Faure wrote:
> 
> > I understand what you mean... I'm not sure what's the best behavior though;
> > your mail made me realize that I did skip "high-magic-beats-extension" in the
> > delayed-mimetype-determination code (even though the core mimetype code can do that),
> > and I re-enabling that would mean a lot of sniffing (every file needs to be rechecked
> > in the post-listing mimetype redetermination...)... Hmm.
> 
> Ah, so we're actually doing the same thing. You're only sniffing when
> there is no known extension, so the priority in that case is irrelevant.

Well let's not generalize. In 90% of the KMimeType use cases it's done correctly :-)
But the "delayed mimetype determination" code for file managers doesn't really
want to do magic on every file indeed. We have to find a rule for how to know when
the mimetype could be refined by magic... which is quite related to my other post
about conflicting results from extension matching (this is one case where we want to
refine with magic later on). There might be more, like ogg if we make its rules low-prio,
or pdf and ps.

> Do you do this even when deciding mimetype for picking app to open the file in?

In that case we should really make sure that the mimetype determination is correct,
so we should use the full spec-compliant matching (including preferring high-prio rules).
There might be a bug there in the current kde4 code, but that's a detail :)

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).


More information about the xdg mailing list