Use content to determine mime type
ClosedPublic

Authored by astippich on Feb 7 2019, 5:21 PM.

Details

Summary

Determine the mime type for the
extractors based on the content, not on the file
extension. This avoids feeding files with a wrong
or the same file extension into the wrong extractor.

CCBUG: 403902

Diff Detail

Repository
R293 Baloo
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
astippich created this revision.Feb 7 2019, 5:21 PM
Restricted Application added projects: Frameworks, Baloo. · View Herald TranscriptFeb 7 2019, 5:21 PM
Restricted Application added subscribers: Baloo, kde-frameworks-devel. · View Herald Transcript
astippich requested review of this revision.Feb 7 2019, 5:21 PM
ngraham accepted this revision.Feb 7 2019, 7:37 PM

The default match mode tries both file extension and content; this would make it just do content. So I guess if they don't match, the default match mode uses the file extension rather than content? That seems kinda like the opposite of the behavior you'd want; might be worth a Qt bug report and aldo a comment in the code here explaining why we're doing this.

The change itself seems sane since we're actually doing less, more correct work now.

What more is needed to fix 403902?

This revision is now accepted and ready to land.Feb 7 2019, 7:37 PM

The default match mode tries both file extension and content; this would make it just do content. So I guess if they don't match, the default match mode uses the file extension rather than content? That seems kinda like the opposite of the behavior you'd want; might be worth a Qt bug report and aldo a comment in the code here explaining why we're doing this.

The change itself seems sane since we're actually doing less, more correct work now.

What more is needed to fix 403902?

The file extension always has priority over the content according to docs.
This is actually more a workaround for the bug (but still the right thing to do nevertheless), we now make sure that Baloo never calls the crashing extractor for the problematic files. The crash inside the extractor actually remains.
I have the real fix for crash actually ready, but it is more a complete rewrite of the taglib extractor.

Thanks, +1 shipit!

This revision was automatically updated to reflect the committed changes.