>>>>> "JF" == Jonathan Fuerth <fuerth@jake.capybara.org> writes:

JF> How does the kernel's pathname->(device, inode) algorithm work when a 
JF> pathname of ".." is given to it when the current directory is the top level
JF> of a mounted filesystem (other than the root filesystem, of course).

See /usr/src/sys/kern/vfs_lookup.c:namei().
In there you'll find this notation:

	/*
	 * Handle "..": two special cases.
	 * 1. If at root directory (e.g. after chroot)
	 *    or at absolute root directory
	 *    then ignore it so can't get out.
	 * 2. If this vnode is the root of a mounted
	 *    filesystem, then replace it with the
	 *    vnode which was mounted on so we take the
	 *    .. in the other file system.
	 */

JF> Also, which inode number is referenced by the .. directory entry of a 
JF> (currently or previously) mounted filesystem's root directory?  Is it a
JF> self-reference (i.e. inode 2) or does it reference an inode on the device
JF> it's currently mounted under?  It would seem odd to do that.

Well, this is where it gets a bit weird.  If you readdir() on a mount
point for an FFS file system, the entry for `..' will have the root
inode number on it, not the i-number of the parent of the mounted-over
directory (which may be some other file system implementation).  It's
not really practical to get that "right."  However, if you try to access
the directory by name `..'  (e.g. stat(), open()), you'll actually be
manipulating the parent of the mounted-over directory.

-- 
==John Kohl <jtk@kolvir.arlington.ma.us>, <john_kohl@alum.mit.edu>
Home page: <http://people.ne.mediaone.net/jtk/>
Bicycling and Skiing to keep fit.