strange interaction between open and cwd
in [Python]
|
Prev: ANN: expy 0.6.7 released!
Next: long int computations
From: Lie Ryan on 3 May 2010 19:39 On 05/04/10 07:57, Baz Walter wrote: > On 03/05/10 19:12, Grant Edwards wrote: >> On 2010-05-03, Baz Walter<bazwal(a)ftml.net> wrote: >> >>>> You requested something that wasn't possible. It failed. What do >>>> you think should have happened? >>> >>> path = '../abc.txt' >>> >>> os.path.realpath(path) -> "OSError: [Errno 2] No such file or >>> directory" >>> >>> therefore: >>> >>> open(path) -> "IOError: [Errno 2] No such file or directory" >>> >>> i think that if the first of these seemingly "impossible" requests >>> fails, it is reasonable to expect that the second one also fails. but >>> the second one (sometimes) doesn't. >> >> Because the second one isn't impossible in the case you posted. >> >>> i think they should always either both succeed, or both fail. >> >> That's not how Unix filesystems work. >> >> Are you saying that Python should add code to it's open() builtin >> which calls realpath() and then refuses to open files for which >> realpath() fails? > > my original question was really about *how* python does the "seemingly > impossible". i had hoped there might be a way to augment realpath so > that it would always work for any path which is openable. but apparently > that is not possible for unix filesystems. It's the OS that does the "seemingly impossible" things. Python only makes the relevant system call with the string you've given, and leaves the rest of the magic of resolving the real file to open, opening the filename, moving the harddrive head, etc to OS kernel. If OS kernel dictates that you can open a file that have no actual path; then Python will do so. >> Even though the user provided a legal and openable path? > > that sounds like an operational definition to me: what's the difference > between "legal" and "openable"?
From: Ben Finney on 3 May 2010 21:12 Baz Walter <bazwal(a)ftml.net> writes: > On 03/05/10 18:41, Grant Edwards wrote: > > Firstly, a file may have any number of paths (including 0). > > yes, of course. i forgot about hard links Rather, you forgot that *every* entry that references a file is a hard link. To ask for a filesystem entry referencing the file contents *is* to ask for a hard link; and there can be zero or more of those. The case where there is exactly one of those for a given file is the special case, and should not be assumed. -- \ “[Freedom of speech] isn't something somebody else gives you. | `\ That's something you give to yourself.” —_Hocus Pocus_, Kurt | _o__) Vonnegut | Ben Finney
From: Cameron Simpson on 3 May 2010 21:36 On 03May2010 15:23, Baz Walter <bazwal(a)ftml.net> wrote: | 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 Well, yeah. Just like an open file handle on a file you have subsequently removed still exists. Remember that the directory tree is a digraph, and (historically at least, and probably for real in many filesystems) '.' and '..' are just pointers to "here" and "up". Your rmdir has detached the current directory from the one that was "up", but the "up" pointer still references the old parent. There's just no filesystem path that refers to your current directory any more (except '.'). Just like a detached object in python really. Cheers, -- Cameron Simpson <cs(a)zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ Everything that can be invented has been invented. - Charles H. Duell, Commissioner, U.S. Office of Patents, 1899.
From: Grant Edwards on 3 May 2010 22:19 On 2010-05-03, Baz Walter <bazwal(a)ftml.net> wrote: > On 03/05/10 19:12, Grant Edwards wrote: >>> i think they should always either both succeed, or both fail. >> >> That's not how Unix filesystems work. >> >> Are you saying that Python should add code to it's open() builtin >> which calls realpath() and then refuses to open files for which >> realpath() fails? > > my original question was really about *how* python does the > "seemingly impossible". i had hoped there might be a way to augment > realpath so that it would always work for any path which is openable. > but apparently that is not possible for unix filesystems. Exactly >> Even though the user provided a legal and openable path? > > that sounds like an operational definition to me: what's the > difference between "legal" and "openable"? Legal as in meets the syntactic requirements for a path (not sure if there really are any requirements other than it being a null-terminated string). Openable meaning that it denotes a path file that exists and for which the caller has read permissions on the file and execute premissions on the directories within the path. -- Grant
From: Grant Edwards on 3 May 2010 22:36
On 2010-05-04, Cameron Simpson <cs(a)zip.com.au> wrote: > On 03May2010 15:23, Baz Walter <bazwal(a)ftml.net> wrote: >| so "here" must always be available somehow, even if getcwd() fails > > Well, yeah. Just like an open file handle on a file you have > subsequently removed still exists. Remember that the directory tree > is a digraph, and (historically at least, and probably for real in > many filesystems) '.' and '..' are just pointers to "here" and "up". > > Your rmdir has detached the current directory from the one that was > "up", but the "up" pointer still references the old parent. > > There's just no filesystem path that refers to your current directory > any more (except '.'). Just like a detached object in python really. Indeed. In fact, CPython uses a pointer/link and reference counting scheme that's pretty much identical to that used by Unix filesystems except that Python objects can form a generalized graph, and Unix filesystems are constrained to be a tree. Though once upon a time SunOS allowed you to create arbitrary graphs within a filesystem by allowing you to create hard links to directories. You had to be root, and you had to use some sort of override option on the command line (probably -f). If you knew enough to gracefully extract yourself from the situation, you probably wouldn't have done it in the first place. IOW, it wasn't something one did a second time. 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... -- Grant |