openSUSE Tumbleweed (20151128) / KDE Frameworks 5.16.0 / System Settings 5.4.3 Attempting to change the icon associated with a mimetype (System Settings -> Applications -> File Associations) fails to work if the subdirectory "~/.local/share/mime/packages" does not already exist. Within system settings it gives the appearance of having worked, however having closed System Settings the icon is unchanged when viewing a directory listing using Dolphin, and if one again uses System Settings it shows the original icon. This section of ".xsession-errors-:0" gave the clue... m_userSpecifiedIcon has changed. Now set to "text-rdf+xml" Entry "application/rdf+xml" is dirty. Saving. m_userSpecifiedIcon has changed. Now set to "text-rdf+xml" writing "/home/paul/.local/share/mime/packages/application-rdf+xml.xml" Couldn't open "/home/paul/.local/share/mime/packages/application-rdf+xml.xml" for writing "application/rdf+xml" hasDefinitionFile: false Specifically, the "Couldn't open..." - The subdirectory didn't exist. Having manually created ~/.local/share/mime/packages changing the icon worked correctly. I have 3 users on that particular machine, none of whom had a "~/.local/share/mime/*" subdirectory. Interestingly, System Settings was able to create an additional subdirectory, "~/.local/share/mime/application". I tried again with one of the other users, initally just creating "~/.local/share/mime" - which failed, it had to be "~/.local/share/mime/packages". So it seems that System Settings expects that subdirectory to "just be there", and does not create it if missing. Reproducible: Always
Git commit c2aa2a46d51793d26dc6e93e60b5933cb1193e56 by Wolfgang Bauer. Committed on 30/05/2016 at 13:49. Pushed by wbauer into branch 'Plasma/5.6'. Create ~/.local/share/mime/packages/ if it doesn't exist QStandardDirs::writableLocation() doesn't guarantee that the returned directory actually exists. So create it, otherwise saving the changes will fail if it isn't there. FIXED-IN: 5.6.5 REVIEW: 128055 M +5 -1 keditfiletype/mimetypewriter.cpp http://commits.kde.org/kde-cli-tools/c2aa2a46d51793d26dc6e93e60b5933cb1193e56
(In reply to Paul from comment #0) > Interestingly, System Settings was able to create an additional > subdirectory, "~/.local/share/mime/application". This was probably created by "update-mime-database" (which is run by systemsettings5/keditfiletype), I suppose. systemsettings5/keditfiletype doesn't depend on that directory to be existent AFAICT. Btw, "update-mime-database ~/.local/share/mime/" fails as well if ~/.local/share/mime/packages/ doesn't exist (and ~/.local/share/mime/ does) , but that's out of scope for KDE...
Well, the source files for update-mime-database are those under the "packages" subdir. It generates everything else from that. So if there's no packages subdir, u-m-d has nothing to do, no bug there.
@David Faure: Thanks for the explanation, makes sense of course. I didn't mean to imply that it's a bug in u-m-d anyway (I wasn't sure actually), I merely mentioned it because it shows similar behavior...
*** Bug 364511 has been marked as a duplicate of this bug. ***
Hm, I was incorrectly assuming that this commit went to "kio". Am I right that this does not fix dolphin? How about other applications that uses the property dialog?
This does indeed seem to be fixed on 5.6.5, thanks.
(In reply to Christoph Feck from comment #6) > Hm, I was incorrectly assuming that this commit went to "kio". Am I right > that this does not fix dolphin? How about other applications that uses the > property dialog? I just tried, and it does work in the "Properties" dialog (e.g. dolphin) as well. The "Properties" dialog uses KMimeTypeEditor::editMimeType() for that, which in turn just runs keditfiletype5 (where I fixed it), see https://api.kde.org/frameworks/kwidgetsaddons/html/kmimetypeeditor_8cpp_source.html .
*** Bug 356972 has been marked as a duplicate of this bug. ***