Prev: ANN: expy 0.6.7 released!
Next: long int computations
From: Peter Otten on 3 May 2010 09:46 Baz Walter wrote: > attempting to remove the cwd would produce an error). but how can python > determine the parent directory of a directory that no longer exists? My tentative explanation would be that the directory, namely the inode, still exists -- only the entry for it in its parent directory is gone. So "one level up from here" is still a valid operation, but there is no longer a path in the file system associated with "here". Peter
From: Grant Edwards on 3 May 2010 10:22 On 2010-05-03, Peter Otten <__peter__(a)web.de> wrote: > Baz Walter wrote: > >> attempting to remove the cwd would produce an error). but how can >> python determine the parent directory of a directory that no longer >> exists? Python doesn't determine the parent directory. The Unix system call and filesystem code do. The same thing happens in bash. IOW, you can do this: $ rm -rf $PWD; cd .. > My tentative explanation would be that the directory, namely the > inode, still exists -- only the entry for it in its parent directory > is gone. That sounds right. > So "one level up from here" is still a valid operation, but there is > no longer a path in the file system associated with "here". I believe that is the case. -- Grant Edwards grant.b.edwards Yow! -- I have seen the at FUN -- gmail.com
From: Baz Walter on 3 May 2010 10:23 On 03/05/10 14:46, Peter Otten wrote: > Baz Walter wrote: > >> attempting to remove the cwd would produce an error). but how can python >> determine the parent directory of a directory that no longer exists? > > My tentative explanation would be that the directory, namely the inode, > still exists -- only the entry for it in its parent directory is gone. > > So "one level up from here" is still a valid operation, but there is no > longer a path in the file system associated with "here". so "here" must always be available somehow, even if getcwd() fails (something like the environment variable $PWD). shame that os.getenv('PWD') isn't reliable, as it would solve my issue :(
From: Baz Walter on 3 May 2010 10:10 On 03/05/10 14:56, Chris Rebert wrote: >> but how does '..' get resolved in the relative path '../abc.txt'? i'm >> assuming python must initially use getcwd() internally to do this, and then >> if that fails it falls back on something else. but what is that something >> else? is it something that is reproducible in pure python? > > I would think that the OS system call, not Python itself, does the > relative->absolute conversion. so there is a discrepancy between some of the std library path functions (like realpath, getcwd, abspath) and the built-in open function. there are files which can be opened for which it is impossible to resolve their full paths (on some platforms).
From: Grant Edwards on 3 May 2010 10:55
On 2010-05-03, Baz Walter <bazwal(a)ftml.net> wrote: > On 03/05/10 14:56, Chris Rebert wrote: >>> but how does '..' get resolved in the relative path '../abc.txt'? i'm >>> assuming python must initially use getcwd() internally to do this, and then >>> if that fails it falls back on something else. but what is that something >>> else? is it something that is reproducible in pure python? >> >> I would think that the OS system call, not Python itself, does the >> relative->absolute conversion. > > so there is a discrepancy between some of the std library path functions > (like realpath, getcwd, abspath) and the built-in open function. Not really. There is a discrepancy between your perception and expectations and the way the Unix filesystem works. > there are files which can be opened for which it is impossible to > resolve their full paths (on some platforms). Sort of. The file in question _has_ a full path, you just can't tell what it is based on the path you used to open it. -- Grant Edwards grant.b.edwards Yow! I smell a RANCID at CORN DOG! gmail.com |