From: Peter Otten on
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
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
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
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
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
 |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: ANN: expy 0.6.7 released!
Next: long int computations