Prev: ANN: expy 0.6.7 released!
Next: long int computations
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. Mel.
From: Gregory Ewing on 4 May 2010 03:56 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 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.) -- Greg
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). -- Greg
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 > provided. 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 something like: 1. Use getcwd() to find an absolute path for the current directory. 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. -- Greg
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 > link. 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. |