updog:~# cd /afs/mw/u/m/mloftis/var
updog:/afs/mw/u/m/mloftis/var# /bin/pwd
/afs/modwest.com/u/j/jslife/var
That in and of itself is weird bug enough. You can replicate this one by
making two or three mounts then stating the first, and using getcwd
(/bin/pwd, note that bas pwd builtin uses PWD env var and/or internal state
and so is NOT affected in the same way!!!) var *is* the same volume
mounted in both places.... worse....
updog:~# chroot /afs/mw/u/j/jslife/
updog:/# cd /var
updog:/var# /bin/pwd
/var
OK...but...
updog:~# chroot /afs/mw/u/m/mloftis/
updog:/# cd /var
updog:/var# /bin/pwd
/afs/modwest.com/u/j/jslife/var
*INSIDE* the chroot we're seeing a path that's outside. I think AFS is
doing something really wrong WRT dentry or inode caches. Stock Debian
1.4.2-6 client/kernel, fileserver/etc all on same machine. /vicepa is on
reiserfs but that shouldn't make any difference, this seems to be all
client side issues.
My guess is it has something to do with the "thou shalt not make hardlinks
to directories" directives but...my foo is a little weak to resolve this
one by myself.
--
"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
