Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bloom-beacon!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.emacs
Subject: Re: Does GNU emacs ever use shared libraries?
Message-ID: <11471@bloom-beacon.MIT.EDU>
Date: 17 May 89 00:05:56 GMT
References: <152@talarian.UUCP> <PINKAS.89May14180259@hobbit.intel.com> <39999@bbn.COM>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)
Distribution: usa
Organization: Massachusetts Institute of Technology
Lines: 46

In article <39999@bbn.COM> jr@bbn.com (John Robinson) writes:
>In article <PINKAS.89May14180259@hobbit.intel.com>, pinkas@hobbit
>(Israel Pinkas ~) writes:
>>2) If the image is deleted, everything goes haywire.
>
>Whoa.  My understanding has always been that you can unlink a file,
>but its inode stays around until every open FD on it is closed.  You
>are implying that NFS breaks this behavior?  Seems to me that Unix
>would have a hard time living with this change.

Since an NFS server does not save any state (well, at least, not
unless you've got the lock manager running :-), it cannot possibly
know when a client is using a particular binary.  Therefore, when you
delete a file using NFS, the file goes away.

An exception to this is if you delete a file and are running it *on
the same host* when you delete it.  NFS clients are smart enough to
recognize this as a special case, because so many programs require a
file to stay around after unlink'ing it (including many compilers, and
all of the hacks discussed recently for using temporary files in shell
scripts).  If this happens, then the client renames the file to some
wierd unique name (usually beginning with ",NFS" and ending with a
number), and really tells the NFS server to remove the file once the
process on the client host has closed it.

This is why if an NFS client crashes you will occasionally find ",NFS"
files floating around the filesystem -- the client didn't get a chance
to tell the server to get rid of those files before it crashed.

One of the side-effects of the amazing disappearing binaries is that
sites that use NFS a lot for moving around binaries have to modify
their installation procedures (read "Makefiles") so that the old
version of the binary is moved out of the way rather than deleted.
This way, assuming that the next installation won't happen for a
while, people who are still running the old version will eventually
end the process and the next time they run the program they'll get the
new version.  My Makefiles usually do:

install:
	-mv $(DESTDIR)$(BINDIR)/$(TARGET) $(DESTDIR)$(BINDIR)/.\#$(TARGET)
	install -c -s $(TARGET) $(DESTDIR)$(BINDIR)

Jonathan Kamens			              USnail:
MIT Project Athena				410 Memorial Drive, No. 223F
jik@Athena.MIT.EDU				Cambridge, MA 02139-4318
Office: 617-253-4261			      Home: 617-225-8218