On Wednesday, February 26, 2020 1:41 PM, Simon McVittie wrote: > The only thing that the XDG_CACHE_HOME specification needs to agree on is the > contents and meaning of whatever file format gets used, not a concrete > implementation of the interpreter for that file format (the same way > freedesktop.org defines what .desktop files contain and mean, but it's up to > projects like GNOME to actually implement them in a compatible way).
Note that XDG_CACHE_HOME is covered by the XDG Base Directory spec. It doesn't have its own, as far as I am aware. I am uncertain whether the cleanup functionality, if accepted for specification, would belong in that spec or somewhere else. In principle, it wouldn't need to be specific to $XDG_CACHE_HOME. To the main point, I agree that any specifications that are adopted only need to (or should) address the format, but it is not clear whether everyone is on the same page about that. This was the point of my question. It matters because it may make a difference to some that there is not, in fact, an existing application that would do the wanted job on all systems of interest. > You're assuming that systemd-tmpfiles is running in system mode Yes, I was indeed making that assumption. > However, `systemd-tmpfiles --user` can be invoked as an ordinary user, > unprivileged, to look at various paths including > ~/.config/user-tmpfiles.d/*.conf (which is the highest-precedence) and > create/clean per-user directories. I think the suggestion is that desktop > environments like GNOME should periodically run `systemd-tmpfiles --user`, or > a compatible reimplementation, as a way to clean per-user cached files. Something along those lines would indeed be possible. I did not intend to suggest otherwise, but I did want to establish that all parties agree that something along those lines -- a user process running periodically in the context of a login session -- was what everyone was considering. This has implications that might be important to some people, such as on the timing and scope of each cleanup. >> Why is that a strong argument? Perhaps this is part of the issue. >> I don't see any particular imperative for cleaning up cache files. >... >> users should be responsible for their own usage. >> If they are using too much, then that's what storage quotas are for. > > Some cache files (such as thumbnails and web browser caches) are created by > "the system" without the user being particularly aware of it happening. If > these have built up to the extent that they are a substantial proportion of > the available storage (storage quota on a multi-user system or disk size on a > single-user system), then it isn't at all obvious to a non-knowledgeable user > why they have run out of space or what they should do about it. I'd be inclined to say that cache files created by the desktop and by user applications, without explicit user request, are probably the vast majority of the contents of most users' cache directories. I do not object to the proposition that there should be a way for users to clean these up, either on demand or on a schedule, without being cognizant of the details. I am not overly concerned with browser or thumbprint caches specifically, as there are already mechanisms in place to address those, but sure, it would be swell if such management could be generalized and unified, so that each application didn't have to roll its own. > That's why the "housekeeping" module of gnome-settings-daemon (which I think > is named for its original purpose, hosting Xsettings, but in practice is more > like a collection of miscellaneous background services used in GNOME) has > traditionally been responsible for cleaning up files like > non-recently-accessed thumbnails. As I consider the matter further, I find that I also do not object more generally to cleanup policy being established on behalf of users on a per-application basis, especially if the application provides a good means for the user to adjust that policy. This is the space where common browsers and GSD reside now. I account cleanup mediated or directed by the application as part of the contract between user and application. I acknowledge that this is a more nuanced position than probably was conveyed by my previous comments. Bringing it back around to the original questions, then: [Benjamin:] > Is it reasonable to standardise on the systemd tmpfiles.d format? As a configuration format for describing cleanup properties, yes, it is reasonable. However, it would be wise to evaluate the details of that format to determine whether it would benefit from a bit of customization for the more specialized role proposed for it. > Is it OK to clean $XDG_CACHE_HOME after a fixed time period by default? No, it is not, as a matter of policy and of the nature of $XDG_CACHE_HOME. It is not safe or reasonable to assume that all of the contents are similar to thumbnail or browser caches, that go stale over time and that can easily and cheaply be repopulated. What's more, those particular items are already accounted for. The default should be to protect users' data, including cache data, about which the system has no specific knowledge or instructions. Overall, the assertion that the cache directory should be subject to cleaning by default seems to be a solution without a problem. To the best of my knowledge, users running out of space and not knowing why or what to do about it is not a common or widespread problem in practice, nor do I presently see any other compelling reason to implement a policy change such as is proposed. -- John Bollinger ________________________________ Email Disclaimer: www.stjude.org/emaildisclaimer Consultation Disclaimer: www.stjude.org/consultationdisclaimer _______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg
