Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!genrad!jpn From: jpn@genrad.uucp (John P. Nelson) Newsgroups: comp.unix.wizards Subject: Re: Making rm undoable Message-ID: <18949@genrad.UUCP> Date: 27 Mar 89 22:12:03 GMT References: <6805@phoenix.Princeton.EDU> <7360@phoenix.Princeton.EDU> <10113@bloom-beacon.MIT.EDU> Sender: news@genrad.UUCP Reply-To: jpn@genrad.genrad.COM (John P. Nelson) Distribution: usa Organization: GenRad, Inc., Concord, Mass. Lines: 33 >NFS does manage to keep files that are still open around. Try the following: > tail -f foo & > rm foo > ls .nfs* >You'll see that foo has been renamed to .nfsXXX. Now if you kill the >tail, .nfsXXX will go away. This is only true if the 'rm' and the 'tail' occur on the same machine. Try it with two different machines: No .nfsXXX file is created. You get assorted bizzare behaviors when this happens. Actually, I discovered this because we had an application where this behavior was very annoying. >I'm not sure quite how that interacts >with statelessness. It's possible that if you open a file, remove it, >and then crash before closing it, that the .nfsXXX file will stay on >the the file server. Yes, it does. >Despite all the comments about how NFS violates "Unix semantics", >we've not run into anything that failed across NFS, aside from bugs in >implementations. We had a ascii "database" with both readers and writers: The readers simply open the file, but the writers use locking and always create a new file, then rename the new file as the old file (expecting old readers to keep their descriptors to the old file). Unfortunately, this doesn't work under NFS (at least not in sun 3.x: I don't know about sun 4.x). john nelson UUCP: {decvax,mit-eddie}!genrad!jpn smail: jpn@lightning.genrad.com