Bug 489679 - Editing a .desktop file in .local/share/applications creates a copy
Summary: Editing a .desktop file in .local/share/applications creates a copy
Status: RESOLVED WORKSFORME
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: Properties dialog (show other bugs)
Version: 6.3.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KIO Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-07-03 14:33 UTC by Vitaliy
Modified: 2024-07-06 12:33 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vitaliy 2024-07-03 14:33:00 UTC
SUMMARY
When I edit a .desktop file properties, e.g. to change the icon, instead of changing the original file it creates a new one, stripping the first character of the file name (so e.g. kate.desktop becomes ate.desktop).

STEPS TO REPRODUCE
1. In Dolphin, go to ~/.local/share/applications/
2. Open properties of any .desktop file there
3. Change anything, e.g. its icon, display name, etc.
4. Click OK

OBSERVED RESULT
A new .desktop file appears, with the first character stripped from the name (e.g. if you edited kate.desktop, the new file is named ate.desktop).

EXPECTED RESULT
The original file is edited/replaced.

SOFTWARE/OS VERSIONS
Operating System: Void 
KDE Plasma Version: 6.1.1
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.2
Kernel Version: 6.6.35_1 (64-bit)
Graphics Platform: X11
Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor
Memory: 31.3 ГиБ of RAM
Graphics Processor: AMD Radeon RX 560 Series
Manufacturer: ASUS

ADDITIONAL INFORMATION
If you edit file permissions instead of other properties, it tries to change them on the wrongly-named file, fails with an error message, and then creates that file anyway.

The same happen if you edit an application entry from the launch menu IF the corresponding .desktop file is in .local/share/applications/ already; otherwise the new file is created there with the correct name.

Editing .desktop files in other locations is NOT affected.

Editing through kmenuedit is not affected but, it doesn’t show the very file I needed to edit, userapp-Firefox-<...>.desktop.
Comment 1 Nate Graham 2024-07-03 21:02:43 UTC
Cannot reproduce the issue with those steps. Can you attach a screen recording that shows it happening?
Comment 2 Vitaliy 2024-07-06 12:05:39 UTC
Neither can I, anymore. I don’t know what that was. That happened just after the upgrade (5->6); I’m almost sure I did reboot but, maybe actually not...
Comment 3 Nate Graham 2024-07-06 12:33:12 UTC
Maybe not. If you see it happen again, let us know!