Re: zgetcwd patch?

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On Aug 18, 12:48pm, Todd Larason wrote:
} Subject: Re: zgetcwd patch?
}
} On Sun, Aug 17, 1997 at 10:05:53PM -0700, Bart Schaefer wrote:
} > It doesn't look wrong to me, but I'm not sure why it wasn't used in the
} > first place, so I can't say for certain.  My guess is that there was an
} > assumption of at most one mount of the same device in any given directory,
} > so the second loop is (before your patch) finding any mount point matching
} > the device and assuming that must be the one.
} > 
} > Why is it, again, that de->d_ino != sbuf.st_ino for the dir in question?
} 
} My understanding was that the first loop would find the parent if it was
} in the same filesystem as the child; the second would find the place the
} child was mounted, in the only other case.

No; both loops are looking for the child's entry in the parent.  The
first looks for entries with the same inode number, then uses lstat to
see if the device number is also the same.  If no entry has the same
inode and device, the second loop uses lstat to look for any entry that
has the same device number as the child.

} The problem is that it was assumed that a filesystem can only be mounted
} one place, and that the device number identifies filesystems.

That part, I believe to be a correct description.

} In this situation, there's /home on filesystem one, /home/a and /home/b
} are both automounted directories from filesystem 2.
} 
} for a and b, de->d_ino is the inode of the mountpoint directory in /home,
} in filesystem 1; sbuf.st_ino is the inode of the mounted directory, in
} filesystem 2.

In that case I also believe John's zgetcwd patch to be correct.  I think
the process could be sped up a bit by replacing the closedir() + opendir()
with a rewinddir(), as I mentioned before.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com