Cleaning of $XDG_CACHE_HOME and $XDG_CACHE_HOME/thumbnails

[Benjamin Berg]

Hi,

On Thu, 2020-02-27 at 00:12 +0100, Egmont Koblinger wrote:
> Let's take ccache for example. It's a weird example because they don't
> use XDG_CACHE_HOME, but they could :). I might compile a project, play
> with it, get some result out of it, and think that I won't ever need
> to work on it again, thus remove the git checkout tree. Then months
> later something pops up and I need to check the project again. Having
> the compilation cache still available might very easily save me in the
> order of minutes or tens of minutes.

Weird. I would have considered ccache the perfect example where
automatic cleaning makes sense. Because the usefulness degrades a lot
over time (a change in one header file may invalidate huge parts of the
cache). And because a user might stop/start using ccache and there is
no need to keep a couple of GiB of cached data around indefinitely.

And I also don't think it would impact regular ccache users at all. If
you e.g. configure a cleanup after a long period of time (lets say 120
days), then ccache itself has probably deleted old cached files already
due to disk space limits. Or, if the cached file is still useful, then
you would be quite likely to have accessed it again in that time
period.

> _My time_ is the most precious bottleneck, not the disk space or CPU
> time or whatever technical. Automatic purging (based on no more
> information than the timestamp of files) has much more chance to harm
> than to help me.

The trouble is that this might differ between users. I do agree that
many people will not care about a few hundred MiB or even GiB of junk
data in .cache. And maybe the whole issue of low disk space or quotas
is becoming less important these days (I remember this being quite a
big problem 10 years ago still in the university context).

> > Overall, the assertion that the cache directory should be subject
> > to cleaning by default seems to be a solution without a problem.
> 
> I don't think it's even a solution to that non-problem. Because if I'm
> running short on disk space, I need to take immediate action purging
> some files, I cannot wait for the automatic cleaning to kick in who
> knows when, in days or weeks, to hopefully free up enough space (which
> it most likely won't, by the way).

systemd-tmpfiles --user --clean

or an equivalent, would be a temporary band-aid that users can apply.
But only if enough caches have clean-up configured. And this seems much
better to me than e.g. asking users to run Baobab and figure out what
is safe to delete themselves.

Benjamin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20200227/39b362e0/attachment.sig>