Re: Cleaning of $XDG_CACHE_HOME and $XDG_CACHE_HOME/thumbnails

Benjamin Berg <[email protected]>
Newsgroups gmane.linux.xdg.devel
Message-ID <[email protected]>
Hi,

On Wed, 2020-02-26 at 15:14 +0100, Bastien Nocera wrote:
> Flatpak'ed applications also use a different cache directory, like:
> $ export | grep CACHE
> declare -x XDG_CACHE_HOME="/home/hadess/.var/app/<app-id>/cache"
> 
> I'd say that it might better left well alone, and have something like
> Baobab better signal what each directory is/which application it
> belongs to, to clean it up.

This specification change would only affect the $XDG_CACHE_HOME as set
at login time by pam_systemd (i.e. ~/.cache).

So in principle, Flatpak'ed applications are not affected at all.
However, the logical extension of this proposal would be that
appropriate configurations are shipped inside each Flatpak. Then we
also have a cleanup mechanism there that does not depend on the
application to be run regularly.

I had not thought about that yet. I could imagine Flatpak collecting
the information and doing the simple re-write and dropping it into
~/.config/tmpfiles.d or $XDG_RUNTIME_DIR/tmpfiles.d at login time. And
Flatpak itself could again ship a default to clean .var/app/*/cache by 
default.

Benjamin

> > > <snip>
> > > > Is it reasonable to standardise on the systemd tmpfiles.d
> > > > format?
> > > > Is it OK to clean $XDG_CACHE_HOME after a fixed time period by
> > > > default?
> > > 
> > > I'm guessing that's a no.
> > > 
> > > As for thumbnails, you'd probably get away with checking whether
> > > atime
> > > is actually set on that mount and cleaning up the ones that
> > > haven't
> > > been used.
> > 
> > Benjamin
> 
>

_______________________________________________
xdg mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/xdg
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEED2NO4vMS33W8E4AFq6ZWhpmFY3AFAl5Wf68ACgkQq6ZWhpmF
Y3AmtA/+LxXN5APub0rve4BQBd9uyRKKqd6C9sdesCfCQw/6E8voHHW6tkjZ/zLJ
mM7poM8qj6cn3i1am7nFV1m9eLLIvw4WnwjPs60Ps5ktg+dFnlLidpfhpYsSgS1Z
vRErwnSdyS+FDTzgaWJ2ITrQwyl5++wyrHQySB44N6wEq2WltgdpyDYAMPnsr3i3
6y5BpVC/4iNXT7G/7qKhx8bMdBdUyMxhEb8LDIKLyqex7m4v6z7vneTNgkyK6air
28zN3qjPxFNzO0qTl3qKyGKlxz250wipYwdlPQ30VcjcfbcYsGxLjeLCIEJ6k8rg
hTYtODuW2N1gcXbTA6BWNb4EY19cUxTT1mPvdZt9dvn9MlZ4jzJ8QQcoB8R5XQ56
GkLAhH8g0wmNvyqKKcliEL1eUyeouDZ/AoWDPf6BuZx59G99rJEKPlcpuwyzJoEJ
PpUxfBrUQYjhhQMTFFI5hTZ5nx1r7a2iNFu4XHl0dmqashTxRtnfVRjih6FuqTit
WG2Q/tdF+2SooaYH20/5dsOnrPeBVvAG1LOUFxAKYi5nmD7QSvhvwnh7r3L/qOVD
Krvq01bPbHWEpZ6avIuhPWzlDXANbFDrYwDhz88s1drnifg9n8qGfW4fzsvzHQ+T
KTeuDfxl9KyJbjQddo2qwCg4h6C/45XWyhmGmykGofqiJA0+eos=
=H0dv
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.