Bug 337035 - KDE does not play well with shared-mime-info after update from 1.2-2 to 1.3-1. "Breaks" .iso files (.txt file icon / behavior).
Summary: KDE does not play well with shared-mime-info after update from 1.2-2 to 1.3-1...
Status: RESOLVED UPSTREAM
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: kdecore (show other bugs)
Version: 4.13.2
Platform: Arch Linux Linux
: NOR minor
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
: 346804 348003 387068 400275 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-07-04 09:22 UTC by AndrzejL
Modified: 2018-10-25 19:33 UTC (History)
21 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
it was iso then change to txt (59.13 KB, image/gif)
2014-11-13 09:15 UTC, margueritesu
Details
/usr/share/mime/packages/freedesktop.xml patch (937 bytes, patch)
2014-11-13 09:46 UTC, margueritesu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description AndrzejL 2014-07-04 09:22:40 UTC
Hi there.

The best explanation I am guessing would be this:

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

and adding that Nautilus picks up the .iso files just fine.

Some more details. Upgraded as usual using stable Arch Linux repositories. Noticed (after a longer while) that my .iso files are shown as .txt files and that dolphin tries to open them in kwrite. Downgraded shared-mime-info - fixed the issue. Upgraded yet again. Broke the .iso file. Reported bug in Arch Linux bug catcher. Was told to upstream it. Reported it (link above) in the shared-mime-info bugzilla. Was told its a dolphin regression. Here I am now :).

Thanks in advance.

Andrzej

Reproducible: Always

Steps to Reproduce:
1. Upgrade Dolphin to 4.13.2 and shared-mime-info 1.3.1
2. Reboot
3. Open Dolphin
4. Navigate to the folder containing .iso files
5. Try opening .iso  file
Actual Results:  
Instead of opening the file in lets say k3b kwrite will be open and in the low spec machines total freeze will occur ;).

Expected Results:  
k3b should open the file.

Marking it as minor. k3b > tools > burn image is a quick and dirty workaround.
Comment 1 Frank Reininghaus 2014-07-04 12:18:33 UTC
Thanks for the bug report.

(In reply to comment #0)
> Was told its a dolphin regression.

A Dolphin regression would be a bug in Dolphin x.y.(z+1) which did not exist in x.y.z. If I understand correctly, this is definitely not the case here, since whether the bug appears or not does not depend on the Dolphin/KDE version at all.

It could be that it is a latent bug in KDE that was not noticed before, and which was triggered by the shared-mime-info update. However, since Dolphin does not interact with this package directly, it would probably a bug somewhere in kdelibs.

Have you tried if rebooting the system or running kbuildsycoca4 in a shell fixes the problem?

BTW, there is no need to put [dolphin] into the summary. Each bug report has a 'Product' field for that.
Comment 2 AndrzejL 2014-07-04 13:02:37 UTC
You're welcome Frank.

Like I said I _was_told_ that its a regression :). As a non-coder / dev all I can do is pass the information along and try whatever the troubleshooting / debugging steps are being thrown my way :).

Thanks for the info. Different bug catchers different rules... Some demand [package] as a first thing in the "subject" line. Some don't. I went from forum post to arch linux bug catcher, mime info bug catcher and now I am here :). I will try to remember about that rule in the future tho.

Rebooted multiple times since noticing this bug - does not helps. Ran the kbuildsycoca4 in the konsole. Bug persists.

Kind regards.

Andrzej
Comment 3 Karthik Periagaram 2014-07-04 18:29:13 UTC
I can confirm this behavior.

Till Dolphin is restarted, it continues to recognize the type of the ISO file correctly (raw CD image) and offers to open with the associated applications for application/x-cd-image. This is the desired behavior.

Once Dolphin is restarted with the new shared-mime-info package having been installed, the icon changes to that of a plain text file, Dolphin identifies the type as plain text document and the applications presented for opening the file are those associated with text/plain.

I'm also using the same packages as the AndrzejL, shared-mime-info 1.3-1 and the latest kde packages on arch.
Comment 4 Frank Reininghaus 2014-07-06 21:11:19 UTC
(In reply to comment #2)
> Like I said I _was_told_ that its a regression :)

I see that Bastien Nocera did probably not know yet that downgrading shared-mime-info "fixes" the problem, so he probably thought that you upgraded Dolphin and shared-mime-info at the same time. In that case, one could really come to the conclusion that it might be a Dolphin/KDE regression.

In any case, as I said, it can very well be a bug in KDE, maybe a latent bug that could for some reason not be reproduced with older shared-mime-info versions.

I see that you closed the bug as NEEDSINFO - this actually means that further info is required from the bug reporter. I don't know if that is really the case, and I cannot test the latest shared-mime-info version myself easily. If you still have this problem, feel free to reopen the report.
Comment 5 AndrzejL 2014-07-06 21:44:22 UTC
I did didn't I... I am such a moose... I was multitasking while posting the previous reply and obviously just got all confused as always when there is multitasking involved... Sorry. The bug is still open / not fixed I think unconfirmed was the correct status. Even tho Karthik confirmed it. It could be kde4 bug indeed. I mean its most probably kde bug. Hoping You guys can track it down and squash it as you always do.

