Cleaning of $XDG_CACHE_HOME and $XDG_CACHE_HOME/thumbnails
bardot.jerome at gmail.com
Wed Feb 26 13:46:04 UTC 2020
On 26/02/2020 14:30, 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
>> 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.
I’m not sure a destructive by default behavior is a good thing even on
a cache directories.
I’m pretty sure this will lead to a lost of data.
> 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.
Not all GNU/linux comes with systemd. Protocol and specification over
tools/implementation specific. If it come restrictive it’s not good.
Exept for security stuff and even in this case it’s not always a good
choice. (for ie : 2fa when only choice is a phone)
>>> 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
>> 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.
> xdg mailing list
> xdg at lists.freedesktop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3098 bytes
Desc: not available
More information about the xdg