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 <[EMAIL PROTECTED]>,"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 <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