Cheers.

Andrzej
Comment 6 Roman Bysh 2014-11-03 21:39:23 UTC
I have the same problem with shared-mime-info 1.3-2.1.3 with openSUSE 13.2. All ISOs downloaded
appear as text plain. 

This problem did not exist with openSUSE 13.1 and earlier versions.

Regards,

Roman
Comment 7 Roman Bysh 2014-11-03 21:40:57 UTC
Follow Up

Using KDE4 Version 4.14.2
Comment 8 Roman Bysh 2014-11-11 21:38:20 UTC
I checked /usr/share/mime/packages/freedesktop.org.xml in openSUSE 13.2.

The end entry for x-cd-image now uses:

<sub-class-of type="application/x-raw-disk-image"/>
<alias type="application/x-iso9660-image"/>
<glob pattern="*.iso"/>
<glob pattern="*.iso9660"/>
</mime-type>

Whereas openSUSE 13.1 used:

<alias type="application/x-iso9660-image"/>
<glob pattern="*.iso"/>
<glob pattern="*.iso9660"/>
</mime-type>

The new subclass of type entry is not understood by kdelibs/dolphin. 

Could this be the problem?
Comment 9 margueritesu 2014-11-13 09:15:50 UTC
Created attachment 89574 [details]
it was iso then change to txt

Hi, everyone,

I have some brand new findings! and I think it can help proceeding this bug to a new level!

I'm an openSUSE developer, ocassionally one local user presesnted me this problem on a local forum. I found 3 bug reports (an Archlinux one, a freedesktop one, and this), and it seems currently you guys all have no idea which side to blame...

I don't trust the "fix"/"workaround" from Manjaro guys. because the fix has _exactly_ the same content as /usr/share/mime/application/x-cd-image.xml, there's also a same content in /usr/share/mime/application/freedesktop.xml. so if we have 2, why a 3rd one will work?!

When I scroll in Dolphin, I noticed the icon of the "iso" will _change_!

I recorded a video, and snapshot some pictures to make a .gif to prove myself in the attachment.

So why the mimetype changed from .iso to .txt?!

Another finding is that if you copy /usr/share/mime/application/x-cd-image.xml to ~/.local/share/mime/application, then run "/usr/bin/update-mime-database ~/.local/share/mime/application", then ~/.local/share/mime/application/x-cd-image.xml will disappear!

Greetings

Marguerite
Comment 10 margueritesu 2014-11-13 09:46:49 UTC
Created attachment 89575 [details]
/usr/share/mime/packages/freedesktop.xml patch

Problem solved!

It seems not a dolphin's bug.

I checked every commit between shared-mime-info 1.2 and 1.3 at http://cgit.freedesktop.org/xdg/shared-mime-info/log and found this specific commit which cause the problem:

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

the patch in the attachment will work

PS: I made one thing wrong: /usr/share/mime/application/x-cd-image.xml is generated from /usr/share/mime/packages/freedesktop.xml, so there's no 2 files with the same content, actually they come from the same source.
Comment 11 Roman Bysh 2014-11-14 03:16:20 UTC
On 11/13/2014 04:46 AM, margueritesu wrote:
> https://bugs.kde.org/show_bug.cgi?id=337035
>
> --- Comment #10 from margueritesu <i@marguerite.su> ---
> Created attachment 89575 [details]
>   --> https://bugs.kde.org/attachment.cgi?id=89575&action=edit
> /usr/share/mime/packages/freedesktop.xml patch
>
> Problem solved!
>
> It seems not a dolphin's bug.
>
> I checked every commit between shared-mime-info 1.2 and 1.3 at
> http://cgit.freedesktop.org/xdg/shared-mime-info/log and found this specific
> commit which cause the problem:
>
> http://cgit.freedesktop.org/xdg/shared-mime-info/commit/?id=4b0bc62b3e50f25d0ef42950e0b715274637c548
>
> the patch in the attachment will work
>
> PS: I made one thing wrong: /usr/share/mime/application/x-cd-image.xml is
> generated from /usr/share/mime/packages/freedesktop.xml, so there's no 2 files
> with the same content, actually they come from the same source.
>
I tried the patch on openSUSE 13.2. However, those changes are already included.
No change. I keep getting a message that it already exists.

Do you have a copy of your /usr/share/mime/packages/freedesktop.org.xml file.
The one that resolved the ISO problem. Can you please email me a copy?

What if we were to comment out the entire section about wii?
Comment 12 Roman Bysh 2014-11-14 19:31:59 UTC
Follow Up
Margueritesu is correct. 
I was able to duplicate the problem related to the patch for " PC Engine, GameCube and Wii "ROM" types ". Once the entire "Wii disc image" and "GameCube disc image" entry block is commented out --lines 7951 to 7972 -- the iso image files are now correct. 

Problem patch:
See:  http://cgit.freedesktop.org/xdg/shared-mime-info/commit/?id=4b0bc62b3e50f25d0ef42950e0b715274637c548
Comment 13 Roman Bysh 2014-11-19 01:19:30 UTC
Status Please

We've had a number of users using openSUSE 13.2 confirm that the patch below broke the iso file association. This is the one added after the
release of shared-mime-info v1.2 and introduced in v 1.3.
<--- snip----------------------------------------------------------------------------
diff --git a/freedesktop.org.xml.in b/freedesktop.org.xml.in
index 9d06800..fe090dc 100644
--- a/freedesktop.org.xml.in
+++ b/freedesktop.org.xml.in
@@ -1624,6 +1624,33 @@ command to generate the output files.
     <generic-icon name="application-x-executable"/>
     <glob pattern="*.nds"/>
   </mime-type>
+  <mime-type type="application/x-pc-engine-rom">
+    <_comment>PC Engine ROM</_comment>
+    <generic-icon name="application-x-executable"/>
+    <glob pattern="*.pce"/>
+  </mime-type>
+  <mime-type type="application/x-wii-rom">
+    <_comment>Wii disc image</_comment>
+    <alias type="application/x-wii-iso-image"/>
+    <alias type="application/x-wbfs"/>
+    <alias type="application/x-wia"/>
+    <generic-icon name="application-x-executable"/>
+    <glob pattern="*.iso"/>
+    <magic priority="50">
+      <match offset="24" type="big32" value="0x5d1c9ea3"/>
+      <match offset="0" type="string" value="WBFS"/>
+      <match offset="0" type="string" value="WII\001DISC"/>
+    </magic>
+  </mime-type>
+  <mime-type type="application/x-gamecube-rom">
+    <_comment>GameCube disc image</_comment>
+    <generic-icon name="application-x-executable"/>
+    <alias type="application/x-gamecube-iso-image"/>
+    <glob pattern="*.iso"/>
+    <magic priority="50">
+      <match offset="28" type="big32" value="0xc2339f3d"/>
+    </magic>
+  </mime-type>
   <mime-type type="application/x-deb">
     <_comment>Debian package</_comment>
     <alias type="application/x-debian-package"/>
<--- snip---------------------------------------------------------------------------
I'm still concerned why this worked in GNOME's nautilus but broken in dolphin and lxde's PCManFM. Perhaps they are more strict with file associations than in GNOME.
Comment 14 Roman Bysh 2014-12-21 19:13:34 UTC
Status please.
Comment 15 Rex Dieter 2014-12-21 19:35:12 UTC
Fwiw, I cannot reproduce this on fedora 21 with shared-mime-info-1.3

$ rpm -q shared-mime-info
shared-mime-info-1.3-15.fc21.1.x86_64

(downloaded an .iso to test)

$ kmimetypefinder Fedora-Server-netinst-x86_64-21.iso 
application/x-cd-image
(accuracy 20)

(not  impressed with the low accuracy value though).

