strange interaction between open and cwd

[Baz Walter]

On 05/05/10 07:24, Nobody wrote:
> On Wed, 05 May 2010 02:41:09 +0100, Baz Walter wrote:
>
>> i think the algorithm also can't guarantee the intended result when
>> crossing filesystem boundaries. IIUC, a stat() call on the root directory
>> of a mounted filesystem will give the same inode number as its parent.
>
> Nope; it will have the same dev/inode pair as if it wasn't mounted, i.e.
> the device will refer to the mounted device, not the device it's mounted
> on, and the inode will be the mounted filesystem's root inode (typically
> #2 for Linux ext2/ext3 filesystems).
>
> And stat()ing the appropriate entry in the parent directory will return
> the same information, i.e. the root inode of the mounted device, not the
> subdirectory of the parent device (as you would see if the filesystem was
> unmounted).

yes, that's actually what i meant (but probably put badly as usual).

> IOW, if stat("foo") reports a different device to stat("."), "foo"
> is a mount point, while if stat("..") reports a different device to
> stat("."), the current directory is the root of a mounted filesystem.
>
>> so
>> if several filesystems are mounted in the same parent directory, there is
>> no way to tell which of them is the "right" one.
>
> The only case which would cause a problem here is if you mount the same
> device on two different subdirectories of a common directory. But in that
> case, it doesn't really matter which answer you get, as they're both
> equivalent in any sense that matters.

nope! just to be clear:

here's what i get on my system, where '/dev/sda1' and '/dev/sda6' are 
mounted at '/boot' and '/home' respectively:

 >>> os.stat('/').st_ino
2L
 >>> os.stat('/usr').st_ino
212993L
 >>> os.stat('/boot').st_ino
2L
 >>> os.stat('/home').st_ino
2L
 >>>

if the algorithm is climbing up from '/home/baz/tmp/xxx', what does it 
do when it searches os.listdir('../../../..')? how can it tell whether 
'boot' or 'home' is the correct next parent if it only checks the inode 
number? i think the algorithm would at least need to take account of 
changes in the current device id. not sure whether that would be enough 
to cover all cases, though.