Certain Files & Directories Used by GNOME Don't Work

[jacobranson]

Hello! My NixOS config is using impermanence with an impermanent home directory. This is working mostly well, with a few things that I seemingly cannot get to work, all related to GNOME. The following files are correctly persisted, but GNOME seems to overwrite them with normal files instead of the bindmounted ones regardless.

• .config/gnome-initial-setup-done - for removing the "Welcome to GNOME" popup on first boot
• .local/share/recently-used.xbel - for persisting recently used files in Nautilus
• .config/monitors.xml - for persisting monitor configurations in GNOME Display Settings

Additionally, Trash support in Nautilus seems broken when bindmounting the .local/share/Trash directory.

Is anyone else using an impermanent home with GNOME and has gotten these things working? Thanks!

[Jo-Blade]

Same issues here.

• recently-used.xbel and monitors.xml don't work when bind-mount by the module. But in general, mounting single files cause a lot of issues because programs tried to make copies for example so I am not really surprised.
• .local/share/Trash does not work with nautilus at all when using a symbolic link: files does not appear in trash and I can't put new files in trash. When using bind-mount, I can see files inside ~/.local/share/Trash inside the nautilus bin, but I can't add new files in the bin from nautilus. I can't figure why but it is very frustating…
• .config/gnome-initial-setup-done works, but is actually useless because gnome do not use this file to remove Welcome to GNOME popup but a dconf key the good solution is adding this inside home-manager :

    dconf.settings = {

      # Désactiver la popup de bienvenue de Gnome
      "org/gnome/shell" = {
        welcome-dialog-last-shown-version = "999"; # prevent popup until gnome version 999 :)
      };

    };

[maydayv7]

Additionally, Trash support in Nautilus seems broken when bindmounting the .local/share/Trash directory.

The FreeDesktop Specification mentions that the ~/.local/share/Trash directory mustn't be a symbolic link in order to be used as intended. To preserve it's functionality, I've been using this workaround instead of persisting that directory using impermanence

Also note that this is not a GNOME-specific issue

(user.homeConfig --> home-manager.users.$USER)

[MordragT]

@maydayv7 thanks for sharing your workaround. I am wondering is this also working for you when deleting files within bind mounted directories (in Home) ? Because I believe I have read somewhere that nautilus (or more specifically gvfs) will not move files across different filesystems to put them into trash. I would have thought that then nautilus will just create .Trash dirs inside each bindmount root but that does not seem to be the case atleast on my machine. I have tried different file managers and only dolphin does that described behaviour.

[maydayv7]

I am wondering is this also working for you when deleting files within bind mounted directories (in Home) ?

This is not the same issue as above

I would have thought that then nautilus will just create .Trash dirs inside each bindmount root

Yes, it will try creating a .Trash folder in the topmost mount directory, and might fail due to insufficient permissions. Try using gio trash /path/to/file/to/delete and see if it throws an error.

[MordragT]

It seems like glib has a Bug which is why trashing files from within bind mounts is not working. This seems to be the related issue https://gitlab.gnome.org/GNOME/glib/-/issues/1885

[maydayv7]

Oh okay, in my case I mount ZFS datasets to something like /data and trashing works perfectly with any gvfs-based file managers (once permissions are sorted)