open() and ESTALE error

[Andrey Alekseyev]

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.