/tmp -- the permanent discussion

[BostonU SysMgr]

(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