[shared-mime-info] update from 1.2-2 to 1.3-1 "breaks" .iso files (.txt file icon / behavior).

Submitted by AndrzejL

Assigned to Shared Mime Info group

Link to original bug (#80877)

Description

Hi there.

This is an issue that is out there for quite a while (31 May 2014) although I have just recently noticed it.

shared-mime-info update from 1.2-2 to 1.3-1 "breaks" .iso files (.txt file icon / behavior).

pacman -Qi shared-mime-info

Name : shared-mime-info Version : 1.3-1 Description : Freedesktop.org Shared MIME Info Architecture : i686 URL : http://freedesktop.org/Software/shared-mime-info Licenses : GPL2 Groups : None Provides : None Depends On : libxml2 glib2 Optional Deps : None Required By : akonadi cmake fceux gtk2 gtk3 kdelibs libreoffice-common virtualbox Optional For : None Conflicts With : None Replaces : None Installed Size : 4104.00 KiB Packager : CENSORED for privacy purposes. Build Date : Sat 31 May 2014 19:16:25 IST Install Date : Mon 30 Jun 2014 15:33:46 IST Install Reason : Installed as a dependency for another package Install Script : Yes Validated By : Signature

I have found confirmation here:

https://bbs.archlinux.org/viewtopic.php?id=182287

All You have to do is upgrade as usual (at least in Arch Linux). Open lets say Dolphin file manager. Browse to any folder that contains lets say Arch Linux iso. You will notice that the iso has a .txt file icon. Also if You right click on it and choose "Open With" You will get text editors.

http://postimg.org/image/d791o7urx/

Its not a major issue but it can be annoying :).

Thanks in advance.

Kind regards.

Andrzej

Bastien Nocera said:

Can't reproduce here in nautilus, so I'm guessing it's a regression in your file manager.

AndrzejL said:

Installed nautilus. It shows .iso files just fine indeed...

I will leave this open for a while and will try getting KDE / dolphin devs attention.

Thanks Bastien!

AndrzejL said:

Reported it here:

https://bugs.kde.org/show_bug.cgi?id=337035

Just in case someone search for the continuation.

Cheers.

Andrzej

Bastien Nocera said:

Please reopen if it turns out to be a shared-mime-info bug nonetheless.

marguerite submitted a patch:

Hi,

Can you review this again please?

I think this commit cause the problem:

http://cgit.freedesktop.org/xdg/shared-mime-info/commit/?id=4b0bc62b3e50f25d0ef42950e0b715274637c548

After commenting the "Wii disc image" and "GameCube disc image" block,

The mimetype is correct again.

This commit was made exactly between 1.2 and 1.3.

I think there's some conflict between these *.iso glob matches, so it fallbacks to .txt. That's my theory, but you're the expert :-)

Thanks

Marguerite

Patch 109396, "patch fix the problem":
freedesktop.org.xml.patch

Roman Bysh said:

I was able to replicate marguerite's findings on my openSUSE 13.2 KDE 4.14.2.

The commit patch for "Add PC Engine, GameCube and Wii "ROM" types" is the culprit. See: http://cgit.freedesktop.org/xdg/shared-mime-info/commit/?id=4b0bc62b3e50f25d0ef42950e0b715274637c548 Dated 2014-01-19

I downloaded shared-mime-info v1.2, extracted the freedesktop.org.xml file to /usr/share/mime/packages/ and it fixed the iso file association.

I also tested the problem commit patch by commenting out the entire block. It fixed the problem.

The file association returned to the correct raw CD image file association. Including the icon.

Rex Dieter said:

Resetting assignee

Bastien Nocera said:

(In reply to marguerite from comment 5)

Created attachment 109396 [details] [review] patch fix the problem

Hi,

Can you review this again please?

I think this commit cause the problem:

http://cgit.freedesktop.org/xdg/shared-mime-info/commit/ ?id=4b0bc62b

After commenting the "Wii disc image" and "GameCube disc image" block,

The mimetype is correct again.

This commit was made exactly between 1.2 and 1.3.

