dricej@drilex.UUCP (Craig Jackson) (09/07/87)
Isn't the real problem not the implementation of symbolic links, but the
implementation of links in general? Building a directory structure with
links is a powerful concept, but its implementation has been growing hacks
for years. The symbolic link seems to me to be used mostly to get around
these hacks.
People have talked of the tree-structured Unix file system, and how symbolic
links violate that. However, links themselves do not create a tree, but
rather a directed graph. The tree structure arose when people first tried
to write fsck-like programs. At that time, links to directories (other than
'.' and '..') were prohibited. (Correct me on my history, but I believe that
this was in the Version 5 or Version 6 timeframes.)
Later, mountable file systems were invented. This cause yet another breakage
of the link concept, as linking across file systems was not defined. This
gave rise to an 'mv' command that sometimes means 'rename' and sometimes means
'copy and remove the original' (if it did things correctly). However,
mountable file systems did allow Unix to access multiple disk drives.
Unfortunately, their implementation forced a one-directory-tree-per-filesystem
rule, which is no good for breaking up a large directory.
Symbolic links seem to be used for several things:
1. Links to directories, in violation of the one-link-to-directory rule.
(This is what has started the controversy.)
2. Links across file systems. This is especially common in the NFS world;
it can also be used to get by the one-directory-tree-per-filesystem limitation.
3. Truly 'symbolic' links. These are the cases where you wish to point
to a file of a given name, no matter which inode that directory entry points
to. I'm sure these cases exist; I can't think of one right now.
There is also the usage of symbolic links with '..' in the value; I don't
quite understand the semantics of that case, so I'll leave it alone.
I think that the symbolic link semantics vs 'cd' should be examined in the
context of generalized links: What would 'cd ..' mean if the one-link-per-
directory rule were relaxed? More importantly, what would you want it to
mean? The conventional meaning would probably be, "'..' points to the
inode of the first parent" and that cd '..' would go towards that directory.
However, what you probably want is "get me out of here the way I came".
Therefore, the present argument about symbolic links would arise in this
expanded hard-link environment, as well.
I suggest that the realization of '.' and '..' as physical directory entries
is an elegant artifice, but an artifice nonetheless. It is suitable only
under the restrictions which were present at the time, particularly
the one-link-per-directory restriction. I see no real reason why '.' and '..'
must be realized this way, and indeed vendors such as HP have done it
differently. If these strings were not realized as physical directory
entries, some of the semantic walls which we face would be removed. I believe
that in such an environment, the meaning of 'cd ..' as 'go back the way I came
would be most natural.
I hope this analysis will help this discussion move along. If I have gotten
the details of the early versions of Unix wrong, I apologise. If you think
what I say is heresy, so be it.
--
Craig Jackson
UUCP: {harvard!axiom,linus!axiom,ll-xn}!drilex!dricej
BIX: cjackson