Hacker News Reader

Comment by Terr_ | Hacker News Reader

> I also think both should be clean at bootup.

I'm OK with a RAM-backed /tmp getting cleaned every boot simply because that's part of the technical tradeoff, however "on boot" is a bad trigger because its behavior is unreliable and can easily backfire and harm a user.

A classic example would be if the power is interrupted and the computer restarts. 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.

In other words, the difference to users between "I won't need this after tomorrow" versus "I won't need this by next boot" can be very important.

View on HN

> 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.

> 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."

does 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

mtime atime ctime? If it's good enough for logrotate it's good enough for /tmp.

If the system went wonky because the disk was full, then clearing this on boot might help me get to a working system.

Reply on news.ycombinator.com