Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site alice.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!alice!ark
From: ark@alice.UucP (Andrew Koenig)
Newsgroups: net.unix-wizards
Subject: Re: How can unlinking be postponed?
Message-ID: <4282@alice.UUCP>
Date: Sat, 7-Sep-85 10:13:22 EDT
Article-I.D.: alice.4282
Posted: Sat Sep  7 10:13:22 1985
Date-Received: Sun, 8-Sep-85 04:33:38 EDT
References: <516@riccb.UUCP>
Organization: Bell Labs, Murray Hill
Lines: 22

> Perhaps I am misreading the manual, but I am under the impression that if
> a process unlinks a file while any process has the same file open and that
> is the last link to the file, then the actual removal of the file is post-
> poned until the last process with the file open closes the file, either
> explicitly or by exit or exec.  Yet when I try experiments with one or
> more background processes and then do ls's in the foreground, I find the
> file disappears immediately after one process does its unlink()!

No, you find that the link disappears immediately.  ls tells you about
links, not files.

> Does the directory entry disappear immediately but not
> the i-node and its associated disk space? If that's so, shouldn't any
> syscall except read return an error value since the process making that
> call is under the reasonable impression that the file's still there when
> it isn't?  Is there no way for a file to be removed upon a process' exit?

You are correct -- the directory entry disappears immediately
and the file stays around.  Thus system calls such as read, write,
fseek, and so on continue to work normally: the file is still there.
The file will go away by itself when the last process closes it
or terminates.