QMimeDatabase may not use mime type file globs properly

On my system, I'm experiencing an issue where some Typescript (.ts) files are assigned an incorrect mime type (text/x-csrc) and some are assigned a mime type I added to my account's mime type database. Here's what I think is happening.

The system mime type database on my install (in /usr/share/mime/freedesktop.org.xml) comes with two other definitions for .ts files,

  <mime-type type="text/vnd.trolltech.linguist">
    ...
    <glob pattern="*.ts"/>
    ...
  </mime-type>
  <mime-type type="video/mp2t">
    ...
    <glob pattern="*.ts"/>
    ...
  </mime-type>

In my user account's mime database (/home/patrickking/.local/share/mime/packages) I've created config files to remove these glob matches (and to remove the glob match for text/x-csrc for good measure), along with adding a custom mime type for text/x.typescript. I did this using KDE's GUI for file type management, and I've included the resulting package/*.xml files in the attachment.

On my system, kmimetypefinder5 is a thin wrapper around QMimeDatabase.mimeTypeForFile().

$ kmimetypefinder5 mime-c-source.ts
text/x-csrc

# This calls:
# qMimeDatabase.mimeTypeForFile(fileName, QMimeDatabase::MatchContent);
$ kmimetypefinder5 -c mime-c-source.ts
text/x-csrc

# This calls:
# qMimeDatabase.mimeTypeForFile(fileName, QMimeDatabase::MatchExtension);
$ kmimetypefinder5 -f mime-c-source.ts
text/x.typescript

QMimeDatabase gives us the desired mime type when only looking at the file extension, but when using file content or when allowed to use both it gives us the C source type.

Looking at the logic in QMimeDatabase.mimeTypeForFileNameAndData

• The mime type matcher (when not told to look only at content or filename) tries to match on the file extension first
• Then, if there is more than one matched mime type for the extension (for example, if the globs for the other two .ts types are not being properly ignored), it adds file content / magic mime types to the list of potential types
• If a mime type appears in both the content and filename derived lists, it is returned
• If there is no overlap between the content and filename derived mime types, the first content or filename mime type in sorted order is returned

I think that the <glob-deleteall> elements for the other two .ts mime types aren't being obeyed, resulting in file magic being used to match some .ts files, and then text/x-csrc wins out as it's first in sorted order. (The magic in this case is to look for // and /* early in the file, which some .ts files have and some do not).

I also tried editing the system mime types in /usr/share/mime/freedesktop.org.xml to remove the *.ts globs there. After rebuilding the database, kmimetypefinder5 no longer returns text/x-csrc for any .ts files.

There is also this comment in qmimedatabase.cpp.

In addition to the package/*xml files from my account's mime type database, I've also included two .ts files in the attachment: one which gets classed as C source and one which gets classed as Typescript.

I hope this helps to reproduce the issue! Please let me know if there's anything else I can provide (though I'm not set up to do development work on QT).