Hi again, Maxim Cournoyer writes: > Hello, > > Maxim Cournoyer writes: > >> After asking in the #gnome channel on freenode, the problem is likely >> caused by GNOME Shell using inotify to watch the $XDG_DATA_DIRS >> referenced $HOME/.guix-profile/share/applications directory. The >> problem is that the inode of such directory will never change, as it >> points to the current profile under /gnu/store: >> >> $ ls -id $HOME/.guix-profile/share/applications >> 72653730 /home/maxim/.guix-profile/share/applications/ >> maxim@hurd ~/src/guix$ realpath $HOME/.guix-profile/share/applications >> /gnu/store/ph6a7fy735w5nycmf3za77m6v3g0r7xb-profile/share/applications >> maxim@hurd ~/src/guix$ ls -id /gnu/store/ph6a7fy735w5nycmf3za77m6v3g0r7xb-profile/share/applications >> 72653730 /gnu/store/ph6a7fy735w5nycmf3za77m6v3g0r7xb-profile/share/applications/ >> >> Any applications making use of inotify to discover changes (to plugins, >> for example) is at risk of having the same problem in Guix. >> >> I don't currently have an idea of how we can fix this. > > Watching of the directory is done via Glib's GAppInfoMonitor > (gpio/gdesktopappinfo.c). A suggested idea from #gnome-shell would be > to patch its desktop_file_dir_init() procedure with Guix-specifics; I > don't know *how* yet. The folks in #gtk may provide some clues. > > Maxim I've analyzed the situation a bit; I'll explain the big lines of what I think might be a solution. The idea would be to patch desktop_file_dir_init() as mentioned earlier with a procedure similar to desktop_file_dir_get_alternative_dir in that same gdesktopappinfo.c file. This new procedure would search for a parent symlink of the dir argument (dir being one of the entries constructed via XDG_DATA_DIRS, such as $HOME/.guix-profile/share/applications.). The algorithm for this new procedure would be like: 1. Check if a parent of DIR is a symlink. When there are none, return NULL. 2. Resolve the symlink parent until the last symlink, e.g. for symlink1 -> symlink2 -> directory, it saves symlink2. 3. Return the parent directory of the symlink resulting from 2 (i.e. dirname symlink2). In most cases (guix environment, build environment, extra user profiles), the entries in XDG_DATA_DIRS are not symlinks but directly store entries so there's nothing we can do about it. The case of interest here is the default user profile or $HOME/.guix-profile, which gets added to XDG_DATA_DIRS via /etc/profile (on Guix System). Because of the indirect links to the store, and the mutable /var/guix/profiles/per-user/$USER directory used to store the profile links, it is possible to have inotify work correctly. The algorithm described above would resolve $HOME/.guix-profile into /var/guix/profiles/per-user/$USER, and /run/current-system into /run. While adding a watch to /run is not optimal, it's not dramatic either given the watch is not recursive and only watch for specific actions: #define IP_INOTIFY_DIR_MASK (IN_MODIFY|IN_ATTRIB|IN_MOVED_FROM|IN_MOVED_TO|IN_DELETE|IN_CREATE|IN_DELETE_SELF|IN_UNMOUNT|IN_MOVE_SELF|IN_CLOSE_WRITE) (from gio/inotify/inotify-path.c) Thoughts? Thanks, Maxim