rrjl@stl.nexen.com (Jay Orr) writes:
have you tried a "fuser" command on the files to see what processes are using the file?
That's certainly the thing to do if unlinking the .nfs* file just causes it to pop up under another .nfs* alias, as in that case you can be sure your client kernel thinks the file is open. [And assuming you have an fuser command or equivalent in your OS, of course: otherwise try installing lsof.]
sirbruce@ix.netcom.com (Bruce Sterling Woodcock) writes:
A good thing to do is set up a weekly cron job to do a find on the filer and delete any .nfs* files over a week old. Would be nice if this was integrated into the filer's own cron facility, though.
Something along the lines of Solaris's /usr/lib/fs/nfs/nfsfind, in other words. Unfortunately this is quite contentious, because one can take issue with
1. The time interval: why one week rather than one hour or one year? It depends on what one expects the clients to be doing.
2. What sort of time? Solaris uses -mtime but I could easily argue for -atime or -ctime or some combination of them all.
3. The test on the names. There's nothing in any of the NFS standards that mandates this behaviour, let alone the nature of the names to be used. As has been pointed out already, it's a fudge, and although .nfs* will cover most client implementations more or less descended from the original Sun one, it's unfortunately wide.
In case you think that this is being hypercritical: a few years ago one of our users was mystified by the way that his file .nfs_domain kept disappearing, when it was "essential for the functioning of my environment" as he told us...
The security problems associated with root-privileged programs traversing directory trees that can simultaneously be modified by users with evil intentions should also be kept in mind.
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.