2 ms·
> Unless the user is present and savvy enough to block it somehow, all of their short-term "throwaway" project/data just got deleted before they actually finish
by jraph 2y ago
> Unless the user is present and savvy enough to block it somehow, all of their short-term "throwaway" project/data just got deleted before they actually finished with it.
That's on them.
I use /tmp like this, because I'm lazy and don't want to have to mess with a directory I need to routinely clean up, but I know that if the computer crashes, it's gone. That's on me.
If you don't like this risk, you need to work in persistent storage.
/tmp is for programs' temporary files. Manually using it like this is abusing it. That's fine, it doesn't hurt anyone beside the user doing it, but they need to bear the consequences of doing it.
- Spivak 2y ago> If you don't like this risk, you need to work in persistent storage. Which is literally what /var/tmp is and what the parent is advocating for. However, clearing /tmp at boot is not the greatest technical choice. There's nothing really special about rebooting the system. The idea that files in /tmp are kept around for anywhere between minutes, hours, and days makes for bad policy which systemd-tmpfiles fixes quite elegantly. You shouldn't lose your temp file after 30 seconds because your machine lost power. You should be able to say "files created here are cleared after $short_time of inactivity."
- semi 2y agodoes inactivity mean writes? reads? stat() calls? IMO setting the expectation of 'wont survive a reboot' is more consistent. but even that fails with private tmp files that could be tied to ephemeral units
- Spivak 2y agomtime atime ctime? If it's good enough for logrotate it's good enough for /tmp.