Cleaning of $XDG_CACHE_HOME and $XDG_CACHE_HOME/thumbnails

[Benjamin Berg]

On Fri, 2020-02-28 at 00:11 +0100, Egmont Koblinger wrote:
> [SNIP]
> 
> 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?

tmpfiles.d seems to specify the following locations:
  ~/.config/user-tmpfiles.d/*.conf
  $XDG_RUNTIME_DIR/user-tmpfiles.d/*.conf
  ~/.local/share/user-tmpfiles.d/*.conf
  /usr/share/user-tmpfiles.d/*.conf

This is just the list at the top of the tmpfiles.d(5) man page. I
expect e.g. /usr/local/share/user-tmpfiles.d is also read.

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

Yes, that would happen, unless there is a default to clean eventually.

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

The format proposed here would be standardise on tmpfiles.d. This has
the advantages that we do have (multiple) implementations and it
already works out of the box on systemd enabled systems (i.e.
pam_systemd is enabled and a user systemd instance is launched at login
time).
For the non-systemd case one nay need to create a small scheduler
around one of the implementations and e.g. start that using an XDG
autostart file.

As said, tmpfiles.d does not live inside the cache itself.

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

One would set it this age on a per-directory level in most cases; the
age itself is then considered on a file level. With tmpfiles.d it would
not be possible to e.g. set a file attribute to trigger cleanup.

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

Well, in that case we would need a completely new specification based
around saving extended attributes for the files. I suspect that would
also require a lot of extra files on disk to store the relevant
metadata.

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

tmpfiles.d is specified to use the newest of mtime/atime/ctime.

So yes, grep'ing through caches would prevent such cleanups from
happening.

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/20200228/c93373de/attachment.sig>