Since the first glob is often used as the default extension when saving, having "*.bin" in application/octet-stream leads to file dialogs automatically adding a ".bin" extension when apps try to have some "all files" filter. In addition I see no purpose in this glob for matching (given that application/octet-stream is the fallback anyway).
(In reply to David Faure from comment #0) > Since the first glob is often used as the default extension when saving, > having "*.bin" in application/octet-stream leads to file dialogs > automatically adding a ".bin" extension when apps try to have some "all > files" filter. > > In addition I see no purpose in this glob for matching (given that > application/octet-stream is the fallback anyway). application/octet-stream isn't the same as "any" mime-type though, is it? I don't know the side-effects it could have on the detection, or the negative detection of the mime-types that do use *.bin as a glob, depending on the implementation.
This bug affects nautilus via gio's function g_content_type_can_be_executable. See https://bugzilla.gnome.org/show_bug.cgi?id=571377 (In reply to Bastien Nocera from comment #1) > I don't know the side-effects it could have on the detection, or the > negative detection of the mime-types that do use *.bin as a glob, depending > on the implementation. Currently, if we rename a files to remove the .bin extension, it's type can be detected more precisely. By classifying *.bin as octet-stream, the more precise detection seems to be bypassed. To test, add ".bin" to the name of an "application/x-executable" file. It becomes "application/octet-stream". As a consequence, it's no longer identified as potentially executable by g_content_type_can_be_executable. While this test is artificial, there are real applications shipped with a *.bin binary mean to be launched[*]. This becomes an actual user-facing bug in a file manager. [*] Yes, this is wrong and they should use .desktop files and ship a proper .flatpak bundle for instance. But it's just an example.
Done in 009f22a.
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.