Terry, Thanks much for you comments, but see below.
> The real problem here is that you know you did an operation > on the file which would break the name/nfsnode relationship, > but did not flush the cached name and nfsnode data. nfs_request() actually calls cache_purge() on ESTALE, and vn_open() frees vnode with vput() if a lookup was successful but there were an error from the underlying filesystem (like ESTALE resulting from nfs_request() which is eventually called from VOP_ACCESS or VOP_OPEN). > A more correct solution would resync the nfsnode. I think this is exactly what happens :) Actually, I believe, I'm just getting another namecache entry with another vnode/nfsnode/file handle. > The main problem with your solution is that it doesn't work > in the case that you don't know the name of the remote file > (in which case, all you really have is a stale file handle, > with no way to unstale it). I think, in this case (if the file was rm'd on the server), I'll just get ENOENT from the second vn_open() attempt, which would be more than appropriate. A real drawback is that for a stale "current" directory it'll take another lookup to detect "true" ESTALE. > This would fix a lot more cases than the single failure you > are fixing. Actually, as I said, I played with different parts of the code to solve this (including, nfs_open(), nfs_access(), nfs_lookup() and vn_open()) only to find the previously mentioned solution to be the simpliest and most suitable for all situations (for me!) :) _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
