Cleaning of $XDG_CACHE_HOME and $XDG_CACHE_HOME/thumbnails

[Egmont Koblinger]

Hi,

On Thu, Feb 27, 2020 at 10:18 AM Benjamin Berg
<benjamin at sipsolutions.net> wrote:

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

Yes, that's true, and for that reason automatic cleaning _in some
well-defined cases_, e.g. gcc upgrade (let's put aside what if someone
uses clang or a self-compiled gcc instead of the system one) or distro
upgrade might make sense.

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

Obviously the numbers differ from person to person. To give an
example, at this moment my ~/.cache is 1.8 GB (most of which is
browser cache), and my ccache is 2.5 GB. That's about 0.5% of my 1 TB
drive.

If someone is running out of disk space, probably cleaning the cache
only gives a very short time, until some more permanent solution is
found (large unneeded files/directories manually located or removed,
or photos, music moved to external storage, or drive replaced with a
larger one, etc.). I find it extremely unlikely that someone can in
the long run maintain a 90%+ disk usage (relative to the area
available for regular users), and thus that automatic purging of cache
files could provide a long-term solution. It's only a short-term
band-aid, as you also said.

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

Which brings me to a next bunch of questions -- and I have to admit I
haven't really followed the beginning of this discussion, so I'm
really sorry if I missed it.

Where would these configurations, clean-up rules live?

If (at least partially) they live in a file shipped by the
application, then removing the application will also remove those
rules, hence the cache files will live there forever (or whatever the
global policy is -- which some of us argue that should be to live
forever). Similarly, if it's the application providing a cmdline
option, or helper application that cleans up, which is invoked by
systemd or whoever, then again the cache of removed apps won't be
cleaned up.

Do we care about it? If this is something to be addressed, the cache
purging rules have to live inside the cache, in some common format,
placed there by supporting applications.

Is there such a format anywhere? Or has one been proposed here?

Would it be per application cache (immediate subdirectory of
XDG_CACHE_HOME), or per file? Would it make sense to configure for
each cached file when it's okay to clear that?

Would it make sense to describe trivial dependencies? E.g. if the
cached file is a thumbnail, an additional meta file could point to the
original and include its timestamp; if the original file isn't there
with timestamp then it's okay to remove the cached file, regardless of
its age. How complex would it presumably become if we start in this
direction?

Which timestamp would the age-based cache cleaning use? Access time is
unreliable (recursive greps or backups open the file, but some
filesystems don't update atime). Modify time is nice, but then apps
joining this game would all need to touch the files they read from --
do caching apps typically do this now?


cheers,
e.