Miklos Szeredi: > And I've shown, that all the other cases are irrelevant.
I didn't agree all of them, especially about permission bits and i_uid. > You seem to think, that we've already decided, that the right way to > deal with this is to refresh the attributes on lookup. Not *right* way. While I don't know the correct English word, I will call as 'a workaround for fuse.' > The fact is, file attributes are usually not needed during or after > lookup, so refreshing them unconditionally is probably the wrong thing > to do. It is entirely depending upon the filesystem. > I still don't know why aufs needs those attributes. Can you please > ellaborate? For example, aufs lookup is actually lookup for the lower (real) filesystem. After the real lookup, aufs copies the real inode attributes to the virtual inode. > A lookup on "/" won't revalidate the root dentry. What I wrote is stat(2) which includes getattr. > In this case, should the stat fail, because the foo is stale? I don't > think so. It shouln'd matter if foo was renamed, because it is not > being looked up, only it's attributes are being queried. > > Now NFS will probably fail in that case because of the REVAL_DOT > thingy, but that's not the right thing to do IMO. I, probably, understand what you are saying repeatedly. Also I guess the main difference between you and me is whether to rely on the inode attr in positive (lookup-ed) dentry or not. In other word, explicit getattr after lookup, before referencing inode attr, is required or not. Junjiro Okajima ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
