Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!root%bostonu.csnet@CSNET-RELAY.ARPA
From: root%bostonu.csnet@CSNET-RELAY.ARPA (BostonU SysMgr)
Newsgroups: net.unix-wizards
Subject: Re: /tmp -- the permanent discussion
Message-ID: <2529@brl-tgr.ARPA>
Date: Mon, 28-Oct-85 17:35:10 EST
Article-I.D.: brl-tgr.2529
Posted: Mon Oct 28 17:35:10 1985
Date-Received: Wed, 30-Oct-85 06:23:14 EST
Sender: news@brl-tgr.ARPA
Lines: 26


(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