Re: symbolic links & `..' entry

[Ivan Shmakov]

>>>>> "PT" == Pierre THIERRY <nowhere.man@levallois.eu.org> writes:

 IS> Now, $ ls z/ will show us `y', just as expected.  Would `..' be
 IS> interpreted lexically, it would break the things,

 PT> But you're talking about a symlink, which is precisly an
 PT> abstraction in the FS. That is, the application doesn't know it's
 PT> accessing a symlink, so there's to interpretation of .. at all.

        In traditional implementations, the symbolic link is, actaully,
        a special kind of a file, with which a ``string'' is associated.
        The ``string'' is used to do a text substritution on the
        original file name, e. g., if file name is `/a/b/c', and `b'
        leads to `d/e', then it's `s,a/b,a/d/e,' => `/a/d/e/c' to be
        used.  (The process continues recursively untill no symbolic
        links in the name are left.)  Note, that the ``string'' is
        available to the application via readlink ().

        Should symbolic links be implemented in traditional way, it
        would be up to translator to readlink () and to interpret that
        string.

 PT> When in a/b, and I ask a link z to ../x, I'm lexically asking my
 PT> shell to create a link a/b/z to a/x. There is no need for the
 PT> system to keep track that it was ../x at the time of it's creation,
 PT> AFAIK.

        Are you suggesting not the string is to be stored on FS?  What
        else then?

        If, e. g., it will be some ``direct'' reference to the file to
        be stored (like device, inode pair), it would be, indeed, the
        hard link.  One of the uses of the symbolic links is to create
        ``shortcut'' to some well-known location:

$ ln -s /well/known/location shortcut

        Keeping the inode (and not the string) associated with the
        symbolic link leaves no way to the user to create such a
        ``shortcut'', since the following will redirect the link to a
        different file (or, the file would be the same, but the file
        name the link refers to would be changed):

$ mv /well/known/location /well/known/location.old
$ mkanything /well/known/location
$ 

        (And the problems with cross-device links will arise as well.)

        Furthermore, some applications use symbolic links in rather
        unusual ways.  E. g., Emacs uses symbolic links for file locks
        -- to store the identity of the user currently editing the file.
        This, however, is easy (in idea, not in implementation) to
        resolve: in Hurd, one might want to implement some new interface
        rather than working with the old one such an unclear way.

 IS> I guess, there could be some examples related to the use of GNU
 IS> Arch, since it depends on ascending directory tree recursively to
 IS> get access to its control files, `{arch}/'.

 PT> Would you really set up file links in a version controlled
 PT> directory hierarchy in a way that lexical directory ascending
 PT> wouldn't make it to the root of the working copy?

        Why not?  If I, e. g., need a part of the tree in some different
        place for my own convenience?  Doing `tla update' from that
        place wouldn't be of primary importance, but nevertheless still.

 IS> ... Doesn't it look like both interpretations could be useful?

 PT> 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.