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)

> 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.

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 ?

"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?

-- 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.