Bug 18109 - Glob isn't used when parent mimetype has matching magic
Summary: Glob isn't used when parent mimetype has matching magic
Status: RESOLVED FIXED
Alias: None
Product: xdgmime
Classification: Unclassified
Component: xdgmime (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Jonathan Blandford
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-17 10:38 UTC by David Faure
Modified: 2011-10-23 22:19 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
patch for freedesktop.org.xml.in and tests/list (2.11 KB, patch)
2008-10-17 10:38 UTC, David Faure
Details | Splinter Review
sqlite2.kexi test file (3.00 KB, application/octet-stream)
2008-10-17 10:40 UTC, David Faure
Details

Description David Faure 2008-10-17 10:38:12 UTC
Created attachment 19722 [details] [review]
patch for freedesktop.org.xml.in and tests/list

application/x-sqlite2 has a magic match defined.

I tried adding a subclass of it, kexi-specific, that has a glob.
  <mime-type type="application/x-kexiproject-sqlite2">
    <_comment>Kexi database file-based project</_comment>
    <sub-class-of type="application/x-sqlite2"/>
    <glob pattern="*.kexi"/>
  </mime-type>
(as well as another mimetype with *.kexi, and which derives from sqlite3)

However ../xdgmime/src/test-mime tests/sqlite2.kexi still says
  File "tests/sqlite2.kexi" has a mime-type of application/x-sqlite2
Even though it works in the KDE implementation.

It looks like the xdgmime implementation doesn't implement correct resolution of multiple-matching-globs. When multiple mimetypes have the same glob, sniffing should be used, but obviously what is expected then is that sniffing helps choosing among the matching globs, not selecting a completely different mimetype.
Comment 1 David Faure 2008-10-17 10:40:00 UTC
Created attachment 19723 [details]
sqlite2.kexi test file
Comment 2 David Faure 2009-01-05 09:58:24 UTC
After fixing bug 18072, I'm hitting this bug again, with another case:

test-template.dot, 'file' test: expected application/msword-template, got application/x-ole-storage

This is because *.dot matches both msword-template and text/vnd.graphviz, so sniffing is used, which finds application/x-ole-storage, which should be used to say "ok, so it was msword-template", NOT to just return application/x-ole-storage as the final result.

Please fix the xdgmime implementation.
Comment 3 David Faure 2009-10-06 04:55:55 UTC
Kexi mimetypes committed. The bug can be seen by the presence of the last 'x' in the lines
test-template.dot application/msword-template oxx
and in the two kexi lines.

But it doesn't matter that much I guess, since Alex Larsson told me that GIO does it right (and KIO does too). It's just a bit strange and confusing that the "reference implementation" would be more buggy than the real-world ones :)
Comment 4 Alexander Larsson 2009-10-06 05:08:03 UTC
Yes, xdgmime does not implement the spec right here, however its not a huge practical problem because the major user of xdgmime (glib) uses the api in such a way that the mimetype detection works out rightly.
Comment 5 David Faure 2011-10-23 22:19:55 UTC
Fixed in 3c8949ec482.

This allows to have correct expected results in shared-mime-info's tests/list, now that other implementations share this test suite to ensure maximum interoperability.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.