It is rather a long-established "trick" (it goes right back to the
original
Sun implementations) used by NFS client implementations to simulate the behaviour of local Unix filing systems when an open file is unlinked.
I'm not sure this "simulates" local filesystems, which I don't see creating such files.
As I understand it, in Solaris, an NFS client which attempts to remove an open file on a mounted drive with the remove (NFSPROC_REMOVE or NFSPROC3_REMOVE) call will have that call intercepted and replaced with a rename (NFSPROC_RENAME or NFSPROC3_RENAME) call instead. The file is renamed .nfsXXXX (where XXXX is a unique suffix) to ensure that the original process using the file is allowed to complete. When the file is closed, remove is issued on the .nfsXXXX file.
Here is an quick example (under an NFS mountpoint):
$ sleep 30 > testfile & [1] 2025 $ rm testfile $ ls -al -rw------- 1 skipper staff 0 Dec 14 08:40 .nfs1D45
Solaris actually ships with a script that is called by cron (/usr/lib/fs/nfs/nfsfind) to remove these files that the client missed.
Stephen Worotynec sw@smoky.ca
Stephen Worotynec sw@smoky.ca writes:
It is rather a long-established "trick" (it goes right back to the
original
Sun implementations) used by NFS client implementations to simulate the behaviour of local Unix filing systems when an open file is unlinked.
I'm not sure this "simulates" local filesystems, which I don't see creating such files.
OK, this is standard Unix filesystem semantics; if a file is unlinked while it is being held open by a process, the file remains accessible to that process until it closes the file (but not to any other process).
This doesn't work in general for NFS filesystems; it is the clients that keep track of open files. Even if a process holds a file open the file can be removed from under its feet by another client.
However, there is a standard trick to partly simulate the semantics of local filesystems; if a client removes a file that is being held open by some process on the same client, the client's NFS routines doesn't remove the file, but renames it to a temporary .nfs* file, which is still accessible to the process that has opened the file. When the process closes the file, it is removed.