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