On Sat, Sep 22, 2007 at 09:57:25AM -0400, Greg Troxel wrote:
> I will have to debug this in the kernel; I wonder if there are two
> vnodes for the same directory, but cd ../testserver.coda.cs.cmu.edu
> works and there pwd fails as well.

There actually are 2 objects in the same location. One is the mount link
which exists in the parent volume, the other is the root directory of
the mounted volume that 'covers' the mount link object. In this case the
lookup is passed to venus and it will traverse to the root directory
object whenever it ends on the mount link. The ls -ai output will also
be correct because ls calls stat(2) on each object, in which case venus
will traverse to the root directory object if we end on the mount link.

The problem with pwd is that it uses the inode numbers that are stored
in the parent directory, which for mount points is actually the hashed
fid of the mount link object instead of the root directory of the
mounted volume.

So when pwd wants to figure out which directory entry we are in the
parent, it gets the inode number from '.' and then does a readdir on
'..' until it finds an entry with a matching inode number. But there
really isn't a match because the parent directory really contains a
symbolic link object. If pwd were to call stat on every directory entry
it would be able to find a match because venus would return the
attributes of the mounted object instead, but calling stat on every
directory entry is more expensive.

And this doesn't only happen for the root of a volume, but also in other
situations where an object from a different volume ends up mounted over
an existing object, for instance when we expand a conflict.

Jan