I disagree somewhat. As long as applications from the user session are using /tmp for data, we have a responsibility to offer a cleanup mechanism for that. And the user has no influence at all over the existence or frequency of system-level cleanup. So, no: not redundant.

Whatever is configured for g-s-d does not influence systemd-tmpfiles, so if the user disables cleanup or sets high cleanup age, this has no effect. So it seems that it might be better to not pretend that the user can configure /tmp cleanup times at all. systemd already provides a cleanup mechanism for /tmp and /var/tmp and gnome can rely on that.

Second issue is that running cleanup as user bumps the access time of directories in /tmp. systemd-tmpfiles tries hard to not do that. g-s-d runs as a normal user, so it will always bump access times. So running g-s-d actively interferes with systemd-tmpfiles.

Matthias, what's the trigger for this houskeeping stuff? When precisely does g-s-d clean up /tmp?

https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/housekeeping/gsd-disk-space.c#n996

 purge_trash_id = g_timeout_add_seconds (3600, ldsm_purge_trash_and_temp, NULL);

Hourly, it seems. Files are deleted when they are org.gnome.desktop.privacy.old-files-age days old, which defaults to 30.

I am really sure that g-s-d should drop all that. /tmp and /var/tmp are provided by the system, and the clean-up regime should be enforced by the system hence, something the admin decides on not the user.

And even if this really should be the user's decision (which I disagree with), you simply cannot implement that correctly in unprivileged code, because you bump the atimes all the time, thus breaking the clean-up logic completely. Hence you get the opposite of what you want: instead of facilitating automatic cleanup, you make it impossible.

Please! This needs to go!

(In reply to Lennart Poettering from comment #5)
> I am really sure that g-s-d should drop all that. /tmp and /var/tmp are
> provided by the system, and the clean-up regime should be enforced by the
> system hence, something the admin decides on not the user.

Sorry, not buying it. What we are offering here is not about '/tmp cleanup' at all. It is about cleaning up the users data, regardless where it live.

I could agree to 'applications should not use '/tmp', since thats a system location. But that is not the world we live in.

> And even if this really should be the user's decision (which I disagree
> with), you simply cannot implement that correctly in unprivileged code,
> because you bump the atimes all the time, thus breaking the clean-up logic
> completely. Hence you get the opposite of what you want: instead of
> facilitating automatic cleanup, you make it impossible.
> 
> Please! This needs to go!

Relying on atimes for cleanup seems overly fragile, then.

