Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!pasteur!miro.Berkeley.EDU!seth
From: seth@miro.Berkeley.EDU (Seth Teller)
Newsgroups: comp.sys.sgi
Subject: Re: Bizarre .nfs* occurrence
Message-ID: <10432@pasteur.Berkeley.EDU>
Date: 25 Jan 91 00:23:23 GMT
References: <9101230417.AA05385@nazgul.physics.mcgill.ca>
Sender: news@pasteur.Berkeley.EDU
Reply-To: seth@miro.Berkeley.EDU (Seth Teller)
Organization: University of California at Berkeley
Lines: 26

>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?
>Loki Jorgenson              / /          \ \  node:  loki@Physics.McGill.CA

it's nfs 'marking' your directory (obvious analogy to dogs and fire
hydrants left partially to your imagination).  at berkeley we cross-
mount sgi and bsd file systems, so who knows whose nfs is at fault.
but apparently these things can hang around for quite a while; 
here's ~550k of such cruft i found today, more than six months old:

% find . -local -name '.nfs*' -exec /bin/ls \-l {} \;
-rw-r--r--   1 seth user 295812 Jul  5  1990 ./inigo2/seth/fontstuff/.nfsD21141
-rw-r--r--   1 seth user 245760 Jul 15  1990 ./inigo2/seth/sethtools/.nfs596EF

for those who want to nuke all such .nfs* files:

% su
% cd /
% find . -atime +1 -local -name '.nfs*' -exec /bin/rm \-f {} \;

the -atime +1 is to leave alone those files younger than one day, in case
nfs really needs them for something timely.

seth