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.
--
http://mail.python.org/mailman/listinfo/python-list
