[OpenAFS] [grand.central.org #19412] OpenAFS-1.3.85 on Solars 10 Problem with pwd after rename of a directory

[Douglas E. Engert]

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
filename.

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.5050206@anl.gov>,"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
> strange.
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444