[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: symbolic links & `..' entry
From: |
Ivan Shmakov |
Subject: |
Re: symbolic links & `..' entry |
Date: |
10 Feb 2007 11:55:11 +0600 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
>>>>> "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.
- Re: Hurd and Unix/Linux and Plan9 features, (continued)
- Re: Hurd and Unix/Linux and Plan9 features, olafBuddenhagen, 2007/02/03
- Re: Hurd and Unix/Linux and Plan9 features, Ivan Shmakov, 2007/02/04
- Re: Hurd and Unix/Linux and Plan9 features, Shams, 2007/02/04
- Re: Hurd and Unix/Linux and Plan9 features, Pierre THIERRY, 2007/02/06
- Re: Hurd and Unix/Linux and Plan9 features, Ivan Shmakov, 2007/02/07
- Re: Hurd and Unix/Linux and Plan9 features, Pierre THIERRY, 2007/02/07
- symbolic links & `..' entry, Ivan Shmakov, 2007/02/08
- Re: symbolic links & `..' entry, Pierre THIERRY, 2007/02/08
- Re: symbolic links & `..' entry,
Ivan Shmakov <=
- Re: symbolic links & `..' entry, Thomas Bushnell BSG, 2007/02/10
- Re: symbolic links & `..' entry, Pierre THIERRY, 2007/02/11
Re: Hurd and Unix/Linux and Plan9 features, Pierre THIERRY, 2007/02/03
Re: Hurd and Unix/Linux and Plan9 features, olafBuddenhagen, 2007/02/03