Bizarre occurrence

[Scott R. Presnell]

moss at brl.mil (Gary S. Moss (VLD/VMB) <moss>) writes:

>In article <9101230417.AA05385 at nazgul.physics.mcgill.ca>, loki at NAZGUL.PHYSICS.MCGILL.CA (Loki Jorgenson Rm421) writes:
>|> 	I was cleaning out a directory with a /bin/rm -r <directory>
>|> 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 at cgl.ucsf.edu
University of California			UUCP: ...ucbvax!ucsfcgl!srp
San Francisco, CA. 94143-0446			Bitnet: srp at ucsfcgl.bitnet