Bug 451003

Summary:	Desktop files should be copied instead of symlinked
Product:	[Frameworks and Libraries] frameworks-kio	Reporter:	Trent M <twilightinzero>
Component:	Properties dialog	Assignee:	KIO Bugs <kio-bugs-null>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	a.samirh78, ashark, kdelibs-bugs, meven.car, mikel5764, nate, noahadvs
Priority:	NOR
Version:	5.96.0
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Trent M 2022-03-01 14:11:49 UTC

SUMMARY
If you want to make an edit to a .desktop file for an application installed system-wide, like via Flatpak, and attempt to do so via the right-click menu of an application in Kickoff, a symlink to the .desktop file will be created in `$XDG_DATA_HOME/applications` , and the file will be uneditable.

STEPS TO REPRODUCE
1. Right click on a Flatpak application in Kickoff
2. Click "Edit Application..."
3. Attempt to make edits to the application

OBSERVED RESULT
All attempted edits fail, because the file made in `$XDG_DATA_HOME/applications` is a **symlink** to a file that is not user-writable.

EXPECTED RESULT
A **copy** of the file is made in `$XDG_DATA_HOME/applications`, and is thus editable.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: KDE Neon 5.24
KDE Plasma Version: 5.24.2
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.3

ADDITIONAL INFORMATION
The case that made me notice this was attempting to edit Spotify's launcher after installing it via Discover; its default install method is system-wide. I wanted to add `--force-device-scale-factor 1.25` to the command line args but couldn't until I changed the symlink in `$XDG_DATA_HOME/applications` to an actual copy.

Even if this is meant to somehow detect when the original .desktop files would be user-editable, like for the user Flatpak installation, I believe it is better to create a copy of the .desktop file so that changes are not lost on updates. I don't want to be forced to redo edits to get my desired scaling back every time Spotify updates.

Comment 1 Nate Graham 2022-07-05 16:56:12 UTC

Is this still reproducible with Frameworks 5.95? It's working for me, and I recall some changes that might have fixed it. Can you check? Thanks!

Comment 2 Trent M 2022-07-06 19:47:16 UTC

(In reply to Nate Graham from comment #1)
> Is this still reproducible with Frameworks 5.95? It's working for me, and I
> recall some changes that might have fixed it. Can you check? Thanks!

I just tried it, and it still creates a symlink to the desktop file in a non-user-writeable system Flatpak installation. Even if there's some (currently failing) logic to check if a .desktop file's location is writeable, like for example if it points to the per-user Flatpak installation instead of a system one, it should still be copying the desktop file instead, because if it's symlinked, an update will overwrite the user's changes.

Comment 3 Trent M 2022-08-15 19:47:08 UTC

I think I've made a breakthrough here. This is *mostly* a Flatpak-specific issue, and here is why. I just tested out trying to edit an application I've installed in a custom system-wide Flatpak installation, located at `/xusr/flatpak`. I try to change its name, it fails, then I go look at the file it made. It is a symlink instead of a copy, but here's where it gets interesting.

Flatpak wants you to put the `exports/share` directory in XDG_DATA_DIRS so that the DE can read the applications in `exports/share/applications`, and it does that automatically nowadays, but here is the rub: everything in that directory is already a symlink! I checked the points-to field of the resulting symlink that was made in `$XDG_DATA_HOME/applications`. It's not pointing to `/xusr/flatpak/exports/share/applications/com.github.unrud.VideoDownloader.desktop`. It's pointing at `/xusr/flatpak/app/com.github.unrud.VideoDownloader/current/active/export/share/applications/com.github.unrud.VideoDownloader.desktop`, which is the *target* of the first file.

I think the reason I had not realized this was the case was because if you use `cp` to copy that file, it dereferences all the symlinks on the way to the actual file without you having to specify the `-L` argument. I am not sure why it does that. But Plasma really was already copying the file... it was just copying the symlink as-is. What it needs to do is dereference every symlink it finds on the way.

Comment 4 Andrew Shark 2023-10-25 13:05:02 UTC


*** This bug has been marked as a duplicate of bug 450727 ***