From: Mel on 3 May 2010 23:34
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
allocation. CP/M, and (IIRC) the GE/Honeywell mainframe systems I used to
work with. MS-DOS FAT filesystems might have supported multi-names but
refused to administer them before long filenames were implemented as special
cases. I first ran into multi-names on Multics, where the Volume Table of
Contents controlled disk space allocation and directories provided name-
keyed access to the VTOC entries. Pretty much as Linux does now with
directories and inodes.
From: Gregory Ewing on 4 May 2010 03:56
> In the OP's case, references to the directory have been removed from the
> system, but his process still has the current working directory reference to
> so it has not actually been deleted. When he opens "../abc.txt", the OS
> the current directory for ".." and finds the inode for /home/baz/tmp,
This doesn't seem to be quite correct. An experiment I just did
reveals that the link count on the parent directory goes down by
one when the current directory is deleted, suggesting that the ..
link has actually been removed... yet it still works!
I think what must be happening is that the kernel is maintaining
an in-memory reference to the parent directory, and treating ".."
as a special case when looking up a name.
(This probably shouldn't be too surprising, because ".." is special
in another way as well -- at the root of a mounted file system, it
leads to the parent of the mount point, even though the actual ".."
link on disk just points back to the same directory. Probably it
simplifies the name lookup logic to always treat it specially.)
From: Gregory Ewing on 4 May 2010 04:08
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 highly
unrecommended, though, because it confuses the heck out of
programs that recursively traverse directories (which is
why only root is allowed to do it).
From: Gregory Ewing on 4 May 2010 04:23
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
Actually, I think it *is* theoretically possible to find an
absolute path for the file in this case.
I suspect that what realpath() is doing for a relative path is
1. Use getcwd() to find an absolute path for the current
2. Chop off a trailing pathname component for each ".."
on the front of the original path.
3. Tack the filename on the end of what's left.
Step 1 fails because the current directory no longer has
an absolute pathname -- specifically, it has no name in
what used to be its parent directory.
What realpath() is failing to realise is that it doesn't
actually need to know the full path of the current directory,
only of its parent directory, which is still reachable via
".." (if it weren't, the file wouldn't be reachable either,
and we wouldn't be having this discussion).
A smarter version of realpath() wouldn't try to find the
path of the *current* directory, but would follow the
".." links until it got to a directory that it did need to
know an absolute path for, and start with that.
Unfortunately, there is no C stdlib routine that does the
equivalent of getcwd() for an arbitrary directory, so
this would require realpath() to duplicate much of
getcwd()'s functionality, which is probably why it's
done the way it is.
From: Baz Walter on 4 May 2010 08:53
On 04/05/10 02:12, Ben Finney wrote:
> 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
i'm not a frequent poster on this list, but i'm aware of it's reputation
for pointless pedantry ;-)
but what the heck, when in rome...
note that i said hard links (plural) - i think a more generous reader
would assume i was referring to additional hard links.