[15536] in Athena Bugs
sparc 8.1: pwd/afs lossage (3.4a.patches.4)
daemon@ATHENA.MIT.EDU (John Hawkinson)
Sat Sep 27 23:05:36 1997
Date: Sat, 27 Sep 1997 23:05:33 -0400
To: bugs@MIT.EDU
From: John Hawkinson <jhawk@MIT.EDU>
Under a 3.4a.patches.5 cache manager:
[mary-kay-commandos!jhawk] ~> rxdebug 127.0.0.1 7001 -version
Trying 127.0.0.1 (port 7001):
AFS version: Base configuration afs3.4 5.28
[mary-kay-commandos!jhawk] ~> cat ~afsdev/src/3.4a.patches.5/src/CML/state
C afs3.4 5.28
It seems that the client's id of the current working directory (as
reported by "pwd") seems to vary based on the last mountpoint through
which a directory was accessed.
In this example "$cwd" is tcsh's idea of the current directory (i.e. what is
reported by the prompt. I have the sipb cell's project.tcpdump.build.nb mounted
in two places:
[mary-kay-commandos!jhawk] ~> fs lsm ~/mnt/tc
'/mit/jhawk/mnt/tc' is a mount point for volume '#sipb.mit.edu:project.tcpdump.bld.nb'
[mary-kay-commandos!jhawk] ~> fs lsm /afs/sipb/project/tcpdump/.build
'/afs/sipb/project/tcpdump/.build' is a mount point for volume '#project.tcpdump.bld.nb'
[mary-kay-commandos!jhawk] ~> ls -l /afs/sipb/project/tcpdump/build
lrwxr-xr-x 1 jhawk root 11 Nov 26 1995 /afs/sipb/project/tcpdump/build -> .build/@sys
THE PROBLEM:
So, initially we get to /afs/sipb/project/tcpdump/build/tcpdump via the normal method.
While there, we look at an the same directory through a different mountpoint, and the
pwd output changes:
[mary-kay-commandos!jhawk] /afs/sipb/project/tcpdump/build/tcpdump> ls ~/mnt/tc/sun4x_55/tcpdump > /dev/null
[mary-kay-commandos!jhawk] /afs/sipb/project/tcpdump/build/tcpdump> pwd
/afs/athena.mit.edu/user/j/h/jhawk/mnt/tc/sun4m_54/tcpdump
Bing! We've now changed to the other mountpoint.
Accessing the original path brings us back:
[mary-kay-commandos!jhawk] /afs/sipb/project/tcpdump/build/tcpdump> ls $cwd > /dev/null
[mary-kay-commandos!jhawk] /afs/sipb/project/tcpdump/build/tcpdump> pwd
/afs/sipb.mit.edu/project/tcpdump/.build/sun4m_54/tcpdump
Accsessing the ~/mnt mountpoint doesn't do anything special, probably because of the cache:
[mary-kay-commandos!jhawk] /afs/sipb/project/tcpdump/build/tcpdump> ls ~/mnt/tc/sun4x_55/tcpdump > /dev/null
[mary-kay-commandos!jhawk] /afs/sipb/project/tcpdump/build/tcpdump> pwd
/afs/sipb.mit.edu/project/tcpdump/.build/sun4m_54/tcpdump
ls -l'ing doesn't seem to help either:
[mary-kay-commandos!jhawk] /afs/sipb/project/tcpdump/build/tcpdump> ls -l ~/mnt/tc/sun4x_55/tcpdump > /dev/null
[mary-kay-commandos!jhawk] /afs/sipb/project/tcpdump/build/tcpdump> pwd
/afs/sipb.mit.edu/project/tcpdump/.build/sun4m_54/tcpdump
But flushing the volume does:
[mary-kay-commandos!jhawk] /afs/sipb/project/tcpdump/build/tcpdump> fs flushvol .
[mary-kay-commandos!jhawk] /afs/sipb/project/tcpdump/build/tcpdump> ls -l ~/mnt/tc/sun4x_55/tcpdump > /dev/null
[mary-kay-commandos!jhawk] /afs/sipb/project/tcpdump/build/tcpdump> pwd
/afs/athena.mit.edu/user/j/h/jhawk/mnt/tc/sun4m_54/tcpdump
This seemed pretty weird.
[mary-kay-commandos!jhawk] ~> which pwd
/usr/bin/pwd
I'm not sure if it's really worth doing anything about since fixing it may be
very hard...
--jhawk