I think there's some conflict between these *.iso glob matches, so it fallbacks to .txt. That's my theory, but you're the expert :-)

There is a conflict. The file manager is supposed to use the magic to differentiate the mime-types. Is it doing that? I'm guessing it isn't.

Roman Bysh said:

Is there a way of adding a higher priority to the two glob patterns?

>>>

Roman Bysh said:

Follow Up

Can you please consider adding the "glob weight" as shown below?

Then run: update-mime-database /usr/share/mime

Any thoughts?

Roman Bysh said:

Follow up please. I think this will resolve the problem.

Can you please consider adding this to shared-mime-info 1.4? Many users are waiting for this correction.

Florian Hubold said:

(In reply to Roman Bysh from comment 11)

Follow up please. I think this will resolve the problem.

Works pretty well here. Before, a lot of "text/plain (accuracy 5)"

for i in *iso; do echo $i $(kmimetypefinder $i 2>/dev/null) ; done chakra-2012.10-Claire-x86_64.iso text/plain (accuracy 5) chakra-2013.03-Benz-x86_64.iso text/plain (accuracy 5) Hybryde_Evolution_v1-live-dvd-32bits.iso application/x-cd-image (accuracy 20) kali-linux-1.0.2-amd64.iso text/plain (accuracy 5) kubuntu-13.04-beta1-desktop-amd64.iso application/x-cd-image (accuracy 20) linuxmint-14-kde-dvd-64bit.iso text/plain (accuracy 5) live-razorqt-20121023-i586.iso application/x-cd-image (accuracy 20) Mandriva_Pulse_Demo_1.4.2.iso application/x-cd-image (accuracy 20) maui-0.5.1-x86_64.iso text/plain (accuracy 5) maui-0.5.1-x86.iso text/plain (accuracy 5) MBS_1.0-soho.x86_64.iso application/x-cd-image (accuracy 20) Minimal_Klyde.x86_64-0.1.2.iso text/plain (accuracy 5) ocz_tools_316.iso application/x-cd-image (accuracy 20) siduction-12.2.0-ridersonthestorm-rqt-amd64-201212092240.iso text/plain (accuracy 5) SolusOS-amd64-1-2.iso text/plain (accuracy 5) solydk64_201306.iso text/plain (accuracy 5) trinity-rescue-kit.3.4-build-372.iso application/x-cd-image (accuracy 20)

And afterwards, all images "application/x-cd-image (accuracy 100)":

for i in *iso; do echo $i $(kmimetypefinder $i 2>/dev/null) ; done chakra-2012.10-Claire-x86_64.iso application/x-cd-image (accuracy 100) chakra-2013.03-Benz-x86_64.iso application/x-cd-image (accuracy 100) Hybryde_Evolution_v1-live-dvd-32bits.iso application/x-cd-image (accuracy 100) kali-linux-1.0.2-amd64.iso application/x-cd-image (accuracy 100) kubuntu-13.04-beta1-desktop-amd64.iso application/x-cd-image (accuracy 100) linuxmint-14-kde-dvd-64bit.iso application/x-cd-image (accuracy 100) live-razorqt-20121023-i586.iso application/x-cd-image (accuracy 100) Mandriva_Pulse_Demo_1.4.2.iso application/x-cd-image (accuracy 100) maui-0.5.1-x86_64.iso application/x-cd-image (accuracy 100) maui-0.5.1-x86.iso application/x-cd-image (accuracy 100) MBS_1.0-soho.x86_64.iso application/x-cd-image (accuracy 100) Minimal_Klyde.x86_64-0.1.2.iso application/x-cd-image (accuracy 100) ocz_tools_316.iso application/x-cd-image (accuracy 100) siduction-12.2.0-ridersonthestorm-rqt-amd64-201212092240.iso application/x-cd-image (accuracy 100) SolusOS-amd64-1-2.iso application/x-cd-image (accuracy 100) solydk64_201306.iso application/x-cd-image (accuracy 100) trinity-rescue-kit.3.4-build-372.iso application/x-cd-image (accuracy 100)

So this is at least better then before, so should be pushed.