(In reply to Matthias Clasen from comment #6)
> (In reply to Lennart Poettering from comment #5)
> > I am really sure that g-s-d should drop all that. /tmp and /var/tmp are
> > provided by the system, and the clean-up regime should be enforced by the
> > system hence, something the admin decides on not the user.
> 
> Sorry, not buying it. What we are offering here is not about '/tmp cleanup'
> at all. It is about cleaning up the users data, regardless where it live.
What g-s-d does for user files in non-shared directories is outside of the scope of this bug report.

Anyway, with current defaults, g-s-d expires files from /tmp after 30d, and systemd-tmpfiles after 10d, so disabling g-s-d cleanup of shared directories should not cause problems for the users.

> I could agree to 'applications should not use '/tmp', since thats a system
> location. But that is not the world we live in.
Again, this is outside of the scope. This is only about who cleans up /tmp and /var/tmp.

> > And even if this really should be the user's decision (which I disagree
> > with), you simply cannot implement that correctly in unprivileged code,
> > because you bump the atimes all the time, thus breaking the clean-up logic
> > completely. Hence you get the opposite of what you want: instead of
> > facilitating automatic cleanup, you make it impossible.
> > 
> > Please! This needs to go!
> 
> Relying on atimes for cleanup seems overly fragile, then.
Atimes are fragile, but the alternatives are worse: for most things the access time tells you best when to delete them, not the other timestamps.

I don't understand what [1] makes systemd a better place to clean up /tmp than gnome-settings-daemon.

I'd be fine with moving the implementation of the automated cleanup to systemd, but it needs to have the same functionality as what's currently in gnome-settings-daemon.

Removing files under the user's feet when the preferences say not to isn't what we're looking for here.

[1]: Other than walking files without updating atime not being accessible to normal users

Yes, systemd currently does not have this configurability. At least on the graphical level, because in principle one could create configuration files which would override the default settings, but I don't think this is widely done. But maybe this configurability is not that important. Currently, g-s-d has a switch, but this switch is imperfect, because systemd still does cleanup no matter what. Afaik, people are not complaining about this not working. At least for /tmp disabling automatic cleanup is not even possible because any restart of the system is will wipe everything.

I see the following advantages of letting systemd do it (in addition to your [1]):
1. systemd cannot rely on something higher in the stack like gnome, so it has to provide *some* mechanism anyway

2. system-level mechanism can work even if a particular user is not logged in, which is good for multi-user machines.

To turn this around, what functionality does g-s-d have that systemd-tmpfiles should provide?

Bastient, the atime bumping is really a killer. That alone is plenty reason enough to not do this in GNOME. Whith the current code in GNOME you keep bumping the atimes of all directories you traverse in /tmp, and that's really not OK, and you cannot fix that.

Why precisely does this exist in g-s-d at all? Why is this needed? Why isn't tmpfiles enough?

You're coming from the fact that the feature has been broken in Fedora for a couple of releases. Except that:
- our version works without systemd installed
- it existed before systemd's tmpfiles
- it worked on systems where /tmp wasn't in memory
- it also works on other temporary directories, such as /var/tmp
with the value of "works" being of course relative.

So I'm fine with replacing the gsd code with systemd's, but it needs to be user controlled and configurable. You can see the current toggles and actions in Settings -> Privacy -> Purge Wastebasket and Temporary files.

Well, if this about supporting non-GNOME systems, sure, keep the code, but make it optional, so that FEdora doesn't use it.

tmpfiles covers both /tmp and /var/tmp btw.

That purge temporary files UI seems pretty useless. THis suggests one could opt-out of that as unprivileged user. But one never could. tmpfiles always cleaned up things in /tmp, and so did tmpwatch before it. The UI is really confusing in this regard.

You haven't addressed the other concerns in my comment, and you assume that the user is unprivileged when they could very well be the admin.

Other concerns? Let me reply in detail:

(In reply to Bastien Nocera from comment #11)
> You're coming from the fact that the feature has been broken in Fedora for a
> couple of releases. Except that:
> - our version works without systemd installed

sure, make it optional then, and turn it off in Fedora.

> - it existed before systemd's tmpfiles

Well, before tmpfiles there was tmpwatch (at least on Fedora), and it automatically cleaned up /tmp and /var/tmp too.

> - it worked on systems where /tmp wasn't in memory

tmpfiles supports any files system backing /tmp or /var/tmp. And so did tmpwatch.

> - it also works on other temporary directories, such as /var/tmp
> with the value of "works" being of course relative.

And so did tmpfiles and tmpwatch.

> So I'm fine with replacing the gsd code with systemd's, but it needs to be
> user controlled and configurable. You can see the current toggles and
> actions in Settings -> Privacy -> Purge Wastebasket and Temporary files.

why would this need to be user controlled? The clean-up logic was always in place, via tmpfiles and tmpwatch, and the toggle button in GNOME was pointless hence, because you couldn't actually turn anything off with it... if you turn that button on, then gnome will bump all atimes, and hence the user's own files might be deleted by gnome, but nobody elses anymore. If you turn that button off, then the system will clean up things anyway, through tmpfiles and before tmpwatch. 

The button is completely pointless hence!

(In reply to Lennart Poettering from comment #14)

> 
> > So I'm fine with replacing the gsd code with systemd's, but it needs to be
> > user controlled and configurable. You can see the current toggles and
> > actions in Settings -> Privacy -> Purge Wastebasket and Temporary files.
> 
> why would this need to be user controlled? The clean-up logic was always in
> place, via tmpfiles and tmpwatch, and the toggle button in GNOME was
> pointless hence, because you couldn't actually turn anything off with it...
> if you turn that button on, then gnome will bump all atimes, and hence the
> user's own files might be deleted by gnome, but nobody elses anymore. If you
> turn that button off, then the system will clean up things anyway, through
> tmpfiles and before tmpwatch. 
> 
> The button is completely pointless hence!

It seems to me that you are missing the point...which is different from there not being one.

The important thing is not that you 'preserve' temp files, but that you can enforce that none of your temp files stay around longer than you allow them to.

I don't see this going anywhere unless we get the minimal configurability that was asked for in comment 11. Feel free to reopen this bug when systemd-tempfiles offers the required functionality

I can't reopen it, because I'm not a gnome developer. Please consider this a request to reopen.

Looking at "Purge Wastebasket & Temp Files":
- "automatically purge wastebasket"
  → we don't care about this

- "automatically purge temporary files"
  → there are two settings
  "off" → this doesn't work because systemd-tmpfiles doesn't know about this setting
  "on" + "purge after"
        → if purge after is *higher* than the systemd-tmpfiles setting, this doesn't work
        → if purge after is "lower" than systemd-tmpfiles setting, than this works partially (see original description and comment #2)
- "empty wastebasket" and "purge temporary files"
  → we don't care

So current code is mostly broken and the advertised "configurability" is not there. As deployed on any systemd system this just doesn't work, and has actual adverse effects, and you're doing a disservice to users by pretending that this dialogue window has some effect. Please drop (hide?) the second part of the window ("automatically purge temporary files" and "purge after") and disable the related functionality when running under systemd.