Joey Hess <jo...@debian.org> writes: > Henrique de Moraes Holschuh wrote:
>> In fact it is the other way. We have /var/tmp for the large file since >> about forever, and important platforms that have /tmp in memory since >> the early 2000's (Solaris).... >> And that STILL wasn't enough for people to not screw it up and dump >> large files in /tmp. > No, that is not the difference between /var/tmp and /tmp. Users of /tmp > are not "screwing up", they are storing files that are intended only to > persist while the computer is up, to the correct place. > If programs that write large files to /tmp are changed to usr /var/tmp, > then over time a system will accumulate orphaned large tmp files in > /var/tmp. Nothing will come along and clean them up. I started as one of the people in the "Solaris has been doing this for years, what's the problem?" camp, but I find the argument presented by Joey and others to be persuasive. If there are a wide variety of programs that expect to be able to write files of arbitrary size to /tmp (and I think it's fairly clear from the bug reports that there are, including video streaming, sort, temporary unpacks of archives by file managers, and even Debian's own tools like debdelta), tmpfs is (in most installations) going to be much smaller than the typical available space on a physical disk. The root problem here is that we have multiple parameters that we want to set on temporary storage: 1. Space for dumping arbitrary files without assuming anything about the structure of the user's home directory. 2. Fast space for small temporary files that will be removed when the system is rebooted. 3. Space for large temporary files that will be removed when the system is rebooted. Both /tmp and /var/tmp satisfy 1, but /var/tmp does not satisfy either 2 or 3. Previously, /tmp satisfied 3 but not 2. Now that it's switched to tmpfs, it satisfies 2 but not 3. In an ideal world, in which we could throw out all of UNIX history and make up our own rules, 1 (alone) would be /var/tmp, 2 would be some new path (/run/tmp or something), and 3 would be /tmp. But we don't live in the world where it's likely we can convince everything to move to some new /run/tmp location or the like. Given that, we're not going to be able to satisfy 2 and 3 at the same time. The advantage of 2 over 3 is speed while the advantage of 3 over 2 is functionality, and as a general rule of thumb functionality should be preferred over speed. The argument before was basically that the functionality improvement of 3 was a corner case, but I'm not sure from this thread that we can support that conclusion. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehq67kel....@windlord.stanford.edu