Bug 356237

Summary:	Unable to change icon associated with mimetype if ~/.local/share/mime/packages does not already exist.
Product:	[Applications] systemsettings	Reporter:	Paul <pip.kde>
Component:	kcm_filetypes	Assignee:	David Faure <faure>
Status:	RESOLVED FIXED
Severity:	normal	CC:	cfeck, luisfe, overdiversifies_pryingly, wbauer1
Priority:	NOR
Version:	5.4.3
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:	http://commits.kde.org/kde-cli-tools/c2aa2a46d51793d26dc6e93e60b5933cb1193e56	Version Fixed In:	5.6.5
Sentry Crash Report:

Description Paul 2015-12-03 11:26:06 UTC

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

Comment 1 Wolfgang Bauer 2016-05-30 13:51:34 UTC

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

Comment 2 Wolfgang Bauer 2016-05-30 14:03:54 UTC

(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...

Comment 3 David Faure 2016-06-03 19:04:30 UTC

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.

Comment 4 Wolfgang Bauer 2016-06-04 23:15:59 UTC

@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...

Comment 5 Christoph Feck 2016-06-20 03:45:23 UTC

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

Comment 6 Christoph Feck 2016-06-20 03:50:14 UTC

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?

Comment 7 overdiversifies_pryingly 2016-06-20 10:16:31 UTC

This does indeed seem to be fixed on 5.6.5, thanks.

Comment 8 Wolfgang Bauer 2016-06-20 15:12:06 UTC

(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 .

Comment 9 Wolfgang Bauer 2016-07-23 19:06:32 UTC

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