You're now at the stage where you're not just MISSING the point of what people are trying to tell you, you're actively IGNORING it.
Automatically deleting files is a bad idea. Those files aren't yours. You don't know why they are there. Leave them alone. --J Sent from my mobile device. ________________________________ From: Luca Boccassi <bl...@debian.org> Sent: Monday, May 6, 2024 08:20 To: Barak A. Pearlmutter Cc: debian-devel@lists.debian.org Subject: Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default] On Mon, 6 May 2024 at 13:42, Barak A. Pearlmutter <b...@debian.org> wrote: > > > Then upon reading the release notes, on such a machine, one can simply do: > > > > touch /etc/tmpfiles.d/tmp.conf > > > > And they get no automated cleanups. > > This also disables on-boot cleaning of /tmp/. Yes, as it's going to be a tmpfs, so it is no longer needed. Trivial to maintain though if one wants to do so, though. > The root issue here is that deleting not-read-in-a-while > but-maybe-stat'ed-recently-by-make-that-doesn't-count files from > /var/tmp/ by default, particularly when the system didn't used to, > violates the principle of least surprise. Which is what release notes are for, if everything was always the same we wouldn't spend time to put those together > There's an old debugging story While personal anecdotes and stories can be interesting and amusing in many circumstances, I am not really looking for those at this very moment. What I am looking for right now is packages or internal infrastructure that need an update to cope with these two changes before I upload them, so if you know of any please do let me know and I'll happily look into it and at least file a bug, if not a MR. Thanks.
