| Summary: | 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). | ||
|---|---|---|---|
| Product: | [Unmaintained] kdelibs | Reporter: | AndrzejL <bugs.kde.org> |
| Component: | kdecore | Assignee: | kdelibs bugs <kdelibs-bugs> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | minor | CC: | artghio, arthur, bugseforuns, doktor5000, emrecio, faure, felixonmars, frank78ac, hrvoje.senjan, i, idarktemplar, karthik.periagaram, mo78, nate, peng.thinkblue, rb03884, rdieter, s2, simonandric5, tesfabpel, travneff |
| Priority: | NOR | ||
| Version: | 4.13.2 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
it was iso then change to txt
/usr/share/mime/packages/freedesktop.xml patch |
||
|
Description
AndrzejL
2014-07-04 09:22:40 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. 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 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. (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. 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 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 Follow Up Using KDE4 Version 4.14.2 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? 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
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. 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? 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 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.
Status please. 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. (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... 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. (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). 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? Surely, by now the "Status" should be changed from UNCONFIRMED to CONFIRMED. Yes? Follow Up Please look into add a patch to dolphin to use "magic" to differentiate the mime-types. This should resolve the problem. 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) 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) 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 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"/> It has now been resolved. Thanks for the info and for your efforts to get this issue fixed upstream, Florian and Roman! 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. (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. 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. *** Bug 346804 has been marked as a duplicate of this bug. *** "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. (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. 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. The bug did NOT exist in GNOME. (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? 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. (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 ... 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. Did you try it actually? Why do you think that quite a lot of people commented on this bug, and are still affected? > 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)
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! 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? 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. *** Bug 348003 has been marked as a duplicate of this bug. *** 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... 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. 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. Another option is to rename mime to mime.bak. Copy back the custom ones that you've created. That's what I did. The 'fix' didn't work for me. Arch Linux extra/shared-mime-info 1.4-1 (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 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... 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 ;-) 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? 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. 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! 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. FYI One of the Archlinux wiki users downgraded an arch package for shared-mime-info v1.2 and it fixed the problem. 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. @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. 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. *** Bug 387068 has been marked as a duplicate of this bug. *** Upstream issue. See: - https://bugs.freedesktop.org/show_bug.cgi?id=97372 - https://gitlab.freedesktop.org/xdg/shared-mime-info/issues/74 *** Bug 400275 has been marked as a duplicate of this bug. *** |