strange interaction between open and cwd
in [Python]
|
Prev: ANN: expy 0.6.7 released!
Next: long int computations
From: Grant Edwards on 3 May 2010 13:41 On 2010-05-03, Baz Walter <bazwal(a)ftml.net> wrote: > i think what i'm asking for is a python function that, given, say, a > valid file descriptor, can return the file's full path. Firstly, a file may have any number of paths (including 0). > would such a thing even be possible? Yes. You have to search the filesystem and compare the descirptor's inode number to that of every file in the filesystem. It will match 0 or more of them. However, that will probably take a long time (many minutes) for a typical "single partition" Unix filesystem. If you have a dedicated filesystem with a small number of files, it may be feasible. -- Grant Edwards grant.b.edwards Yow! !! I am having fun!!! at gmail.com
From: Baz Walter on 3 May 2010 13:45 On 03/05/10 18:12, Grant Edwards wrote: > On 2010-05-03, Baz Walter<bazwal(a)ftml.net> wrote: >>> 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. >> >> yes, that's exactly what i was trying to demonstrate in my OP. i can >> use python to open a file; but under certain circumstances, there >> seems to be no guarantee that i can then use python to locate that >> file in the filesystem. > > Exactly. > > In your example, it's simply not possible to determine the file's > absolute path within the filesystem given the relative path you > provided. > > 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. i think they should always either both succeed, or both fail.
From: Baz Walter on 3 May 2010 13:56 On 03/05/10 18:41, Grant Edwards wrote: > On 2010-05-03, Baz Walter<bazwal(a)ftml.net> wrote: > >> i think what i'm asking for is a python function that, given, say, a >> valid file descriptor, can return the file's full path. > > Firstly, a file may have any number of paths (including 0). yes, of course. i forgot about hard links - that pretty much kills that idea. oh well.
From: Grant Edwards on 3 May 2010 14:12 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? Even though the user provided a legal and openable path? -- Grant Edwards grant.b.edwards Yow! Did I say I was at a sardine? Or a bus??? gmail.com
From: Baz Walter on 3 May 2010 17:57
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. > 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"? |