How .. is resolved at mountpoints
Jonathan Fuerth
answer me. So I looked through the 4.4BSD implementation book, and it didn't
mention the answer either. I figure someone has to know. :)
How does the kernel's pathname->(device, inode) algorithm work when a
pathname of ".." is given to it when the current directory is the top level
of a mounted filesystem (other than the root filesystem, of course).
Also, which inode number is referenced by the .. directory entry of a
(currently or previously) mounted filesystem's root directory? Is it a
self-reference (i.e. inode 2) or does it reference an inode on the device
it's currently mounted under? It would seem odd to do that.
I learned a lot about vnodes in the 4.4BSD book.. they were entirely glossed
over in my OS course lectures. Since the vnode system plays a vital and
active part in resolving pathnames, I wonder if it catches ".." references
at mountpoints before the individual filesystem gets involved. That seems
cleanest, but there must have been something else in place before vnodes
entered the scene, which may or may not have been obsoleted when vnodes were
adopted by BSD.
Finally, I notice that when I fsck my filesystems (say, after a power failure)
I'm told where the filesystem was last mounted. How and where (and why) is
this information stored?
I know I've asked a fair bit here.. I don't want to disrupt the list with
a flood of lengthy responses, so feel free to mail any answers directly to me
if you feel they would otherwise pollute the list.
Thanks!
Jonathan Fuerth
Simon Burge
> Finally, I notice that when I fsck my filesystems (say, after a power failure)
> I'm told where the filesystem was last mounted. How and where (and why) is
> this information stored?
This info is stored in the superblock of the filesystem (look in
/usr/src/sys/ufs/ffs/fs.h). It's _very_ useful when you rearrage
a whole bunch of SCSI id's and want to make sure things are where
they should be :-)
Simon.
John Kohl
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 <j...@kolvir.arlington.ma.us>, <john...@alum.mit.edu>
Home page: <http://people.ne.mediaone.net/jtk/>
Bicycling and Skiing to keep fit.
Greg A. Woods
> Subject: Re: How .. is resolved at mountpoints
>
> >>>>> "JF" == Jonathan Fuerth <fue...@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.
Hmmm... why is there any thing special done when at the absolute root
directory? Isn't ".." still guaranteed to be just a hard link to "." in
the root directory (unless of course you are in fact chroot'ed).
Looking very briefly at the code I see that the elimination of this test
wouldn't likely make much difference of course, and keeping it will
obviate the need for worrying about the correctness of the ".."
directory entry in the absolute root....
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwo...@acm.org> <robohack!woods>
Planix, Inc. <wo...@planix.com>; Secrets of the Weird <wo...@weird.com>
Hubert Feyrer
> I know I've asked a fair bit here.. I don't want to disrupt the list with
> a flood of lengthy responses, so feel free to mail any answers directly to me
> if you feel they would otherwise pollute the list.
Good questions - i'd like to see the answers too! :-)
- Hubert
--
Microsoft: "Where do you want to go today?"
Linux: "Where do you want to be tomorrow?"
BSD: "Are you guys coming, or what?"