Expected behaviour of XDG_USER_DIRS?

Help
,
1

Like many I suspect, i’m a long term Windows user on the desktop, looking to migrate to Linux to avoid Win11.

As a stepping stone I have configured my machine to dual boot Win10 and KDE Neon (6.3). My plan is to put all the day to day user data (in Desktop, Documents, Music etc.) in a separate partition that can (a) be access by either OS; and (b) be retained and re-used if I decide to swap distros

I was considering more heavyweight solutions to shifting all the users default file locations to the new drive, such as bind-mounting the new locations over the existing folders, but then I found out about xdg-user-dirs, which looks perfect for the job

I’ve written a script to create the new directories, and then configure ~/.config/user-dirs.dirs to point all the XDG locations at them.

I tried it on my own account and it seems to “take”, i.e. the KDE Locations tool under System Settings shows the new configuration. However in practice only parts of the system seem to take any notice of the change-

  1. Some file save dialogs (e.g. the Spectacle tool) do default to the new locations
  2. However Dolphin for example is still pointing at the original entries in /home.

Does anyone have any experience of how this is expected to work, and/or how to make the change more seamless?

2

Not everything respects (insert scheme for locating a folder here)

This is the way

You seem well educated and prepared, especially for a newbie. You’re gonna be A-OK

3

You can simply edit the entries in the places panel through their context-menu (right-click).
Those don’t follow automatically settings changes.

4

Yes I understand this. However even on my home PC I have 6 registered users, with 8 “well known” folders each, so I’m looking for something I can set up once from a script run from an admin account, rather than logging in manually 6 times and configuring 48 locations by hand.

5

I fake competence well :wink:, but thank you.

I have 6 user accounts on my home PC, with 8 well-known directories for each to set up. I can’t say having 48 bind mounts stuck on the bottom of fstab strikes me as elegant, but i suppose they are in effect just aliases, so they shouldn’t impact the system too much.

In the past I dealt with a similar need (but this time mounting remote SMB shares) by mounting/unmounting the required items at login and logoff using pam.mount, however that was a bit of a pain to set up and maintain so i’m not sure i want to go down that route again.

6

The files to edit are in ~/.local/share/user-places.xbel and are simple xml files you can edit through scripts, a simple old-path/new-path should be enough.

7

One easy solution is to move those directories to your new partition, then create symlinks (symbolic links) in their original locations.

1 Like
8

Yes, that’s the alternative to using bind mounts. I think both have advantages and disadvantages.

Pluses for bind mounts are-

  1. The existing directories can stay in place, they are simply masked by the bind mount. No need to move them out of the way to create symlinks.
  2. If the new data partition goes away for some reason (maybe a botched edit to fstab, or a hardware failure), the original folders under /home/ are still there, so users can still log in and work normally until the problem is fixed.
  3. More transparent than symlinks to some file operations (find for example)

There are disadvantages too-

  1. So transparent that normal users (or even yourself after a few months?) can’t easily see what’s going on (not many people would look at fstab as a matter of course)
  2. The same data appears in two locations. So transparent that it can confuse some operations, e.g. backups, and potentially cause issues like backing up the same data twice