loki@NAZGUL.PHYSICS.MCGILL.CA (Loki Jorgenson Rm421) (01/23/91)
Can anyone identify this phenomenon?
IRIS 4D/25 running IRIXv3.3.1 (all observed as non-super user)
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 ran "file"
on it and it turned out to be an unstripped executable. I was about
to run "strings" on it to figure out it function, when IT DISAPPEARED!
This directory was freshly created for a simple unrelated task of
building an executable and there was no obvious connection between
this mystery file and any files manipulated within the directory.
I don't like this much. Anyone seen this before? Anyone can
identify this beast?
Regards,
__ __
Loki Jorgenson / / \ \ node: loki@Physics.McGill.CA
Grad, Systems Manager / ////// \\\\\\ \ BITNET: PY29@MCGILLA
Physics, McGill University \ \\\\\\ ////// / fax: (514) 398-8434
Montreal Quebec CANADA \_\ /_/ phone: (514) 398-7027moss@brl.mil (Gary S. Moss (VLD/VMB) <moss>) (01/23/91)
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 <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 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. -Gary
srp@babar.mmwb.ucsf.edu (Scott R. Presnell) (01/24/91)
moss@brl.mil (Gary S. Moss (VLD/VMB) <moss>) 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 <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@cgl.ucsf.edu University of California UUCP: ...ucbvax!ucsfcgl!srp San Francisco, CA. 94143-0446 Bitnet: srp@ucsfcgl.bitnet