Bug 284519 - kmenuedit silently fails to modify the menu when ~/.local directory file permissions are wrong
Summary: kmenuedit silently fails to modify the menu when ~/.local directory file perm...
Status: CONFIRMED
Alias: None
Product: kmenuedit
Classification: Applications
Component: general (show other bugs)
Version: 0.8
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-20 07:43 UTC by peter.maloney
Modified: 2021-03-11 01:23 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description peter.maloney 2011-10-20 07:43:12 UTC
Version:           unspecified
OS:                Linux

$ kmenuedit --version
Qt: 4.7.2
KDE Development Platform: 4.6.5 (4.6.5)
KDE Menu Editor: 0.8

When using kmenuedit to add a submenu or item, then clicking "save", it looks like it worked, and everything saved (no error message). However, my file permissions were wrong (for unknown reasons), so it did not save properly. I am reporting this, because there should be feedback, saying that the changes failed.

If I run kmenuedit from command line with the broken file permissions, and create a submenu, and an item in it, here is the output:
===============================
QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: No such file or directory
QFileSystemWatcher: failed to add paths: /home/peter/.config/ibus/bus
kmenuedit(10553)/kdecore (services) KServicePrivate::init: The desktop entry file  "/home/peter/.local/share/applications/a.desktop"  has Type= "Application"  but no Exec line 

QFile::remove: Empty or null file name
QFile::remove: Empty or null file name
===============================

If I do the same after changing permissions (so things work), here is the output:
===============================
QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: No such file or directory
QFileSystemWatcher: failed to add paths: /home/peter/.config/ibus/bus
kmenuedit(11533)/kdecore (services) KServicePrivate::init: The desktop entry file  "/home/peter/.local/share/applications/test2.desktop"  has Type= "Application"  but no Exec line 
===============================

Here is what I did to fix it:

sudo chown peter:peter -R ~/.local

I don't know why the permissions were wrong (we can blame Ubuntu/kubuntu), but the owner of some directories was root:root. (In particular, the one I noticed first was ~/.local/share/applications)

Reproducible: Always

Steps to Reproduce:
sudo chown root:root -R ~/.local
kmenuedit
(add a submenu and an item)
(hit save)
(close)
kmenuedit


Actual Results:  
You sometimes have your submenu, but not the item. 
Sometimes you have a submenu with the wrong name, such as ~2 added on the end and no item.
Sometimes you have nothing that you added.

Expected Results:  
If permissions are wrong, the result should be error messages on screen in the gui, that clearly state that something important has failed having to do with having write access to files or directories. 

Example:
   Failed to write changes to disk. Error was: /home/peter/.local/... : Permission denied
Comment 1 GB 2011-10-20 14:21:32 UTC
There may be a larger issue here. New items are dropped here, too, i.e. apparently saved but never appearing in the menu.

However, all the files and directories in my .local folder are owned by my user, and the .desktop file that I saved *is* actually created in the .local/share/applications/ folder. Still, it does not show up in the Menu.
Comment 2 GB 2011-11-02 16:05:42 UTC
The workaround given in bug #115396 works. Tick the 'Only show in KDE' box and the new item is saved and shown correctly.
Comment 3 Christoph Feck 2011-11-11 01:04:26 UTC
Which KDE version are you using?
Comment 4 GB 2011-11-11 08:33:56 UTC
(In reply to comment #3)
> Which KDE version are you using?

4.7.3. I first noticed the bug in 4.7.2.
Comment 5 Justin Zobel 2021-03-11 01:23:53 UTC
Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.