emr..@..il.com said:

I had to up the weight here to 100 and comment out the wii/game cube xml to get it to work for me. Fedora 21 KDE 4.14.4 Dolphin 14.11.97

Bastien Nocera said:

Your file manager is still broken though.

commit 824cff3d Author: Bastien Nocera hadess@hadess.net Date: Wed Feb 18 10:37:36 2015 +0100

Bump priority for ISO images glob matching

To work-around file managers that cannot use magic to differentiate
mime-types.

https://bugs.freedesktop.org/show_bug.cgi?id=80877

Roman Bysh said:

Bastien

Thank you for accepting the patch.

As far as I can remember KDE Dolphin, Konqueror and MC have never used magic. They always relied directly on shared-mime-info.

Bastien Nocera said:

(In reply to Roman Bysh from comment 15)

Bastien

Thank you for accepting the patch.

As far as I can remember KDE Dolphin, Konqueror and MC have never used magic. They always relied directly on shared-mime-info.

shared-mime-info is the one providing the magic...

Roman Bysh said:

I'll submit a new bug report on kdelibs and Dolphin for them to look into.

Can you backport this patch into shared-mime-info 1.4 or do we wait for 1.5?

Bastien Nocera said:

(In reply to Roman Bysh from comment 17)

I'll submit a new bug report on kdelibs and Dolphin for them to look into.

Can you backport this patch into shared-mime-info 1.4 or do we wait for 1.5?

You should ask your distribution, using that distribution's channels.

Roman Bysh said:

Yes. It has already been patched and provided for download.

I used "mc" (midnight commander) to view the openSUSE ISO for Tumbleweed. The following was viewed at the beginning of the ISO:

<--- snip ----------------------------------------------------- CD-ROM is in ISO 9660 format System id: LINUX Volume id: openSUSE-Tumbleweed-DVD-x86_6400 Volume set id: Publisher id: SUSE LINUX GmbH Data preparer id: KIWI - http://opensuse.github.com/kiwi Application id: openSUSE-Tumbleweed-DVD-x86_64-Build0002-Media Copyright File id: Abstract File id: Bibliographic File id: Volume set size is: 1 Volume set sequence number is: 1 Logical block size is: 2048 Volume size is: 2257732 El Torito VD version 1 found, boot catalog is in sector 20 Joliet with UCS level 3 found Rock Ridge signatures version 1 found Eltorito validation header: Hid 1 Arch 0 (x86) ID 'SUSE LINUX GmbH' Key 55 AA <--- snip -----------------------------------------------------

Does the Eltorito validation header key "55 AA" provide additional information to identify this iso? Can it be added?

When using GNOME's Nautilus filemanager. Does it use magic to differentiate mime-types?

Roman Bysh uploaded an attachment:

Attachment 113771, "ISO viewed in midnight commander":

Roman Bysh uploaded an attachment:

Attachment 113772, "openSUSE ISO with Preferences viewed in Dolphin using KDE4.14.4":

Roman Bysh uploaded an attachment:

Attachment 113773, "Correct upload of openSUSE ISO":

Roman Bysh uploaded an attachment:

Attachment 113849, "ISO png file viewed in midnight commander":

Roman Bysh said:

I have kept our Bugzilla apprised of the date of your patch. Our "shared-mime-info" package was available several days after your patch was applied to the shared-mime-info master.

The openSUSE 13.2 update version number is shown below:
shared-mime-info 1.4-2.4.1 rpm package

Build date: Fri 20 Feb 2015 07:55:28 AM EST

I would recommend to users still experiencing this problem to check their distro for an update. It should have been available in the first quarter of 2014.

Or you can manually add this line below to the x-cd-image entry to the file freedesktop.org.xml.

``

In openSUSE 13.2 and Tumbleweed: The file name can be found in /usr/share/mime/packages/freedesktop.org.xml

Note: Depending on the distro a slightly different file name may be used.

David Faure @faure said:

Bastien: you say "There is a conflict. The file manager is supposed to use the magic to differentiate the mime-types.".

My code in Qt and KDE certainly does that, as per the spec.

