GNOME Bugzilla – Bug 702991
Doesn't add monitor for .local/share/applications if it doesn't exist
Last modified: 2021-05-25 12:45:48 UTC
Currently when a new user first logs in, ~/.local/share/applications doesn't exist for him. If he creates a .desktop file somehow (e.g. through alacarte) the directory is created and a .desktop file is added, but gnome-shell doesn't notice the new desktop file because libgnome-menu didn't add a monitor: Resolving files in: Resolving files in: Adding <AppDir>/home/test2/.local/share/applications</AppDir> in <DefaultAppDirs/> Adding <AppDir>/usr/local/share/applications</AppDir> in <DefaultAppDirs/> Adding <AppDir>/usr/share/applications</AppDir> in <DefaultAppDirs/> [...] Loading entry directory "/usr/local/share/applications" (legacy <no>) Failed to canonicalize "/usr/local/share/applications": No such file or directory Loading entry directory "/home/test2/.local/share/applications" (legacy <no>) Failed to canonicalize "/home/test2/.local/share/applications": No such file or directory Perhaps if canonicalize fails with ENOENT we can ignore the error. Or we can canonicalize the parent and add the basename (recursively), e.g. Canonicalize /home/test2/.local/share/applications -> ENOENT Canonicalize /home/test2/.local/share/ -> ENOENT Canonicalize /home/test2/.local/ -> OK! Return /home/test2/.local/ + share/applications
Created attachment 247661 [details] [review] Add monitors for non-existent paths A directory may be created later on so add a monitor to notice changes on it if that happens.
That patch works for me: from session.log: Resolving files in: Resolving files in: Adding <AppDir>/home/test2/.local/share/applications</AppDir> in <DefaultAppDirs/> Adding <AppDir>/usr/local/share/applications</AppDir> in <DefaultAppDirs/> Adding <AppDir>/usr/share/applications</AppDir> in <DefaultAppDirs/> [...] Loading desktop entry "/usr/share/applications/glchess.desktop" Loading entry directory "/usr/local/share/applications" (legacy <no>) Failed to canonicalize "/usr/local/share/applications": No such file or directory Looking up cached dir "/usr/local/share/applications" Caching dir "local" Caching dir "share" Caching dir "applications" **** adding monitor for /usr/local/share/applications, 1 Attempting to read entries from applications (full path /usr/local/share/applications) Unable to list directory "/usr/local/share/applications" Loading entry directory "/home/test2/.local/share/applications" (legacy <no>) Failed to canonicalize "/home/test2/.local/share/applications": No such file or directory Looking up cached dir "/home/test2/.local/share/applications" Caching dir "home" Caching dir "test2" Caching dir ".local" Caching dir "share" Caching dir "applications" **** adding monitor for /home/test2/.local/share/applications, 1 Attempting to read entries from applications (full path /home/test2/.local/share/applications) Unable to list directory "/home/test2/.local/share/applications" Loading entry directory "/usr/share/desktop-directories" (legacy <no>) I haven't seen any drawbacks so far, but I can think of at least more wakeups due to bug #522314. I'm also not quite confident of not doing canonicalization at all. Could there be any risk if we don't do it?
We're going to create ~/local/share/applications in g-s-d's housekeeping plugin, see bug #703048. Leaving this open as there are other dirs that are affected by this and so a more general fix is needed.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/gnome-menus/-/issues/ Thank you for your understanding and your help.