Re: symbolic links & `..' entry

[Pierre THIERRY]

Scribit Ivan Shmakov dies 10/02/2007 hora 11:55:
> In traditional implementations, the symbolic link is, actaully, a
> special kind of a file, with which a ``string'' is associated.

Yes, but this is not seen by the user application. It's entirely an
abstraction in the FS. That's why there is a need for special operations
that break the abstraction, like lstat().

> > When in a/b, and I ask a link z to ../x, I'm lexically asking my
> > shell to create a link a/b/z to a/x. There is no need for the system
> > to keep track that it was ../x at the time of it's creation, AFAIK.
> Are you suggesting not the string is to be stored on FS?  What else
> then?

I was arguing that when I'm in a/b and do 'ln -s ../x z', I don't care
that I'm really in a/c/d/e because in fact b is a symlink to c/d/e. So
as a user, I don't ask my system to create a link to the file "x in the
directory referenced by '..' in the current directory". As I see in my
prompt the cwd as a/b, I expect ../x to refer to a/x.

> > I'm not really convinced so far by the need of a physical .. entry.
> It's not the physical `..' entry I'm arguing the need for.  I feel,
> that such a ``lexical'' interpretation of `..' would lead to a
> sufficiently different behaviour of the programs, and the consequences
> of that behaviour need to be investigated.

Yet I don't see any use of the physical '..' entry that makes sense.
Some of them just break any expection from the user, like creating a
symlink to anything in ../ when in a symlinked directory (you will in
nearly all cases create a dangling link).

Curiously,
Pierre
-- 
nowhere.man@levallois.eu.org
OpenPGP 0xD9D50D8A

signature.asc
Description: Digital signature