Cleaning of $XDG_CACHE_HOME and $XDG_CACHE_HOME/thumbnails

[Bardot Jérôme]

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

>> <snip>
>>> 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?
>>
>> 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.
> 
> Benjamin
> 
> 
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x053A41EF03878A98.asc
Type: application/pgp-keys
Size: 3098 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20200226/107a99a1/attachment-0001.key>