root%bostonu.csnet@CSNET-RELAY.ARPA (BostonU SysMgr) (10/29/85)
(re: the 2.9bsd feature to use a bit to control unlinking files in /tmp) >Is this an acceptable fix, or am I missing something? > Michael Baldwin > {at&t}!whuxl!mike It's very close, and may be enough to settle the issue, but it still does not address the cruft left in /tmp that oughta be garbage collected automatically on program exit (users can still cripple a system by filling /tmp, even totally inadvertantly, it seems this oughta be solvable also with some sort of delete-on-last-reference files.) Note that quotas only help a little here (and certainly the sum of the quotas for /tmp for an active system will be much greater than /tmp due to temporary needs, and note that SYSV has no disk quotas that protect against many files being created in /tmp, only against large files.) At the very least, delete-on-last-reference is self correcting, if programs fail because /tmp is full, /tmp gets cleaned up (annoying, but doesn't require finding an operator to fix things up.) I dunno, tmp oughta be tmp, but as I said, we'll live with current solutions, this is more an interesting design issue than a massive flame, though I think we will need the solution if our 3081 goes UNIX (400+ logins, >15,000 user accounts) things could get ugly which is why I am thinking about it, I am sure people with PCs are wondering just what the problem is, so there it is in a nutshell. -Barry Shein, Boston University
gwyn@BRL.ARPA (VLD/VMB) (10/29/85)
A solution to the left-over-upon-abnormal-termination temp file, which works well most of the time, is tmpfile(3S), distributed with UNIX System V. If you don't have one of these, it's not hard to reimplement. In case you're not familiar with this function, it creates a temp file with a unique name, opened for stdio "w+", and arranges for it to be deleted when the program terminates (by pre-unlinking it). I find it very handy.