The problem is, there is no magic for application/x-cd-image.

So what should we do in such a case?

Sounds like Nautilus will reject the other two candidates because their magic doesn't match, and then fallback to the mimetype without magic?

That seems to be against the spec, which says

"...start by doing a glob match of the filename. Keep only globs with the biggest weight. [...] If the glob matching fails or results in multiple conflicting mimetypes, read the contents of the file and do magic sniffing on it. If no magic rule matches the data (or if the content is not available), use the default type of application/octet-stream for binary data, or text/plain for textual data. [...]"

We are in the "no magic rule matches" case here, aren't we?

As Frank Reininghaus analysed in KDE bug 337035:

1. It looks like KDE software does exactly what the spec demands.

2. The commit http://cgit.freedesktop.org/xdg/shared-mime-info/commit/?id=4b0bc62b3e50f25d0ef42950e0b715274637c548, which added the other mime types for the *.iso pattern, is broken, because it made detecting the application/x-cd-image type impossible for any application that follows the spec.

3. The "fix" http://cgit.freedesktop.org/xdg/shared-mime-info/commit/?id=824cff3da0f17812715795f0e64a47f7331a338b is equally broken, because it makes detecting the "new" mime types application/x-wii-rom and application/x-gamecube-rom impossible for any application that follows the spec.

4. The correct solution for the *.iso issue would be to give all types the same glob weight and, most importantly, also "magic" patterns that can be used to detect them, including application/x-cd-image.

It seems you rejected that idea in https://bugs.freedesktop.org/show_bug.cgi?id=10049 - time to revisit it?

Bastien Nocera said:

(In reply to David Faure from comment 25)

Bastien: you say "There is a conflict. The file manager is supposed to use the magic to differentiate the mime-types.".

My code in Qt and KDE certainly does that, as per the spec.

The problem is, there is no magic for application/x-cd-image.

FWIW. This bug is most likely a dupe of bug 97372. The bug only happened in Qt's implementation (and the reference implementation).

Bastien Nocera closed a related bug:

*** Bug 106936 has been marked as a duplicate of this bug. ***

Hi The behavior described in the following link is still happening on Arch Linux running shared-mime-info 1.10-1 and Dolphin 18.08.2 file manager. https://bugs.kde.org/show_bug.cgi?id=387068

Can anyone confirm if such behavior is related to the issue reported here please? Thanks.

Still a bug to today with a recently compiled system.

I guess a question a lot of people would like to know, why does this seem to be specifically broken by following the spec, and why doesn't gnome or whatever is holding this back fix their bug to actually follow the spec as well?

I don't think there's any way we can express a solution to this problem in shared-mime-info. *.iso files have a mime-type, the *.iso glob for application/x-cd-image has more weight than other globs for other mime-types, and a well-formed *.iso that isn't one of the other mime-types will not match them.

I don't really see what else can be fixed on the shared-mime-info database side, short of update the specification. @faure?

First, about your previous comment from a year ago: this bug is NOT a dupe of https://bugs.freedesktop.org/show_bug.cgi?id=97372, which was solved by looking at the first 128 bytes instead of 32. Here we're talking about application/x-cd-image which has no magic, and if it had, it would be at a much bigger offset (https://bugs.freedesktop.org/show_bug.cgi?id=10049).

Second, the big question is whether we are indeed in the "no magic rule matches the data" case. Any mimetype with any matching magic messes up the situation. On my system with shared-mime-info 1.9, this resulted in model/x.stl-binary for some iso files, because that mimetype used to have far-too-unspecific magic (3 nul bytes), fixed in commit 7c7f84e2.

After upgrading to shared-mime-info git master, it actually works: $ kmimetypefinder5 /tmp/maui-0.5.1-x86_64.iso says application/x-cd-image

(downloaded from https://sourceforge.net/projects/mauios/files/0.5/, since it's one of the files that was mentioned to match text/plain in an earlier comment).

@overminddl1, can you do the same test on that same file? If it works for you, can you provide a file (or URL) which fails for you, using kmimetypefinder5?