Bug 506032 - Cannot rename desktop links (shortcuts)
Summary: Cannot rename desktop links (shortcuts)
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Desktop icons & Folder View widget (other bugs)
Version First Reported In: 6.4.0
Platform: Arch Linux Linux
: NOR minor
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks: 446031
  Show dependency treegraph
 
Reported: 2025-06-23 09:42 UTC by zaliojicitrina
Modified: 2025-07-31 17:19 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In: 6.4.4
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description zaliojicitrina 2025-06-23 09:42:17 UTC
SUMMARY
I am unable to rename the displayed name for .desktop files. Right clicking on them and selecting rename on the desktop or dolphin renames the .desktop file itself and not the displayed name. Trying to rename through the properties window's application tab's name field throws an error "Could not save properties due to insufficient write access to: 'home/name/Desktop/shortcut.desktop'". It does however work, if you use a text editor (such as Kate or Nano) to edit the "name" field.

STEPS TO REPRODUCE
1. Try to rename a .desktop file either through the desktop itself, with dolphin or the file's properties window.

OBSERVED RESULT
The displayed name on the desktop stays the same. If edited through the desktop or dolphin the .desktop file name itself is changed. Trying to rename through the properties window throws an error.

EXPECTED RESULT
The displayed name is changed, keeping the original name of the .desktop file intact.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 6.15.3
KDE Plasma Version: 6.4.0
KDE Frameworks Version: 6.15.0
Qt Version: 6.9.1

ADDITIONAL INFORMATION
Checking the permissions for the .desktop files, each file's owner is root and not my user account, perhaps that has something to do with it? Though trying to change the owner with chown did not fix the problem.
Comment 1 Nate Graham 2025-06-24 17:57:08 UTC
Can you be specific about how you created the shortcuts that are on the desktop?
Comment 2 Nate Graham 2025-06-24 17:57:46 UTC
Was it by dragging apps installed from Flathub (user install, not system install) from Kickoff/kicker/etc to the desktop and then choosing "Link"?
Comment 3 zaliojicitrina 2025-06-24 18:01:48 UTC
I think one of them was from flathub (currently can't check), but most of the apps were installed using pacman (arch system). The shortcuts were created by right clicking the apps and selecting "Add to desktop" in the start menu (kickoff).
Comment 4 zaliojicitrina 2025-06-24 18:02:55 UTC
Will add, 2 of them were installed from the AUR. Seems like their origin is not related
Comment 5 TraceyC 2025-06-26 00:50:58 UTC
I tested this on git-master and cannot reproduce

Testing steps:
1. Right click an app from the app menu and choose Add to Desktop (tested with native Kate and Obsidian flatpak)
2. Right click the shortcut, choose rename

The shortcut on the desktop has the new name
The properties show the new name in the name field, and the .destop filename remains as it had been (e.g. /home/tracey/.local/share/applications/org.kde.kate.desktop)

On KDE Neon User, and Neon Testing:
The properties window shows the new name in the text field, and the correct name for the .desktop file but the shortcut on the desktop does not update, due to a permissions issue. That's a packaging issue on Neon, but it verifies the .desktop file does not change name.
Comment 6 zaliojicitrina 2025-06-26 09:28:30 UTC
I can try downloading plasma-deskqtop-git from the AUR (I believe that's the right package) then to see if the bug persists.  Question: is mixing KDE enviroment packages a bad idea - I would esentially be only replacing the desktop while keeping all other plasma apps from the main (extra) repositories.
Comment 7 TraceyC 2025-06-26 17:25:03 UTC
(In reply to zaliojicitrina from comment #6)
> I can try downloading plasma-deskqtop-git from the AUR (I believe that's the
> right package) then to see if the bug persists.  Question: is mixing KDE
> enviroment packages a bad idea - I would esentially be only replacing the
> desktop while keeping all other plasma apps from the main (extra)
> repositories.

I would advise against mising environment packages. This can lead to an inconsistent system state, and would make things harder to test. I was testing on git-master to provide data, it isn't a workaround.

Hopefully others will be able to reproduce this.
Comment 8 Akseli Lahtinen 2025-07-01 11:57:07 UTC
I can repro this:

- If linked target is in user writable folder, the symlink can be renamed
- If linked target is in flatpak or some other non-user writable folder, it can't be renamed

One should be able to rename symlinks, since it shouldnt rename the target. Will investigate why it fails.

Operating System: Fedora Linux 42
KDE Plasma Version: 6.4.80
KDE Frameworks Version: 6.16.0
Qt Version: 6.9.1
Kernel Version: 6.15.4-200.fc42.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 3600 6-Core Processor
Memory: 16 GiB of RAM (15.5 GiB usable)
Graphics Processor: AMD Radeon RX 6600
Comment 9 Akseli Lahtinen 2025-07-01 12:05:19 UTC
I think i get why:

When renaming the symlink, it does actually rename it. However it cant rename the "friendly name" that is usesdon the desktop for name display, since that is under root ownership.

What we could do instead is just show the symlink name if its symlink, but when creating new symlink for desktop file, use tve friendly name as its initial name.
Comment 10 Bug Janitor Service 2025-07-01 13:39:20 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5648
Comment 11 Akseli Lahtinen 2025-07-31 10:21:33 UTC
Git commit 8b2f22c28d24b3a70765b71d83f3cde77320ab7d by Akseli Lahtinen.
Committed on 31/07/2025 at 10:21.
Pushed by akselmo into branch 'master'.

DesktopProtocol: If symlink target desktop file is unwritable, create new one to ApplicationsLocation

If user creates a symlink from applications launcher to desktop, and that symlink points to a
flatpak related desktop file, it is unwritable. Therefore renaming it wont work, since
rename process wants to rename the "friendly name" of the desktop file.

In these cases, we copy the symlink target desktop file data, create new one
to the `QStandardPaths::ApplicationsLocation`, delete the old symlink and replace it 
with new one which points to the one we just created. Since this is writable,
it will rename correctly.

M  +14   -1    kioworkers/desktop/kio_desktop.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/8b2f22c28d24b3a70765b71d83f3cde77320ab7d
Comment 12 Akseli Lahtinen 2025-07-31 10:46:11 UTC
Git commit 8df7d9aeffb82fe128113855c66605ef6a8457dc by Akseli Lahtinen.
Committed on 31/07/2025 at 10:21.
Pushed by akselmo into branch 'Plasma/6.4'.

DesktopProtocol: If symlink target desktop file is unwritable, create new one to ApplicationsLocation

If user creates a symlink from applications launcher to desktop, and that symlink points to a
flatpak related desktop file, it is unwritable. Therefore renaming it wont work, since
rename process wants to rename the "friendly name" of the desktop file.

In these cases, we copy the symlink target desktop file data, create new one
to the `QStandardPaths::ApplicationsLocation`, delete the old symlink and replace it 
with new one which points to the one we just created. Since this is writable,
it will rename correctly.


(cherry picked from commit 8b2f22c28d24b3a70765b71d83f3cde77320ab7d)

955ad41c DesktopProtocol: If symlink target desktop file is unwritable, create new one...
a4f1fcbc If newPath exists, only link it

Co-authored-by: Akseli Lahtinen <akselmo@akselmo.dev>

M  +14   -1    kioworkers/desktop/kio_desktop.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/8df7d9aeffb82fe128113855c66605ef6a8457dc