Cleaning of $XDG_CACHE_HOME and $XDG_CACHE_HOME/thumbnails

Benjamin Berg benjamin at
Wed Feb 26 17:18:38 UTC 2020


So, lets try to clarify a few points.

I do think that it is a good idea to use tmpfiles.d and for
applications to ship appropriate configurations. There seems to be an
overall agreement that tmpfiles.d is an appropriate way of doing this
and that we could standardise on it.

The strong argument in favour is that we have an external service that
guarantees cleanup even if the application is not running regularly.
For example, I have multiple .cache/* directories with relevant amounts
of junk data for applications that I have not used in months to years.

But, I would like to go one step further and make this an opt-out.
Which is what appears to be triggering the opposition here. The
argument in favour is a bit more complicated, but I think it boils down

 * The behaviour becomes explicit rather than an implicit "keep
   forever" policy. I do feel that this is really good in principle.
 * In principle, I don't think it is sane to keep caches forever. So I
   do believe it makes sense to define the expectation that
   $XDG_CACHE_HOME is cleaned eventually even if the application is not
   run regularly.
 * If a user just stops using an application and removes the package,
   then we should clean the cache. This works very nicely with an opt-
   out solution, as the tmpfiles.d config is removed and the default
   configuration kicks in and cleans things up.

And yes, I do agree that it may well be a bit painful at the point when
the switch is flipped. I wouldn't expect that to happen for another 1-2 
years after the specification changed though; and I expect that some
distributions would play safe und would wait even longer.

So yeah, I don't feel that sticking to the status-quo of never deleting
application caches is sane. I am happy to reconsider my position. But I
really don't find it a very convincing counter argument that the
transition may be painful in a few cases.


On Wed, 2020-02-26 at 13:45 +0100, Benjamin Berg wrote:
> Hi,
> so I looked at gsd-housekeeping the other day. With systemd-
> tempfiles,
> it only has two purposes these days:
>  1. Cleaning $XDG_CACHE_HOME/thumbnails after 30 days
>  2. Cleaning the trash directories after a configurable time
> Currently it also tries to clean /tmp and /var/tmp, but doing so is
> really dangerous compared to just leaving it up to systemd-tempfiles
> (I
> have filed an MR to disable the logic if we are systemd booted).
> 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. So I am thinking that we could do the following:
>    1. Specify that we use the systemd tmpfiles.d configuration format
> for
>       cleaning $XDG_CACHE_HOME. Also specify that $XDG_CACHE_HOME
> will be
>       cleaned automatically after e.g. 30 days unless otherwise
> configured
>       by an application.
>    2. Add some reference to this to the thumbnail specification.
>    3. Tell application maintainers that they need to ship a
> configuration
>       if they want to keep files longer (likely candidates are e.g.
> email
>       clients).
>    4. As a start, add a "xdg-thumbnails.conf" systemd-tempfiles
>       configuration to systemd that cleans $XDG_CACHE_HOME/thumbnails
>       after 30 days.
>    5. After a grace period, add "xdg-cache.conf" to clean
>       and remove "xdg-thumbnails.conf" again (similar to how
>       /usr/lib/tmpfiles.d/tmp.conf does it for /var/tmp and /tmp)
> 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?
> Other thoughts?
> Benjamin
> _______________________________________________
> xdg mailing list
> xdg at
-------------- 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: <>

More information about the xdg mailing list