Hi, On Thu, Feb 27, 2020 at 10:18 AM Benjamin Berg <benja...@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. _______________________________________________ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg