Subject: Re: How .. is resolved at mountpoints
To: None <firstname.lastname@example.org>
From: John Kohl <email@example.com>
Date: 03/15/2000 21:35:56
>>>>> "JF" == Jonathan Fuerth <firstname.lastname@example.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).
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 <email@example.com>, <firstname.lastname@example.org>
Home page: <http://people.ne.mediaone.net/jtk/>
Bicycling and Skiing to keep fit.