(Illustration by Gaich Muramatsu)
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. JanReceived on 2007-09-24 11:58:00