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 04/05/10 03:25, Grant Edwards wrote:
On 2010-05-04, Charles wrote:
I don't see how it's inelegant at all. Perhaps it's
counter-intuitive if you don't understand how a Unix filesystem
works, but the underlying filesystem model is very simple, regular,
and elegant.
but probably makes some
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
On Tue, 04 May 2010 23:02:29 +1000, Charles wrote:
> I am by no means an expert in this area, but what I think happens (and I
> may well be wrong) is that the directory is deleted on the file system.
> The link from the parent is removed, and the parent's link count is
> decremented, as you observ
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
"Gregory Ewing" wrote in message
news:84a1mcffn...@mid.individual.net...
> Charles wrote:
>
>> In the OP's case, references to the directory have been removed
>> from the file system, but his process still has the current working
>> directory reference to it, so it has not actually been deleted.
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
Charles wrote:
In the OP's case, references to the directory have been removed from the
file
system, but his process still has the current working directory reference to
it,
so it has not actually been deleted. When he opens "../abc.txt", the OS
searches
the current directory for ".." and fin
Grant Edwards wrote:
> I guess I've been using Unix for too long (almost 30 years). I don't
> think I was consciously aware of a "one file, one name" paradigm. Is
> that a characteristic of Dos, Windows or Mac filesystems?
Older and simpler filesystems used to combine the naming with the space
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-04, Charles wrote:
>> I don't see how it's inelegant at all. Perhaps it's
>> counter-intuitive if you don't understand how a Unix filesystem
>> works, but the underlying filesystem model is very simple, regular,
>> and elegant.
>>
>>> but probably makes some bit of the OS's job slight
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
"Grant Edwards" wrote in message
news:hrn3qn$nh...@reader1.panix.com...
> 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 t
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
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.write('abc')
>>> f.close()
>>> os.chdir('/home/baz/tmp/xxx'
57 matches
Mail list logo
