Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site drivax.UUCP
Path: utzoo!linus!philabs!prls!amdimage!amdcad!amdahl!drivax!alan
From: alan@drivax.UUCP (Alan Fargusson)
Newsgroups: net.unix-wizards
Subject: Re: How can unlinking be postponed?
Message-ID: <227@drivax.UUCP>
Date: Tue, 10-Sep-85 00:45:02 EDT
Article-I.D.: drivax.227
Posted: Tue Sep 10 00:45:02 1985
Date-Received: Sat, 14-Sep-85 01:10:22 EDT
References: <516@riccb.UUCP>
Distribution: net
Organization: Digital Research, Monterey, CA
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()!  What's
> going on here?  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?

When a file is unlinked while a process has it open then the name is removed
from the directory, but the contents of the file are not released until the
file is closed. All syscalls work correctly because they use information
from the inode. The directory entry is only used by open.
-- 

Alan Fargusson.

{ ihnp4, amdahl, mot }!drivax!alan