And dolphin offers to open it in ark/k3b as the top 2 associated apps.
Comment 16 Hrvoje Senjan 2014-12-22 23:20:39 UTC
(In reply to Rex Dieter from comment #15)
> Fwiw, I cannot reproduce this on fedora 21 with shared-mime-info-1.3
> ...

i can confirm the same results with latest openSUSE Tumbleweed/Factory... as s-m-i wasn't updated, most likely the underlying bug was somewhere else...
Comment 17 Roman Bysh 2014-12-23 02:55:51 UTC
Perhaps the kdelibs and dolphin in Tumbleweed been updated compared to openSUSE 13.2.
Please check the exact version of KDE4 you are using and post it? 

What other applications/libraries rely on /usr/share/mime/packages/freedesktop.org.xml?
Shouldn't this be found in the changelogs. It must be logged somewhere. Yes.

Was Plasma 5 affected?

I'm installing Tumbleweed tonight and Plasma 5 tomorrow. So I'll check.
Comment 18 Florian Hubold 2014-12-25 17:24:42 UTC
(In reply to Rex Dieter from comment #15)
> Fwiw, I cannot reproduce this on fedora 21 with shared-mime-info-1.3

> (downloaded an .iso to test)
> 
> $ kmimetypefinder Fedora-Server-netinst-x86_64-21.iso 
> application/x-cd-image
> (accuracy 20)
> 
> (not  impressed with the low accuracy value though).
> 
> And dolphin offers to open it in ark/k3b as the top 2 associated apps.

That's not sufficient as a test, as it depends on the image used for testing. E.g. in a folder with various collected linux images here, this yields:

$ 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)

This is what file shows for those images:

$ file *iso
chakra-2012.10-Claire-x86_64.iso:                             DOS/MBR boot sector
chakra-2013.03-Benz-x86_64.iso:                               DOS/MBR boot sector
Hybryde_Evolution_v1-live-dvd-32bits.iso:                     # ISO 9660 CD-ROM filesystem data 'Hybryde_Evolution_v1' (bootable)
kali-linux-1.0.2-amd64.iso:                                   DOS/MBR boot sector
kubuntu-13.04-beta1-desktop-amd64.iso:                        DOS/MBR boot sector
linuxmint-14-kde-dvd-64bit.iso:                               DOS/MBR boot sector
live-razorqt-20121023-i586.iso:                               DOS/MBR boot sector
Mandriva_Pulse_Demo_1.4.2.iso:                                # ISO 9660 CD-ROM filesystem data 'Mandriva_Pulse_Demo_1.4.2' (bootable)
maui-0.5.1-x86_64.iso:                                        DOS/MBR boot sector
maui-0.5.1-x86.iso:                                           DOS/MBR boot sector
MBS_1.0-soho.x86_64.iso:                                      DOS/MBR boot sector
Minimal_Klyde.x86_64-0.1.2.iso:                               DOS/MBR boot sector
ocz_tools_316.iso:                                            # ISO 9660 CD-ROM filesystem data 'OCZ_TOOLS_316' (bootable)
siduction-12.2.0-ridersonthestorm-rqt-amd64-201212092240.iso: DOS/MBR boot sector
SolusOS-amd64-1-2.iso:                                        DOS/MBR boot sector
solydk64_201306.iso:                                          DOS/MBR boot sector
trinity-rescue-kit.3.4-build-372.iso:                         # ISO 9660 CD-ROM filesystem data 'TRK_3.4' (bootable)

The problem occurs with the images that are recognised as text/plain (or DOS/MBR boot sector by file).
Comment 19 Roman Bysh 2015-01-18 20:13:32 UTC
It's 2015 and the problem still exists in KDE4 and Plasma 5 with ISOs missing the CD icon and text/plain.
Why is it that Nautilus in GNOME does not experience this problem?
Comment 20 Roman Bysh 2015-01-18 20:16:57 UTC
Surely, by now the "Status" should be changed from UNCONFIRMED to CONFIRMED. Yes?
Comment 21 Roman Bysh 2015-02-12 21:59:20 UTC
Follow Up

Please look into add a patch to dolphin to use "magic" to differentiate the mime-types. This should resolve the problem.
Comment 22 EMR_Kde 2015-02-17 14:01:24 UTC
What's the status of this bug, I am having the same problems here:

$ kmimetypefinder CentOS-7.0-1406-x86_64-DVD.iso 
text/plain
(accuracy 5)
$ kmimetypefinder Fedora-Server-DVD-x86_64-21.iso 
application/x-cd-image
(accuracy 20)

$ iso-info CentOS-7.0-1406-x86_64-DVD.iso
iso-info version 0.92 i686-redhat-linux-gnu
ISO 9660 image: CentOS-7.0-1406-x86_64-DVD.iso
Application : GENISOIMAGE ISO 9660_HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE
System      : LINUX
Volume      : CentOS 7 x86_64
Joliet Level: 3

$ iso-info Fedora-Server-DVD-x86_64-21.iso 
iso-info version 0.92 i686-redhat-linux-gnu
ISO 9660 image: Fedora-Server-DVD-x86_64-21.iso
Application : GENISOIMAGE ISO 9660_HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE
System      : LINUX
Volume      : Fedora-S-21-x86_64
Joliet Level: 3

$ file CentOS-7.0-1406-x86_64-DVD.iso Fedora-Server-DVD-x86_64-21.iso 
CentOS-7.0-1406-x86_64-DVD.iso:  # ISO 9660 CD-ROM filesystem data 'CentOS 7 x86_64' (bootable)
Fedora-Server-DVD-x86_64-21.iso: # ISO 9660 CD-ROM filesystem data 'Fedora-S-21-x86_64' (bootable)
Comment 23 EMR_Kde 2015-02-17 14:03:39 UTC
Also I am running Fedora 21.
shared-mime-info-1.3-15.fc21.i686

(In reply to E. Recio from comment #22)
> What's the status of this bug, I am having the same problems here:
> 
> $ kmimetypefinder CentOS-7.0-1406-x86_64-DVD.iso 
> text/plain
> (accuracy 5)
> $ kmimetypefinder Fedora-Server-DVD-x86_64-21.iso 
> application/x-cd-image
> (accuracy 20)
> 
> $ iso-info CentOS-7.0-1406-x86_64-DVD.iso
> iso-info version 0.92 i686-redhat-linux-gnu
> ISO 9660 image: CentOS-7.0-1406-x86_64-DVD.iso
> Application : GENISOIMAGE ISO 9660_HFS FILESYSTEM CREATOR (C) 1993
> E.YOUNGDALE
> System      : LINUX
> Volume      : CentOS 7 x86_64
> Joliet Level: 3
> 
> $ iso-info Fedora-Server-DVD-x86_64-21.iso 
> iso-info version 0.92 i686-redhat-linux-gnu
> ISO 9660 image: Fedora-Server-DVD-x86_64-21.iso
> Application : GENISOIMAGE ISO 9660_HFS FILESYSTEM CREATOR (C) 1993
> E.YOUNGDALE
> System      : LINUX
> Volume      : Fedora-S-21-x86_64
> Joliet Level: 3
> 
> $ file CentOS-7.0-1406-x86_64-DVD.iso Fedora-Server-DVD-x86_64-21.iso 
> CentOS-7.0-1406-x86_64-DVD.iso:  # ISO 9660 CD-ROM filesystem data 'CentOS 7
> x86_64' (bootable)
> Fedora-Server-DVD-x86_64-21.iso: # ISO 9660 CD-ROM filesystem data
> 'Fedora-S-21-x86_64' (bootable)
Comment 24 Florian Hubold 2015-02-17 17:56:18 UTC
This is an upstream bug, see the comment 0

Roman has found a pretty good solution: https://bugs.freedesktop.org/show_bug.cgi?id=80877#c10
Comment 25 Roman Bysh 2015-02-18 23:24:23 UTC
Important Follow Up

A patch has been accepted and applied to the "Master" by the maintainers of shared-mime-info.
See: http://cgit.freedesktop.org/xdg/shared-mime-info/commit/

To work-around file managers that cannot use magic to differentiate mime-types. Bumping priority for ISO images glob matching. 
See: https://bugs.freedesktop.org/show_bug.cgi?id=80877

The original glob pattern entry is:
<glob pattern="*.iso"/>

Changed to:
<glob pattern="*.iso" weight="80"/>
Comment 26 Roman Bysh 2015-02-18 23:26:04 UTC
It has now been resolved.
Comment 27 Frank Reininghaus 2015-02-19 20:40:12 UTC
Thanks for the info and for your efforts to get this issue fixed upstream, Florian and Roman!
Comment 28 Roman Bysh 2015-02-19 20:46:23 UTC
Although the maintainers of shared-mime-info provided a workaround patch for Dolphin. It is still broken. 
Dolphin MUST use magic to differentiate mime-types as it is the proper way. Magic is provided by shared-mime-info.

Can some one please look into this or should I submit a bug report under Dolphin?
This bug does not exist in GNOME and Nautilus.
Comment 29 Frank Reininghaus 2015-02-19 21:22:38 UTC
(In reply to Roman Bysh from comment #28)
> Can some one please look into this or should I submit a bug report under
> Dolphin?

I cannot comment on the magic issue because mime types are not my area of expertise. However, even if your suggestion to use magic is sort of related related to the problem reported here, it is not exactly the same thing and should be reported separately (also because this report has a lot of comments already, and changing the subject now does not make it more understandable).

Note that it is NOT a Dolphin issue - mime type determination is handled for all KDE applications by the same library. I think it might be the KIO framework for KF5-based applications, but AFAIK, it uses this Qt class to determine mime types, so I'm not sure if anything can be done about this in KDE at all:

http://doc.qt.io/qt-5/qmimedatabase.html

 It would be interesting to know if anyone can reproduce the problem with a KF5-based application (like FolderView in Plasma 5, or the KF5-based Dolphin version, which is not released yet and only available as a git branch or as preview packages in some distros). Or even better, if anyone could find out if QMimeDatabase uses the "correct" way to determine mime types.
Comment 30 Roman Bysh 2015-02-23 21:34:25 UTC
Thank you for the info on QMimeDatabase.
We already have a patched "shared-mime-info-1.4-59.1.x86_64.rpm" package for users to download in Factory. 
It is also compatible for openSUSE 13.2.
Comment 31 Rex Dieter 2015-05-02 03:47:28 UTC
*** Bug 346804 has been marked as a duplicate of this bug. ***
Comment 32 David Faure 2015-05-14 23:41:47 UTC
"Dolphin MUST use magic to differentiate mime-types as it is the proper way."
  is very wrong.
See the shared-mime-info spec: the recommended checking order is to trust extensions when the extension is known and non-ambiguous. This allows users to have control.
Magic is only used for unknown extensions as it's not reliable enough to be 100% correct.

QMimeDatabase is correct.
Comment 33 Roman Bysh 2015-05-15 06:16:33 UTC
(In reply to David Faure from comment #32)
> "Dolphin MUST use magic to differentiate mime-types as it is the proper way."
>   is very wrong.
> See the shared-mime-info spec: the recommended checking order is to trust
> extensions when the extension is known and non-ambiguous. This allows users
> to have control.
> Magic is only used for unknown extensions as it's not reliable enough to be
> 100% correct.
> 
> QMimeDatabase is correct.

I agree. This has been a limitation with KDE4 for several years. All we can do is place a request for an "enhancement" with kdelibs4 and dolphin and konqueror. 

The problem also exists in Plasma 5 with dolphin and konqueror due to the fact they share the same library. Everyone - please submit and request a patch for kdelibs4 and 5.0x.
By the time or if they fix this it will be 2017. 

Although this enhancement would have a low priority .  Please fix this so that it uses magic.
Comment 34 Roman Bysh 2015-05-15 07:00:02 UTC
Follow Up
Correction. Please have Dolphin use QMimeDatabase correctly. 
It was truly broken with v1.3x. I was able to convince the person maintaining the "shared-mime-info" package to assign a patch as a workaround. 

It is better than the results we had with the "shared-mime-info" v1.3.4 build Thu 25 Sep 2014 . 
The previous patch assigned to v1.3 broke the "shared-mime-info" update package's mime associations during the creation of v1.3. 
It affected every distro using v1.3x.
Comment 35 Roman Bysh 2015-05-15 07:01:22 UTC
The bug did NOT exist in GNOME.
Comment 36 Florian Hubold 2015-05-15 09:27:07 UTC
(In reply to David Faure from comment #32)
> "Dolphin MUST use magic to differentiate mime-types as it is the proper way."
>   is very wrong.
> See the shared-mime-info spec: the recommended checking order is to trust
> extensions when the extension is known and non-ambiguous. This allows users
> to have control.
> Magic is only used for unknown extensions as it's not reliable enough to be
> 100% correct.
> 
> QMimeDatabase is correct.

So does that imply that the upstream update of shared-mime-info is broken? See https://bugs.freedesktop.org/show_bug.cgi?id=80877#c14 for the upstream comment and the link to the commit: http://cgit.freedesktop.org/xdg/shared-mime-info/commit/?id=824cff3da0f17812715795f0e64a47f7331a338b

I had to revert that and use instead the previous workaround from Roman: https://bugs.freedesktop.org/show_bug.cgi?id=80877#c10 as otherwise the .iso-file recognition is broken in dolphin and other KDE tools like kmimetypefinder with latest shared-mime-info.

Upstream says the problem is downstream, and downstream says it's an upstream issue. I can only tell that since the upstream change to improve recognition for WII and GameCube images with http://cgit.freedesktop.org/xdg/shared-mime-info/commit/?id=4b0bc62b3e50f25d0ef42950e0b715274637c548 the .iso-image recognition was partly broken. KDE showed half of my linux images as textfiles, same for others.

Who should fix what now?
Comment 37 Rex Dieter 2015-05-15 10:58:32 UTC
Re: comment #36

you had to revert the upstream commit that used weight=80 (that didn't work?) to use a workaround that used weight=60 ?  that seems very odd.
Comment 38 Florian Hubold 2015-05-15 11:14:37 UTC
(In reply to Rex Dieter from comment #37)
> Re: comment #36
> 
> you had to revert the upstream commit that used weight=80 (that didn't
> work?) to use a workaround that used weight=60 ?  that seems very odd.

Odd or not, at least it's now working as intended, and as it did before. Please see the diff against shared-mime-info 1.4 which I'm using instead of the upstream fix:
http://svnweb.mageia.org/packages/cauldron/shared-mime-info/current/SOURCES/shared-mime-info-1.4-mga-iso-images-recognition-fd.o80877.patch?view=markup

I see fedora does only have 1.4 without the "faulty" commit on top, could you try to reproduce with some directory with a variety of different .iso images like you did in comment #15 ?
You should still be affected, see comment #23 ...
Comment 39 Rex Dieter 2015-05-15 11:37:01 UTC
I fail to see what's faulty about the commit, the only (essential) difference I see is upstream used weight=80 and you used weight=60.
Comment 40 Florian Hubold 2015-05-15 11:46:23 UTC
Did you try it actually? Why do you think that quite a lot of people commented on this bug, and are still affected?
Comment 41 Rex Dieter 2015-05-15 12:57:30 UTC
> Why do you think that quite a lot of people commented on this bug, and are still affected?

it's only a guess, but because there has yet to be any formal shared-mime-info release that includes the fix (the fix you referenced was committed after 1.4 release)
Comment 42 Roman Bysh 2015-05-16 03:39:41 UTC
Our distro openSUSE 13.2 provided us with an update for shared-mime-info 1.4 about a week after the patch was submitted by the person maintaining the package to the "shared-mime-info" master. 

Here's a snippet of the 1 line change to the x-cd-image entry:   <glob weight="80" pattern="*.iso"/>

I f you do not see any change to your ISOs, close dolphin and konsole or xterm. Log in as root using the "su -" command without the quotes and type:
update-mime-database /usr/share/mime

That's it!
Comment 43 Roman Bysh 2015-05-16 04:35:22 UTC
The package maintainer of the shared-mime-info commented that dolphin does not use magic for differentiating the different mime-types.
He only tests his patches in GNOME and there were no errors. GNOME's file manager nautilus does not have the same problems that dolphin is experiencing. 

It wasn't until KDE4 users started posting on our openSUSE forum and Bugzilla. Then freedesktop's Bugzilla.

Once I started reading on freedesktop's Bugzilla that other users were also experiencing the same problem with Fedora's KDE4 respin and Arch and others..
I then started experimenting with different values until I came across the idea of increasing the weight. It worked!
I posted my idea on https://bugs.freedesktop.org/show_bug.cgi?id=80877#c10  and the author increased the weight from 60 to 80 and submitted the patch. 

Rather than wasting time pointing fingers. And, more than a year has now passed without any one from KDE trying to isolate the problem. The problem still exists... Why does the problem not exist with GNOME's nautilus but with KDE's dolphin4 and now with Plasma 5's dolphin5?
Comment 44 Frank Reininghaus 2015-05-16 08:02:31 UTC
I have tried to improve my mime type knowledge in the mean time - when I first commented here, I didn't even know what "magic" is ;-) I'll try to summarize here what I did to understand why we show ISO images as plain text files. I'm not an expert though, so some of my conclusions might be wrong.

The code from kdelibs and KDE Frameworks 5/QMimeDatabase (which is used by the current and future Dolphin version) do use magic, i.e., look at the file contents, if the mime type cannot be determined unambiguously from  the extension. You can see that easily if you look at a directory like /usr/bin, where there are lots of files without extension.

The problem that we have here is that there are multiple mime types for the pattern *.iso, namely,

application/x-cd-image
application/x-wii-rom
application/x-gamecube-rom

The latter two were added in http://cgit.freedesktop.org/xdg/shared-mime-info/commit/?id=4b0bc62b3e50f25d0ef42950e0b715274637c548 and have "magic" patterns that can be used to distinguish them by looking at the file contents.

However, application/x-cd-image does not have any such "magic" pattern. It was suggested to add one by a KDE contributor many years ago, but the idea was rejected by Bastien Nocera:

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

Now the interesting question is: what should happen if 3 mime types match the *.iso pattern, and only two of them can be detected by using "magic"? Let's look at the spec:

http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html#idm140625828606432

"...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. [...]"

My conclusions are:

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. 

> He only tests his patches in GNOME and there were no errors. GNOME's file
> manager nautilus does not have the same problems that dolphin is
> experiencing.

From my point of view, this can only mean that Nautilus (or the GNOME library that it uses to detect mime types) violates the shared-mime-info spec. 

> And, more than a year has now passed without any one from KDE trying to isolate the problem.

OK, I did that now (and it was not really rocket science - anyone who is willing to spend an hour reading the spec and the glob/magic info at the shared-mime-info site could have done that). My conclusion is that the bug was correctly reported to shared-mime-info at https://bugs.freedesktop.org/show_bug.cgi?id=80877 and was handled improperly there.

> The problem
> still exists... Why does the problem not exist with GNOME's nautilus but
> with KDE's dolphin4 and now with Plasma 5's dolphin5?

See above - from my point of view, the bug is in shared-mime-info and Nautilus/GNOME.

I'm not a mime type expert though, as I said earlier, so feel free to correct me if any part of my analysis is wrong.
Comment 45 Frank Reininghaus 2015-05-21 21:00:20 UTC
*** Bug 348003 has been marked as a duplicate of this bug. ***
Comment 46 Nick Stefanov 2015-07-24 20:52:33 UTC
Same problem here on Arch and KDE 4. This workoround doesn't work for me:

https://forum.kde.org/viewtopic.php?f=66&t=122445#p317733

"kmimetypefinder shows .iso as text:

kmimetypefinder /home/mozo/Downloads/Custom\ Live\ CD\ Mint\ 17.1.iso 
text/plain
(accuracy 5)"

But file --mime-type shows it as .iso:

"file --mime-type /home/mozo/Downloads/Custom\ Live\ CD\ Mint\ 17.1.iso 
/home/mozo/Downloads/Custom Live CD Mint 17.1.iso: application/x-iso9660-image"

When I run Nemo, Nautilus or Thunar in Live mode, all the .isos are shown correctly. Only KDE and Dolphin show some of them as text files and I think that the problem is with hybrid .isos. It is very, very annoying...
Comment 47 Roman Bysh 2015-07-25 01:58:09 UTC
Guys,

We have resolved this having updated shared-mime-info to 1.4x and higher.
This has been resolved as of February 2015.  See: https://bugs.freedesktop.org/show_bug.cgi?id=80877#c10

Checklist
1. Search and check your user ./local/share/mime/ directory and delete it 
2. Next open konsole and type: "su -c" (without quotes)
3. Type:  update-mime-database /usr/share/mime and press the [enter] key
4. Close konsole and restart Dolphin

And/or create a new profile under a different user name. Check the ISO again and you should see the correct result.
We are using openSUSE 13. 2.
Comment 48 Nick Stefanov 2015-07-25 09:37:13 UTC
Yes, this works but deletes all custom settings to files and set them to default. What I made is to remove wii and game cube associacions and all is good now.
Comment 49 Roman Bysh 2015-07-25 19:00:23 UTC
Another option is to rename mime to mime.bak. Copy back the custom ones that you've created. That's what I did.
Comment 50 tguen 2015-11-02 08:02:38 UTC
The 'fix' didn't work for me.

Arch Linux 
extra/shared-mime-info 1.4-1
Comment 51 Roman Bysh 2015-11-02 20:02:26 UTC
(In reply to rasq37 from comment #50)
> The 'fix' didn't work for me.
> 
> Arch Linux 
> extra/shared-mime-info 1.4-1

@rasq37
Checklist 
1. If you have custom associations back up the mime folder
2. Search and check your user ./local/share/mime/ directory and delete it 
3. Next open konsole and type: "su -c" (without quotes) 
4. Type: update-mime-database /usr/share/mime and press the [enter] key 
5. Close konsole and restart Dolphin and/or create a new profile under a different user name

Check the ISO again and you should see the correct result. We are using openSUSE 13. 2.

Arch FYI
See: https://wiki.archlinux.org/index.php/Default_applications
Comment 52 tguen 2015-11-02 22:44:08 UTC
Well, I fixed it...

I don't know what you mean by "./local/share/mime/". Did you mean "~/.local/share/mime/"? I don't have that.

 The only mime folder I could find was "/usr/share/mime". When I first ran the command you gave it didn't seem to do anything. I removed the mime folder and it complained about mime/packages not existing. I restored just that folder and ran the command again and ended up right back where I started. That's when I posted my previous comment.

Now I just deleted the whole /usr/share/mime folder and now everything seems to work properly...
Comment 53 Roman Bysh 2015-11-02 23:08:59 UTC
I have it locally because I created new associations.
FYI
You don't have to delete the entire folder just /usr/share/mime/packages/freedesktop.org.xml
The shared-mime-info program will create a fresh copy of the freedesktop.org.xml file.

Running  as root "update-mime-database /usr/share/mime" creates a fresh copy.

It's good to hear that you resolved your problem ;-)
Comment 54 tguen 2015-11-02 23:35:55 UTC
Well, removing that folder fixed Dolphin listing the types wrong but I just discovered that it also broke all of my file associations. I restored the folder and I'm back where I started. 

I also discovered that update-mime-database isn't actually doing anything. I didn't notice before that it was complaining:

Unknown media type in type 'all/all'
Unknown media type in type 'all/allfiles'

Any idea how to fix this?
Comment 55 tguen 2015-11-02 23:48:46 UTC
It turns out that the command is working despite the complaining. Unfortunately it still isn't fixing the problem. I tried manually deleting the *.iso lines from the wii/gamecube .xml files and running the command again. That didn't help. 

I opened System Settings > Applications > File Associations and found that the *.iso associations for wii/gamecube were still there. Does System Settings not use these .xml files? I deleted the associations there as well and once again it didn't fix the problem.
Comment 56 Roman Bysh 2015-11-03 00:18:51 UTC
Have you looked for a newer package? Arch should have a newer package as this has been resolved for some time.

Here's how i fixed this problem manually.

First backup any file you are editing no matter how/which editor you are using.

cp -v /usr/share/mime/packages/freedesktop.org.xml /tmp

Now you can edit that file. I used the command based editor ed. (as root)

Type "su -" (without the quotes)

Next copy and paste the line below and press the [enter key]:
printf '%s\n' '7951s/^/<!-- /' w .  '7972s/$/ -->/' w . | ed -s /usr/share/mime/packages/freedesktop.org.xml

Update the mime database

update-mime-database /usr/share/mime/
FYI
Just in case you did something wrong the backup is in /tmp/freedesktop.org.xml

That's it!
Comment 57 Roman Bysh 2015-11-03 00:24:52 UTC
Follow Up

I ran update-mime-database /usr/share/mime
Unknown media type in type 'all/all'
Unknown media type in type 'all/allfiles'

Seems everyone gets the same message because there is no association for type 'all/all'.
I wouldn't worry about that. The main thing is to fix freedesktop.org.xml.
Comment 58 Roman Bysh 2015-11-03 00:29:34 UTC
FYI
One of the Archlinux wiki users downgraded an arch package for shared-mime-info v1.2 and it fixed the problem.
Comment 59 tguen 2015-11-03 01:23:04 UTC
Again, your solution didn't work for me. I did finally figure out how to fix it though. I opened freedesktop.org.xml and searched for the wii / gamecube sections and deleted the *.iso lines, then update-mime-database. I hope this won't break anything like my last 'solution'. :)

I still don't understand why my changes to .xml files weren't shown in System Settings but that may be a separate problem.

I appreciate the help. I never would have figured this out on my own.
Comment 60 Florian Hubold 2015-11-03 21:32:22 UTC
@Roman: The newer upstream version of shared-mime-infos is still broken regarding e.g. dolphin. Please check https://bugs.freedesktop.org/show_bug.cgi?id=80877#c25 or here comment 44.
Comment 61 Roman Bysh 2015-11-03 21:55:07 UTC
Thanks Florian.
For now, I would recommend commenting out the two entries referring to wii and gamecube.
It's a quick hack until they resolve this issue.
Comment 62 Nate Graham 2018-03-29 21:11:34 UTC
*** Bug 387068 has been marked as a duplicate of this bug. ***
Comment 64 Nate Graham 2018-10-25 04:39:19 UTC
*** Bug 400275 has been marked as a duplicate of this bug. ***