Deletion-handling of open files in NFS V2 and V3 (such as it is) is handled at the NFS client. The NFS server isn't aware of which clients have a file open, or how many processes on those clients have a particular file open (I'm assuming no NFS locking here).
If a process on NFS client "A" has a file open, then another process on that same client deletes the file, the NFS client sends a "RENAME" to the NFS server, instead of a "REMOVE", so that the file sticks around until that first process closes the file (at least this is the case for NFS clients with which I'm familiar). The file is renamed to ".nfsXXXX", or something of that ilk, but the NFS file handle remains the same, so the first process can continue to read/write/etc. However, if a process on a different NFS client, "B", deletes the file, client "B" has no way of knowing that the file is open by a process on client "A". So client "B" will go ahead and remove the file completely, resulting in ESTALE the next time the process on client "A" attemts an operation on the file.
Do you have just one NFS client accessing the file in question? What NFS client are you using?
Hope this chatter is of some use.
Cheers,
Steve
-----Original Message----- From: Edward Hibbert [mailto:EH@dataconnection.com] Sent: Wednesday, September 06, 2000 4:39 AM To: toasters@mathworks.com Subject: ESTALE
Does anyone know under precisely what circumstances NetApp returns ESTALE?
I have a file open in my application to which I have just done a write; I issue another write very shortly thereafter and I get ESTALE back.
Now, I believed that ESTALE was returned when a file handle was presented where the file had really been deleted and the inode for the file was reused for a new file. But since my process has the file open, even if it's been deleted by some other process (which is possible), I don't think I should get ESTALE returned.
So this means I don't understand what is going on. But perhaps you do :-).
Edward Hibbert.