Bug 108908 - shared-mime-info-spec : add generic .bin type
Summary: shared-mime-info-spec : add generic .bin type
Status: RESOLVED MOVED
Alias: None
Product: Specifications
Classification: Unclassified
Component: shared-mime-info (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Allison Lortie (desrt)
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-30 03:04 UTC by fenugrec
Modified: 2019-02-16 12:26 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description fenugrec 2018-11-30 03:04:07 UTC
I tried to file this in the same category as https://bugs.freedesktop.org/show_bug.cgi?id=97107 , but bugzilla wouldn't let me !

Incidentally, that bug# is related. It seems application/x-sega-cd-rom and application/x-sega-pico-rom are the only ones to have a <glob pattern="*.bin"/>, so every unrelated .bin file - magic or no - gets identified as Sega ROMs. I'm willing to bet > 99% of .bin files in the universe are not Sega ROMs. Well at least in mine.

Would it be possible to add a generic "application/x-bin" type , or "application/x-raw-dump" (or any other appropriate name) that can be the default fallback for .bin extensions ? 

Thanks!
Comment 1 David Faure 2019-01-05 00:23:06 UTC
What application exists that can handle *any* kind of *.bin type?
Rethorical question: none.
So a generic mimetype for *.bin would be useless.

But let's talk about the actual problem before we talk about possible solutions :)
When two mimetypes have the same glob, the spec says content should be used instead.

Which implementation is giving you Sega for all .bin files?
A proper implementation should give application/octet-stream when neither magic from the two mimetypes matches.

Example:
$ kmimetypefinder5 /usr/share/syslinux/gptmbr.bin
(no output, error code 1, which means application/octet-stream)
Comment 2 fenugrec 2019-01-07 14:26:36 UTC
> What application exists that can handle *any* kind of *.bin type?
> Rethorical question: none.

I would argue "all hex editors", which is probably a more widespread use than Sega emulation, but granted that doesn't really qualify as a "generic mimetype".

> Which implementation is giving you Sega for all .bin files?
lxqt, with Arch linux's default "shared-mime-info" package, generated thus :
https://git.archlinux.org/svntogit/packages.git/plain/trunk/PKGBUILD?h=packages/shared-mime-info


> A proper implementation should give application/octet-stream when neither
> magic from the two mimetypes matches.
Ah, I think you nailed it. I don't have "kmimetypefinder5" but with a similar
$ xdg-mime query filetype romdump.bin

I get the expected application/octet-stream. I didn't realize the implementation had to handle a "fallback" case like this; I'll enquire with the lxqt devs.
Comment 3 fenugrec 2019-01-07 16:33:46 UTC
Well, I've been running a lot of tests :

### 'file' which uses its own magic database
$ file --brief --mime-type test.bin
application/octet-stream

### mimeinfo uses the system-wide shared MIME-info database, but returns a different type depending on whether the extension is ignored or the magic is verified:

$ mimetype --brief --debug test.bin
> Checking inode type
> Checking globs for basename 'test.bin'
> Checking for extension '.bin'
application/x-sega-cd-rom

$ mimetype --brief --magic-only --debug test.bin
> Checking all magic rules
> File exists, trying default method
> First 10 bytes of the file contain control chars
application/octet-stream


### GNOME's gvfs / gio
$ gio info test.bin  | grep "content-type"
  standard::content-type: application/x-sega-cd-rom
  standard::fast-content-type: application/x-sega-cd-rom


So it seems that a number of implementations don't bother to check the magic value. This makes me wonder if it was really important to give the sega types the "*.bin" glob, why not just the magic ?
Comment 4 David Faure 2019-01-13 14:18:29 UTC
"all hex editors" is exactly what one expects to get as the (only) associated application when the mimetype is application/octet-stream.

Those implementation that you tested, and which return application/x-sega-cd-rom with their default settings (not magic-only), are not compliant with the shared-mime-info recommended checking order (which says, look at magic when two globs conflict, and fallback to octet-stream if none matches). Please file bugs with these implementations.

> This makes me wonder if it was really important to give the sega types the "*.bin" glob, why not just the magic ?

That's a good question, actually. Globs are useful when they allow to skip magic checking. But defining conflicting globs in shared-mime-info indeed doesn't serve much purpose (when other mimetypes can also match).

Oh, and we used to have *.bin for application/octet-stream and I removed it in 009f22a.

Adrien, Bastien, any objection if I remove *.bin from application/x-sega-cd-rom and application/x-saturn-rom?
Comment 5 GitLab Migration User 2019-02-16 12:26:45 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xdg/shared-mime-info/issues/101.


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.