Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!mtxinu!ed
From: ed@mtxinu.COM (Ed Gould)
Newsgroups: comp.unix.wizards
Subject: Re: unlink safe before close?
Message-ID: <853@mtxinu.UUCP>
Date: 9 May 89 20:30:41 GMT
References: <755@unify.UUCP> <8201@phoenix.Princeton.EDU> <8412@chinet.chi.il.us>
Reply-To: ed@mtxinu.COM (Ed Gould)
Distribution: usa
Organization: mt Xinu, Berkeley
Lines: 25

Regarding unlinking open files and continuing to use the descriptor:

>Note that this does not apply to NFS file systems.  The "stateless"
>nature of the protocol precludes the server from knowing that a
>client thinks it still has the file open.

In a strict sense, this is true.  But, there were enough programs
doing exactly this (e.g., the C compiler) that Sun considered the
consequenses too severe.  So they developed a work-around that
covers the typical case.  When a process unlinks a file that it
has open, the *client* system notices this, and instead of sending
an unlink request to the server, it sends a rename.  The new name is
structured according to a well-defined convention that will make it
unique.  The client then removes this file when the process closes
the descriptor.

This is *not* a general solution to the problem of removing open
files.  It is a work-around that solves the most common (and
arguably the only "correct") use of this semantic.

-- 
Ed Gould                    mt Xinu, 2560 Ninth St., Berkeley, CA  94710  USA
ed@mtxinu.COM		    +1 415 644 0146

"I'll fight them as a woman, not a lady.  I'll fight them as an engineer."