In article ,
Grant Edwards wrote:
>
>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 a
On 06May2010 05:24, Nobody 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
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
On Wed, 05 May 2010 13:23:03 +0100, Baz Walter wrote:
>>> 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 s
On 05May2010 13:23, Baz Walter wrote:
| here's what i get on my system, where '/dev/sda1' and '/dev/sda6'
| are mounted at '/boot' and '/home' respectively:
|
| >>> os.stat('/').st_ino
| 2L
| >>> os.stat('/usr').st_ino
| 212993L
| >>> os.stat('/boot').st_ino
| 2L
| >>> os.stat('/home').st_ino
| 2
On 05/05/10 07:24, Nobody wrote:
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 par
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 s
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
On 04May2010 14:48, Baz Walter wrote:
| On 04/05/10 09:08, Gregory Ewing wrote:
| >Grant Edwards wrote:
| >>except that Python objects can form a generalized graph, and Unix
| >>filesystems are constrained to be a tree.
| >
| >Actually I believe that root is allowed to create arbitrary
| >hard lin
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
On 2010-05-04, Gregory Ewing wrote:
> Grant Edwards wrote:
>
>> except that Python objects can form a generalized graph, and Unix
>> filesystems are constrained to be a tree.
>
> Actually I believe that root is allowed to create arbitrary
> hard links to directories in Unix,
I know that used to b
On Mon, 03 May 2010 06:18:55 -0700, Chris Rebert wrote:
>> but how can python determine the
>> parent directory of a directory that no longer exists?
>
> Whether or not /home/baz/tmp/xxx/ exists, we know from the very structure
> and properties of directory paths that its parent directory is, *by
On 04/05/10 09:08, Gregory Ewing wrote:
Grant Edwards wrote:
except that Python objects can form a generalized graph, and Unix
filesystems are constrained to be a tree.
Actually I believe that root is allowed to create arbitrary
hard links to directories in Unix, so it's possible to turn
the
On Tue, 04 May 2010 20:08:36 +1200, Gregory Ewing wrote:
>> except that Python objects can form a generalized graph, and Unix
>> filesystems are constrained to be a tree.
>
> Actually I believe that root is allowed to create arbitrary hard links to
> directories in Unix, so it's possible to turn
On 04/05/10 09:23, Gregory Ewing wrote:
Grant Edwards wrote:
In your example, it's simply not possible to determine the file's
absolute path within the filesystem given the relative path you
provided.
Actually, I think it *is* theoretically possible to find an
absolute path for the file in th
Baz Walter writes:
> On 04/05/10 02:12, Ben Finney wrote:
> > Baz Walter writes:
> >> yes, of course. i forgot about hard links
> >
> > Rather, you forgot that *every* entry that references a file is a
> > hard link.
>
> i'm not a frequent poster on this list, but i'm aware of it's
> reputation
On 04/05/10 03:19, Grant Edwards wrote:
On 2010-05-03, Baz Walter wrote:
On 03/05/10 19:12, Grant Edwards wrote:
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 meet
On 04/05/10 02:12, Ben Finney wrote:
Baz Walter 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.
i'm not a fr
Grant Edwards wrote:
In your example, it's simply not possible to determine the file's
absolute path within the filesystem given the relative path you
provided.
Actually, I think it *is* theoretically possible to find an
absolute path for the file in this case.
I suspect that what realpath()
Grant Edwards wrote:
except that Python objects can form a generalized graph, and Unix
filesystems are constrained to be a tree.
Actually I believe that root is allowed to create arbitrary
hard links to directories in Unix, so it's possible to turn
the file system in to a general graph. It's h
On 2010-05-04, Cameron Simpson wrote:
> On 03May2010 15:23, Baz Walter 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 digrap
On 2010-05-03, Baz Walter 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 refus
On 03May2010 15:23, Baz Walter 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
Baz Walter 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 f
On 05/04/10 07:57, Baz Walter wrote:
> On 03/05/10 19:12, Grant Edwards wrote:
>> On 2010-05-03, Baz Walter 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
On 03/05/10 19:12, Grant Edwards wrote:
On 2010-05-03, Baz Walter 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) -
On 2010-05-03, Chris Rebert wrote:
>> 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
On 2010-05-03, Baz Walter 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 su
On 03/05/10 19:05, Chris Rebert wrote:
On Mon, May 3, 2010 at 10:45 AM, Baz Walter wrote:
On 03/05/10 18:12, Grant Edwards wrote:
On 2010-05-03, Baz Walterwrote:
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,
On Mon, May 3, 2010 at 10:45 AM, Baz Walter wrote:
> On 03/05/10 18:12, Grant Edwards wrote:
>> On 2010-05-03, Baz Walter 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
On 03/05/10 18:41, Grant Edwards wrote:
On 2010-05-03, Baz Walter 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 h
On 03/05/10 18:12, Grant Edwards wrote:
On 2010-05-03, Baz Walter 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
On 2010-05-03, Baz Walter 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 file
On 03/05/10 15:24, Grant Edwards wrote:
On 2010-05-03, Baz Walter wrote:
On 03/05/10 14:18, Chris Rebert wrote:
Whether or not /home/baz/tmp/xxx/ exists, we know from the very
structure and properties of directory paths that its parent directory
is, *by definition*, /home/baz/tmp/ (just chop o
On 2010-05-03, Baz Walter wrote:
> it's a fact that realpath/abspath/normpath etc can fail for paths
> that don't when used with os.stat or the builtin open function.
True.
> i think it's reasonable to expect that a path that can be used to
> successfully open a file wont then produce "No such
On 03/05/10 15:55, Grant Edwards wrote:
On 2010-05-03, Baz Walter 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 somet
On 2010-05-03, Baz Walter wrote:
>>> (something like the environment variable $PWD). shame that
>>> os.getenv('PWD') isn't reliable, as it would solve my issue :(
>>
>> I don't understand what you mean by that.
>
> i'm trying to understand how the path of the cwd can be known if there
> is no en
On 03/05/10 15:56, Grant Edwards wrote:
On 2010-05-03, Baz Walter 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 explan
On 2010-05-03, Baz Walter 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 di
On 2010-05-03, Baz Walter 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 so
Baz Walter wrote:
On 03/05/10 14:18, Chris Rebert wrote:
Whether or not /home/baz/tmp/xxx/ exists, we know from the very
structure and properties of directory paths that its parent directory
is, *by definition*, /home/baz/tmp/ (just chop off everything after
the second-to-last slash). I would as
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 reproduc
On 2010-05-03, Baz Walter wrote:
> On 03/05/10 14:18, Chris Rebert wrote:
>> Whether or not /home/baz/tmp/xxx/ exists, we know from the very
>> structure and properties of directory paths that its parent directory
>> is, *by definition*, /home/baz/tmp/ (just chop off everything after
>> the second
On 2010-05-03, Peter Otten <__pete...@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
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 th
On Mon, May 3, 2010 at 6:49 AM, Baz Walter wrote:
> On 03/05/10 14:18, Chris Rebert wrote:
>> Whether or not /home/baz/tmp/xxx/ exists, we know from the very
>> structure and properties of directory paths that its parent directory
>> is, *by definition*, /home/baz/tmp/ (just chop off everything af
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 director
On 03/05/10 14:18, Chris Rebert wrote:
Whether or not /home/baz/tmp/xxx/ exists, we know from the very
structure and properties of directory paths that its parent directory
is, *by definition*, /home/baz/tmp/ (just chop off everything after
the second-to-last slash). I would assume this is what h
On Mon, May 3, 2010 at 5:42 AM, Baz Walter wrote:
> Python 2.6.4 (r264:75706, Mar 7 2010, 02:18:40)
> [GCC 4.4.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
import os
os.mkdir('/home/baz/tmp/xxx')
f = open('/home/baz/tmp/abc.txt', 'w')
f
49 matches
Mail list logo
