Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!usc!ucsd!ucbvax!ucsfcgl!babar.mmwb.ucsf.edu!srp From: srp@babar.mmwb.ucsf.edu (Scott R. Presnell) Newsgroups: comp.sys.sgi Subject: Re: Bizarre occurrence Message-ID: Date: 23 Jan 91 16:57:20 GMT References: <9101230417.AA05385@nazgul.physics.mcgill.ca> <14934@smoke.brl.mil> Sender: daemon@cgl.ucsf.edu Lines: 42 moss@brl.mil (Gary S. Moss (VLD/VMB) ) writes: >In article <9101230417.AA05385@nazgul.physics.mcgill.ca>, loki@NAZGUL.PHYSICS.MCGILL.CA (Loki Jorgenson Rm421) writes: >|> I was cleaning out a directory with a /bin/rm -r >|> command when it failed with "directory not empty". Since this command >|> recursively cleans out directories *before* removing them, something >|> had to have appeared in mid-remove. >|> >|> I looked in the directory and saw ".nfsE5E79". >|> I don't like this much. Anyone seen this before? >Yes, and I don't like it much either. I noticed it when doing a recursive >destruction of a directory hierarchy from a C program using directory access >library calls and unlink. For some reason, I haven't noticed this happening >-Gary As I understand it, ".nfsXXXX" files are *temporary* files which NFS uses when in the process of a transfer. The fact that .nfsXXXX file occurred in the middle of a remove sounds like someone or *something* else was trying to use that directory as you were removing it. Not incredibly likely, but not impossible. Could that be it? Also, when a NFS connection is severed sometimes these files get left behind. Indeed, part of my cleanup script does a search and destroy on those .nfsXXXX which have not been used in 7 days. I see a handful of them per month. We have some "long distance" NFS connections. >recently. One thing that changed is we turned on lockd/statd; I don't know >if it is related, but if you don't have these running you should (on both >server and client machines) to avoid other problems. Under some circumstances (in my case it was NFS mounted mail directories) lockd/statd in IRIX 3.3.1 are confirmed (by SGI) broken. - Scott -- Scott Presnell +1 (415) 476-9890 Pharm. Chem., S-926 Internet: srp@cgl.ucsf.edu University of California UUCP: ...ucbvax!ucsfcgl!srp San Francisco, CA. 94143-0446 Bitnet: srp@ucsfcgl.bitnet