Fwd: Re: main extension for a mimetype

[Alexander Larsson]

On Wed, 2009-04-08 at 12:32 +0200, David Faure wrote:
> On Wednesday 08 April 2009, Alexander Larsson wrote:
> > On Wed, 2009-04-08 at 11:56 +0200, David Faure wrote:
> > > On Wednesday 08 April 2009, Alexander wrote:
> > > > I think the reason the globs are a per-glob map is that when the globs
> > > > are stored in the mime.cache file some of the items (suffixes, literals)
> > > > are stored sorted.
> > > 
> > > Ah. I don't know anything about mime.cache ;-)
> > 
> > You use a similar thing, right? ksyscoca? How does that work, is it also
> > mmaped by apps, or is it an ipc thing?
> 
> Yes, ksycoca is mmap'ed by apps (or uses shared memory on Windows).
> If mmap or shared-mem fails, we fall back to a plain file (seeking and reading
> into it at specific offsets just like we do with the mmap'ed data).
> 
> > > > I can have a go at fixing this. However, there is an issue here with the
> > > > ordering. There is a given order for the patterns in the xml files, but
> > > > the globs file is sorted by glob weight. With a stable sort this would
> > > > only be a problem if a glob that is not the main extension for the file
> > > > has a larger weight. Is this a problem?
> > > 
> > > Hmm. The point of glob weights is to choose between two mimetypes that use the same glob;
> > > not to order the globs of a single mimetype. But glob weights have that side effect, though, indeed.
> > > Let's see. Hmm. Let's say we have,
> > > 50:app/foo:foo.*
> > > 50:app/bar:*.gbar
> > > 10:app/bar:*.bar
> > > 
> > > The lower glob of 10 is there so that "foo.bar" is seen as app/foo rather than as app/bar.
> > > If we still want to say that *.bar is the main extension for app/bar rather than *.gbar,
> > > then we have a problem. But an easy solution too: changing the weight of *.gbar to 10 too,
> > > which only becomes a problem if that glob also conflicts with another glob somewhere else...
> > > 
> > > Given that we only have one use of glob weights right now this seems rather unlikely,
> > > but if we want to be on the really really safe side, we could simply... ah yes, we could
> > > preserve the <glob> elements in the generated app/bar.xml file? Then I could just
> > > read the preferred glob from there, and globs2 can keep its hash-based implementation?
> > 
> > Yeah, I was thinking about that too. Its probably a better idea than
> > overloading the glob file order.
> 
> Yeah, seems much simpler. And no overhead for me since kbuildsycoca is already parsing
> the xml files anyway (to read the <comment> tags).
> 
> BTW with reference to our other discussion, this means <glob> and <glob-deleteall>
> nodes should both be written out into the generated .xml files, so that we don't end
> up using a deleted glob as the main extension :-)

I commited these two changes to update-mime-data.c in shared-mime-info.
Can you test it and see if it works as you expect?