NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/unix/programm/4375

Internet Message Format | 1992-08-19 | 3.9 KB

Path: sparky!uunet!auspex-gw!guy
From: [e-mail] (Guy Harris)
Newsgroups: comp.unix.programmer
Subject: Re: Process & Signal Question
Message-ID: <[e-mail]>
Date: 19 Aug 92 21:24:53 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Auspex Systems, Santa Clara
Lines: 65
Nntp-Posting-Host: bootme.auspex.com

>> True. Well, mostly. This may be a bug in the NFS implementation
>> we're using, but if the binary is opened via NFS, you can unlink
>> the file locally on the machine where the file resides. Odd.
>
>It's not odd if you know something about the implementation of NFS.
>The server knows nothing about which files are being executed remotely.
>Executables are read from the server, which explains why NFS imported
>executables must be readable by the invoker.  Should such an executable
>be removed on the server the process executing it on the server will
>_probably_ die, depending on the executable's magic no and its memory
>state.

Except that he said you can unlink the file *locally*, in which case the
*client* should know that the file is being executed locally, and should
do the rename trick (the file is renamed to a special ".nfs*" name, or
whatever, and "marked for deletion" so that when the last local process
holding onto the file lets go of it, it's removed).

If, by "you can unlink the file locally", he meant "you can unlink it
and it goes away on the server, so that the processes using it run the
risk of choking and dying", that *is* a bug in the NFS implementation.

If, by "you can unlink the file locally", he meant "you can unlink it,
but it's just renamed, and only removed when the last local process
holding it lets go of it", that's not a bug in the NFS implementation,
it's a *feature* of the UNIX implementation.

I.e., they probably picked up Berkeley's removal of the old V7 crock by
which an attempt to remove the last link to a running shared-text
executable fails and sets "errno" to ETXTBSY, rather than marking the
file for deletion.

V7 did that because, at the time, it didn't have any decent file system
checkers (it may have had "icheck" and "dcheck", but there's no way in
hell I'd call them "decent"), and the Research folks wanted to avoid
having files hanging around with no links to them, because if the system
crashed, it was a pain to get rid of those files.

Of course, it doesn't prevent that from happening, as you could still
open a file and unlink it while it's open....

For some unknown reason, when they finally got around to putting "fsck"
in, they didn't nuke that no-unlinking-an-active-shared-text-image
crock.  Berkeley, however, realized that it was a crock, and got rid of
it; you could remove the last link to a running image, and it'd be
marked for deletion when the last process stopped using it, just as
happens with open files.

The SVID folk, unfortunately, confused that crock with a feature, and
put it into the SVID.  However, it requires it only for systems that
support "shared text"; at Sun, we figured we'd just say "our system
doesn't support shared text, it supports read-only copy-on-write
mappings", which is entirely true, and avoid having to put that crock
back.  (You still get sharing, because pages not copied-on-write are
shared, but you don't get screwed by not being unable to remove the last
link to a running image.)  Hopefully, the SVR4 folk did the same
thing....

(Do not confuse the aforementioned crock with ETXTBSY on an attempt to
open an active shared-text image file for writing.  The latter can be
defended - and might even be implementable in a reasonable fashion, at
least for local files, in a way that generalizes to handle SunOS
4.x/SVR4-style shared libraries as well.  The former can only be
defended if you have no decent file system salvager, and UNIX has had
"fsck" since at least 1980 or so, and it's decent enough for that....)