Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards
Subject: Re: How can unlinking be postponed?
Message-ID: <1520@umcp-cs.UUCP>
Date: Mon, 9-Sep-85 07:15:49 EDT
Article-I.D.: umcp-cs.1520
Posted: Mon Sep  9 07:15:49 1985
Date-Received: Wed, 11-Sep-85 04:54:38 EDT
References: <516@riccb.UUCP> <234@uwai.UUCP>
Distribution: net
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 26

To give people another reason not to unlink open files (besides
that it does, er, ``interesting'' things under NFS [it *does*
work, I'm told]), consider the following:

	multi 1000 </usr/dict/words >/tmp/file1

(multi is a program that makes N copies of its input; here N is 1000)
Now suppose /tmp runs out of space.  You can:

	rm /tmp/file1		# oops, file didn't actually go away
	ps ax			# find the "multi" process
	kill <pid>		# get rid of it

or you can

	cp /dev/null /tmp/file1	# now have some time to fix things up

Bending the example a bit, suppose that /tmp runs out of file space
and there are a bunch of unlinked-but-open files.  To get rid of
the space these occupy, you must kill the processes holding them
open.  However, if there are ordinary files, you can just trim them
down to zero bytes.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland