Date: Sat, 21 Jun 2003 02:16:21 +0400 (MSD) From: Andrey Alekseyev <uitm@blackflag.ru> To: truckman@FreeBSD.org (Don Lewis) Cc: freebsd-hackers@freebsd.org Subject: Re: open() and ESTALE error Message-ID: <200306202216.CAA01809@slt.oz> In-Reply-To: <200306202039.h5KKd5M7060679@gw.catspoiler.org> from Don Lewis at "Jun 20, 3 01:39:05 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Don, > old vnode and its associated file handle. If the file on the server was > renamed and not deleted, the server won't return ESTALE for the handle I'm all confused and messed up :) Actually, a rename on the server is not the same as sillyrename on the client. If you rename a file on the server for which there is a cached file handle on the client, next time the client will use its cached file handle, it'll get ESTALE from the server. I don't know how this happens, though. Until I dig more around all the rename paraphernalia, I won't know. If someone can clear this out, please do. It'll be much appreciated. At this time I can't link this with the inode generation number changes (as there is no new inode allocated when the file is renamed). I'm not strong in rename and sillyrename alchemy, just can deduce something from the code, though not much. However, I've just tested my patch with the rename-to-other-name-on-the-server scenario, and it seems to return ENOENT to the application after the local file pagecache is invalidated and the client tries to actually read the file from server using old name and old file handle. > Also, fixing open() doesn't fix similar problems that can occur with > other syscalls that take path names, such as stat() and readlink(). That's a good point. However, if the patch for open() succeeds it can be further extended to other syscalls as well. > If the lookup code is changed so that it more frequently revalidates the > name->vnode->handle entries, then the window where open() can fail due > to ESTALE would be greatly reduced. Sorry, I've got no time for that :) I'm generally not in this area of activities. At least for the next few years I'm an extremely busy man :) Again, thanks a lot for your comments.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200306202216.CAA01809>