Re: Cleaning of $XDG_CACHE_HOME and $XDG_CACHE_HOME/thumbnails

On Wed, 2020-02-26 at 14:30 +0100, Benjamin Berg wrote:
> On Wed, 2020-02-26 at 14:22 +0100, Bastien Nocera wrote:
> > On Wed, 2020-02-26 at 13:45 +0100, Benjamin Berg wrote:
> > > Now, systemd-tempfiles can already clean up everything except for
> > > the
> > > trash. And considering that $XDG_CACHE_HOME is non-essential by
> > > definition, I think it might be sane to use systemd-tempfiles not
> > > only
> > > to clean the thumbnails but the entirety of $XDG_CACHE_HOME in
> > > the
> > > future.
> > 
> > It's not "non-essential", it's a cache, which can be regenerated,
> > but
> > it might be utterly costly to do so. Eg. there are 10 gigs of
> > "cached"
> > evolution mails in my ~/.cache, 5 gigs of jhbuild builddirs.
> > 
> > Nuking it is a last ditch scenario. You'd avoid backing it up on
> > space
> > constrained storage, but you'd want to avoid having to regenerate
> > that
> > cache in most cases.
> 
> I am *not* proposing to nuke these directories. I am proposing to
> nuke
> them by default, and ask applications like evolution, jhbuild and
> others to ship their own configuration.
> 
> This matches the behaviour of /tmp and /var/tmp on systemd managed
> systems. In the simplest case, all evolution needs to do is ship a
> one
> line file with:
> 
> x     %C/evolution
> 
> This file can even be installed to the users $XDG_CONFIG_DIR for
> applications that might not be able to do it globally.

That sounds like a recipe for disaster, if you have an older version of
evolution and a newer version of the host OS.

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.

> > <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