Re: Urgent help needed on an NFS question, please help!!!

["Xin Zhao" <uszhaoxin@gmail.com>]

That makes sense.

Can we make the following two conclusions?
1. In a single machine, inode+dev ID+i_generation can uniquely identify a file
2. Given a stored file handle and an inode object received from the
server,  an NFS client can safely determine whether this inode
corresponds to the file handle by checking the inode+dev+i_generation.

Thanks,
-x


On 8/10/06, Matthew Wilcox <matthew@wil.cx> wrote:
> On Thu, Aug 10, 2006 at 11:15:57AM -0400, Xin Zhao wrote:
> > I am considering another possibility: suppose client C1 does lookup()
> > on file X and gets a file handle, which include inode number,
> > generation number and parent's inode number. Before C1 issues
> > getattr(), C2 move the parent directory to a different place, which
> > will not change the parent's inode number, neither the file X's inode,
> > i_generation. So when C1 issues a getattr() request with this file
> > handle, the server seems to have no way to detect that file X is not
> > existent at the original path. Instead, the server will returns the
> > moved X's attributes, which are correct, but semantically wrong. Is
> > there any way that server deal with this problem?
>
> It isn't semantically wrong.  There is no way for the application to
> distinguish between the events:
>
> open()
> stat()
>         mv
>
> and
>
> open()
>         mv
> stat()
>
> As long as the results are consistent with the former case, it doesn't
> matter if the latter case actually happened.
>