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