Operating System - HP-UX
1823988 Members
3855 Online
109667 Solutions
New Discussion юеВ

Mystery .nfs files created by ?

 
Dale Corrington
Advisor

Mystery .nfs files created by ?

After installing 11.0 I am finding these files in user and CAD data directories.

-rw-rw-r-- 1 kevin design 7118925 Mar 21 14:22 /disk1/egl/parts/3787/.nfs6F8A

After deleting I find more with a date prior to
when I cleaned them out. They are 1-20meg. The only application I use is Unigraphics CAD/CAM.
I never saw this on HP 10.2
Where are these coming from?
2 REPLIES 2
Steven Sim Kok Leong
Honored Contributor

Re: Mystery .nfs files created by ?

Hi,

Use lsof to identify the processes associated with these files. You can download the latest copy of lsof from: http://hpux.cs.utah.edu.

Hope this helps. Regards.

Steven Sim Kok Leong
Brainbench MVP for Unix Admin
http://www.brainbench.com
Garry Ferguson
Frequent Advisor

Re: Mystery .nfs files created by ?

Hi Dale,
We had this problem. I made the following note
to myself after sussing it.
Regards, Garry Ferguson

I found an old post from Steve Fosdick that may explain .nfsXXXX files on mounted NFS filesystems:

""""This is tied up with the UNIX delete file semantics, and the fact that
NFS is a stateless protocol.

UNIX allows a file to be deleted when it is still open. The directory
entry for the file is removed at delete time, and hence the file
appears to have gone for anyone trying to open it afresh. The inode
and disk blocks are retained until the last process closes the file,
thus allowing processes which still have it open to carry on using it.

NFS does not support the operation of opening and closing files, so
the NFS server will open a file when it is accessed by the client,
then some time after the last client has appeared to use it it will
close the file. There is no way for the server to know whether one
of the clients still has the file open.

So, when a client deletes the file, the server cannot actually delete
it for some time, because it doesn't know whether it will still get
requests to read/write that file from processes on the client which
still have it open, yet it should return a "No such file or directory"
error to any new process which tries to access the file.

The way it handles this is to rename the file to a temporary name such
as you have seen, and remember which clients still have access to it.

You can delete them, if you are sure that all the clients which may
have had the original file open have finished with it - difficult to
determine."

What I am doing from time to time, is zeroing these files, as these files may still have a file descriptor on them. """"

It looks like the nfs server will clear .nfs files itself. EVENTUALLY!
They are only created if an open file is deleted.
I have changed the permissions on /usr/sbin/fuser on all the HP boxes
so it can be run by any user. ( It already can under Solaris. )
/usr/sbin/fuser -fu
will show who has open files.

If you get any more try, as mentioned, the zeroing bit.
I guess he means something like echo > .nfsxxxx