Re: Where to set XDG_CACHE_HOME?

Hello,

using symlinks is not an option here, since the use could use any machine i=
n the network and some of them do not have local storage. I set the environ=
ment for the users only on the machines with the local storage.

Regarding bind mount, I think it is not feasible to maintain fstab for the =
whole list of users on all the machines. This would be a major headache.

Thanks for suggestions.

Marek




Odoslan=C3=A9 pomocou bezpe=C4=8Dn=C3=A9ho emailu Proton Mail.

sobota 28. febru=C3=A1ra 2026, 15:27, Ren=C3=A9 J.V. Bertin <rjvbertin@gmai=
l.com> nap=C3=ADsal/a:

> On Saturday February 28 2026 10:54:53 Marek Gre=C5=A1ko wrote:
>=20
> >Do you have any clue where should be the script run from to be started s=
oon enough I do not have the $HOME/.cache/mesa_shader_cache created?
>=20
> Could you do a "bind mount" of ${CACHEDIR}/.cache onto ${HOME}/.cache ?
>=20
> I have a comparable set-up where home dirs are on a "safe" ZFS dataset (c=
opies=3D2 or a pool with mirrored vdevs) but I don't want the costly safety=
 for cache directories. Rather than giving each user a dedicated dataset fo=
r that, I have a single one with a directory structure that gives each user=
 a .cache directory. The bind mounts are defined in /etc/fstab, and trigger=
ed via /etc/rc.local once I'm certain all datasets have been mounted.
>=20
> You could probably also just make each ${HOME}/.cache a symlink to your l=
ocal target location. I've done that for a long time, and the only advantag=
e of bind mounts is that normalised (aka canonical) paths (as obtained e.g.=
 via `realpath`) will still be of the form ${HOME}/.cache . The advantage o=
f symlinks is that you only set them up once without having to modify syste=
m scripts/tables on each machine where the users might log in. You'd be rel=
ying on users not replacing the symlink ... but if they do it's mostly thei=
r problem, no? ;)
>=20
> In either case, you may run into problems with applications that e.g. dow=
nload something to the cache area, and then "move" it into place with syste=
m calls like rename(2) that don't do cross-mount operations. I've seen both=
 Chromium and Firefox fail to install/update extensions because of this kin=
d of situation they hadn't foreseen (though it was probably not related to =
the cache area).
>