GNOME Bugzilla – Bug 744030
Add a method to force gio to notice newly installed desktop files
Last modified: 2018-05-24 17:25:15 UTC
Let's say you have this use case: - create a .desktop file in a xdg directory (like ~/.local/share/applications) - immediatly after, try to load it through g_desktop_app_info_new() (as, you can gsettings set a new launcher key). -> As discussed with desrt, we didn't get the inotify (1s timeout) noticing the new file and couldn't then load the desktop file. Either having a way to know "we got inotify from this file" or a way to "please rescan dirs" would fix this use case.
This bug is annoying. Adding an explicit "reload all the things now" API would certainly work, but it's evil for two reasons: 1) it will often result in wasted effort 2) it's ugly Even once we fix inotify in order not to have baked-in delays there is still a theoretical race here: if the system is loaded, then we may see the "use this desktop file" message before we had a chance to handle the inotify. It's pretty unlikely, but it's still a race. What could be interesting is a mechanism to ask a file monitor if it might be dirty. This would be an out of band mechanism to ask, on the spot, "is there any chance at all that anything is pending wrt. file monitoring?" It would almost always be false. In the event, however, that we are in this race, we would either notice that inotify is in its throttle state or that the inotify fd is ready for read. Other backends (that do not have a notification mechanism) could implement it by doing a stat() and comparing it to the 'last updated' timestamp that they hold internally. One reason that I don't like this is because it means that we will be doing syscalls for each desktop file directory. It's particularly annoying in the inotify case because querying each file monitor will result in a poll() on the same fd (ie: we'll do the same syscall a bunch of times in a row). Interesting problem...
There is also an annoying interaction with GAppInfoMonitor here -- if we just invalidate everything then we risk losing real change events that we should have reported via the monitor. Do we fire the monitor as well in response to someone calling the invalidate API? Yuck....
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/989.