Thoughts on Symbolic Links

I enjoyed my reading of ``The UNIX-HATERS Handbook'', and one note on symbolic links stuck out to me
even as I struggled to find the particular passage again.  Symbolic links pointing at leaf nodes, at
individual files, are simpler to consider compared to those pointing at other nodes, at directories.

I failed to find a contrast with Multics' handling of symbolic links in the book, and my reading the
Multicians website failed to answer my greatest question also: I'd forgotten how each system handled
accessing the parent directory from a symbolically-linked directory, and decided to reason my way to
both answers, the correct I believed to be attributed to Multics and that wrong implemented in UNIX.

The parent of a symbolically-linked directory is either that parent of the directory linked, or that
of the directory linking; no alternation from these two choices makes sense.  Either choice has good
reason to be present, however, and both have uses.  I realized the former choice to be most sensible
for the simple reason that it's a matter of meaning whereas the latter is one of form: The parent of
a symbolically-linked directory should be the parent of the linked directory, because this needs the
information held in the link, whereas the directory holding the symbolic link can be got with a mere
syntactical manipulation of the path; the former needs system support whereas the latter needs none.

Unsurprisingly, I found the passage, and UNIX implements the wrong of the two: The special directory
named ``..'' specifies a directory's parent and simply sheds the symbolic link from the path, unless
one opens the path named ``./..''  instead.  I observed not this behaviour with my GNU/Linux system.

In general, that which requires more work of the implementor should be chosen, which is the opposite
of UNIX's attitude; I've not verified which of the two choices Multics makes, but I've a good guess.

In mulling over this question, I noticed no one should care about symbolic links whatsoever.  A user
only cares to refer to a file by more than one name, and the mechanism is irrelevant.  Indirection's
quite a fun topic to consider.  In mulling over the buffer narrowing mechanism of GNU Emacs, I found
normal and narrowed buffers to be almost identical in Object-Oriented terms; narrowed buffers merely
respond to an additional interface revealing the indirection, making them perfectly identical except
to code which knows for what to look.  Symbolic links can be considered similarly, but they make the
tree a graph, thus fundamentally altering the assumptions that can be made, and so can't be ignored.

I think so-called ``hard links'' which link more deeply to files to be uninteresting in this matter.
.