Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.19/text0027.txt

Internet Message Format | 1990-05-17 | 1.5 KB

From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>

In article <[e-mail]> [e-mail] writes:
>From: [e-mail] (Spencer Garrett)
>I don't know if this is the proper forum in which to discuss this issue,
>but it seems to me that we're about to codify a poor implementation of
>the concept of symbolic links.  IMHO symbolic links shouldn't have
>a format code at all, since they shouldn't be inodes.  They make
>infinitely more sense when treated as directory artifacts - i.e. a
>directory entry either points to an inode or it supplies some more
>path information to be used in resolving the request.  This eliminates
>all the silliness about what permission bits on symbolic link inodes
>mean, for instance.  Here's the directory structure I use in my own OS.

You're to be congratulated on a decent implementation of symlinks.

If symlinks were "perfect", they'd be so transparent that one wouldn't
be able to see them, just as a perfect network file system implementation
would make the networking totally transparent (apart from timing) to
applications.  Your approach comes as close as could be practically
desired.

The whole issue of synonyms in the file system is quite interesting,
and there are some good ideas about this.  Symlinks were an early (and
in my opinion, not very successful) experiment in this area.  It is a
real shame that the standards groups are locking in utterly horrible
implementations of asynchronity, synonyms, networking, and other areas.
I don't know, however, how the juggernaut can be stopped..

Volume-Number: Volume 19, Number 28