strange interaction between open and cwd
in [Python]
|
Prev: ANN: expy 0.6.7 released!
Next: long int computations
From: Baz Walter on 4 May 2010 21:41 On 05/05/10 00:44, Nobody wrote: > On Tue, 04 May 2010 14:36:06 +0100, Baz Walter wrote: > >> this will work so long as the file is in a part of the filesystem that can >> be traversed from the current directory to the root. what i'm not sure >> about is whether it's possible to cross filesystem boundaries using this >> kind of technique. > > At least on Linux, the kernel "fixes" the links at mount points, i.e. > within the root directory of a mounted filesystem, ".." refers to > the directory containing the mount point on the parent filesystem, while > the mount point refers to the root directory of the mounted filesystem. > > This also appears to work correctly for bind mounts (mounting an arbitrary > directory to another directory, which results in a directory hierarchy > appearing at multiple locations within the filesystem), i.e. ".." refers > to the appropriate directory for each "instance". > > OTOH, the algorithm can fail if a directory is moved (whether by rename() > or remounting) between the stat("..") and the listdir(). 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. so if several filesystems are mounted in the same parent directory, there is no way to tell which of them is the "right" one.
From: Nobody on 5 May 2010 02:24 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). 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.
From: Nobody on 6 May 2010 00:24 On Thu, 06 May 2010 10:21:45 +1000, Cameron Simpson wrote: > Look at the st_rdev field (== the device holding this inode). > When that changes, you've crossed a mount mount point. st_dev reports the device on which the inode resides. st_rdev is only meaningul if the inode type is block device (S_IFBLK) or character device (S_IFCHR), in which case it identifies the device to which the inode refers, e.g.: > os.stat("/").st_dev 2049L > os.stat("/").st_rdev 0 > os.stat("/dev/sda1").st_dev 2049L > os.stat("/dev/sda1").st_rdev 2049 > os.stat("/dev/sda2").st_dev 2049L > os.stat("/dev/sda2").st_rdev 2050 (/dev/sda1 is mounted as the root filesystem).
From: Cameron Simpson on 6 May 2010 02:00 On 06May2010 05:24, Nobody <nobody(a)nowhere.com> wrote: | On Thu, 06 May 2010 10:21:45 +1000, Cameron Simpson wrote: | | > Look at the st_rdev field (== the device holding this inode). | > When that changes, you've crossed a mount mount point. | | st_dev reports the device on which the inode resides. | | st_rdev is only meaningul if the inode type is block device (S_IFBLK) or | character device (S_IFCHR), in which case it identifies the device to | which the inode refers, e.g.: Gah. Yes, you're quite right. st_dev is what I should have been citing. -- Cameron Simpson <cs(a)zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ It's better, when you're riding with someone you don't know so well, to stick to the inside line - it's easier to avoid the bits... - Barry Sheene
From: Albert van der Horst on 12 May 2010 07:25
In article <hro17v$3lb$1(a)reader1.panix.com>, Grant Edwards <invalid(a)invalid.invalid> wrote: <SNIP> > >Still, at the time, it _seemed_ like a good way to share a directory >of source code amongst multiple projects. I don't remember why >symlinks wouldn't accomplish the task -- something to do with RCS... Must be deep. I use RCS in combination with symlinks all the time. Like symlinks to a directory tree on a mounted volume, where one is not supposed to check out. Or symlinking happyd.sco,v to HAPPYD.SCO,v effectively making file names case-insensitive. > >-- >Grant > Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert(a)spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst |