[OpenAFS] [grand.central.org #19412] OpenAFS-1.3.85 on Solars
10 Problem with pwd after rename of a directory
Douglas E. Engert
Thu, 04 Aug 2005 10:02:34 -0500
Now that we know why this fails, a bad mount point most likely created
by an admin and not a user, it is a very unlikely problem.
The fact that either of these patches further hides a bad mount point
in that ls -l shows nothing and that it looks like a Solaris bug, which
may well show up with NFS makes me reluctant to use either patch right now.
I have a feeling that there is still some other problems here.
Since the problem only showed up after a rename of a directory,
and Solaris 10 is now caching the file name in the v_path field of
the vnode, and the vnode.h header files say vn_recycle should be
called to clean it up and AFS is not doing this, this could cause
at least performance problems as the v_path name does not match the
I thing the v_path was added to make getcwd much more efficient. But
if the v_path is not correct it will fall back to walking the
directories and thus running into my problem. It would also appear
that rename should also change or free v_path, but I don't see this
being done in other Solaris drivers.
Not calling the vn_recycle when done with a vnode will leave an old
v_path value, and some other fields that vn_recycle clears in the vnode
which could cause other problems when the vnode is reused by AFS.
chas williams - CONTRACTOR wrote:
> In message <42F1160E.email@example.com>,"Douglas E. Engert" writes:
>>I too have been working on a similiar patch today which appears to
>>fix this problem. "ls" still shows the entry, but now "ls -l" does not.
>>Before it showed ./badmp: nodev
> right. ls just reads the directory entries but ls -l will stat each
> entry and discover that the bad mount point says it doesnt exist
> (ENOENT). based on the code i have seen so far, the only safe
> thing to return is ENOENT.
>>Why did you change the afs_AccessOK to READ.
> that's an old bug from an old tree.
>>This really apears to be a Solaris bug, as Solaris 9 did not have a problem.
> i believe solaris9 still had the userspace getcwd which wasnt so
> particular. the new version certainly seems broken. an ESTALE in
> an nfs directory in the path should see the same problem. seems
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439