Eddie Horng: > Glad to hear you reproduced, yes, make print getcwd warning and continue > without error (sorry I didn't mention it clearly), but some applications > stops if getcwd fails, for example python raise exception in os.getcwd(). > > I tried your nfs client/server without aufs case, yes it is similar case, > dirA is gone, but I notice that d_revalidate to dirA failed, so ls also > report "." is Stale file handle.
Yes, getcwd(2) systemcall returns the error, but getcwd(3) library seems issueing stat(2) internally for "." . It has the same effect to your "cd ." solution, and it has no problem at least on my test system. On my test, ls(1) issues openat(AT_FDCWD, ".") and it succeeds. "stat ." is good too which issues lstat(2) for "." As far as I know (currently), only getcwd(2) systemcall is the problematic case. Of course such library behaviour depends upon the library you use. That is why I wrote about the library version. > If I have to workaround this issue, do you think if aufs always returns > dir's file handle of what it returns at the first time, can avoid the > problem? or fix in nfs, make a re-lookup if file handle compare mismatch? That is the hard question for me because such change may violate the NFS world. I'd suggest you to ask NFS people with the sample which I wrote as "without aufs" case in my previous mail. J. R. Okajima ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
