[KLUG Advocacy] Symlinks and ideas vs. implementation

[Peter Buxton]

On Wed, Jan 28, 2004 at 01:16:51AM -0500, Robert G. Brown was only escaped
   alone to tell thee:

> > ObRant: When Alan Cox was busy on that kernel for ludicrously under-
> > powered machines (FOLKS, right?), he was surprised to note that the
> > code to implement symlinks roughly doubled the size of the generic
> > FS code. A sure sign that symlinks are a Bad Thing (but not the only
> > one).
> 
> Interesting observation!
> 
> Was "the code" pre-exisiting. or written just before he noted this?

It was standard Linux code being adapted to the 286.

> I'd like to see the other reasons why symlinks are a "Bad Things". I've
> always sort of accepted them as part of UNIX file systems, but haven't 
> really thought aboutthem as Good or Bad, but rather Expedient. They have
> proved useful, but not as I can recall in ways that hard links would NOT
> have been.

According to symlinks(1) and wc(1), I have 4,147 symbolic links in 8.7
gigabytes of files. 5.6 of those gigs are in my home directory; NONE of
the symlinks are! And that doesn't count the 2.4 and 2.6 kernels (0.5
gigs), which are not in my home dir -- and which have no symlinks
themselves!

What do symlinks do that hard links do not?

1. Point to directories
2. Create directory loops
3. Work across filesystems
4. Break
5. Self-indicated as secondary links

1. I've never seen a directory redirect worth keeping. (I have used
   symlinked dirs to save typing while moving files. I have since
   realized that dozens of easier methods exist to do this trick.) Most
   'permanent' instances are for programs that need work on their
   Makefiles; i.e., they are set to compile to a non-standard (or
   non-linux) fs heirarchy and someone 'fixes' it with a symlink because
   the hacker hardcoded directories in his or her code.

   Sysvinit: The more I look at /etc/rc.? the more I hate it. BSD still
   uses rc.conf, a single file that runs the system daemons. (It's been
   a while since I've been on BSD.) Single files written to by multiple
   programs are fragile. Another way of doing it would be to code each
   sysvinit-like code with a name like 05-0200_samba, where 05 is the
   runlevel and 0200 is the runlevel order. Then you just use a
   runparts-like script/program to read the init.d dir, order the files
   and execute them. Shutdown is the same, backwards.

   What if startup and shutdown are not mirror images of each other;
   what if PROGA needs to start before PROGB but shutdown after it? You
   could write a small script to check 'tickfiles' that indicate whether
   another init.d script is up or down. Richard Gooch suggested using a
   Depends-like line in a script. Samba, say, would depend on fsall,
   which depends on fslocal and fsremote.

   That so many ways exist to do what sysvinit does now suggests to me
   that many other symlink-less options exist that may be just as, if
   not more featureful than sysvinit.

2. A lot of programs using directory recursion are required to code
   against directory loops. The addition of symlinks created this
   serious problem. With only hard links, each file and directory has
   only one parent in a strict heirarchy.

   ln -s ../../home test
   cd test
   pwd

   I get '/var/home/peter/test', not '/var/home'. Bad.  Real shortcuts
   would be better. Using real shortcuts means, after `cd test`, pwd
   returns the true directory, not a fake symlink path.  Programs
   looking for directory paths wouldn't see the shortcuts as dirs but
   only as shortcuts for the mnemonically-challenged (i.e., humans).

   Another use for redirected dirs is when things get shuffled about.
   Again, shortcuts would be better as you wouldn't be redirected to a
   soon-to-be-obsolescent symlink. The change would be noticeable.

3. The suggested shortcuts would work across filesystems. If hardlinks
   could point to UUIDs, so could they.

4. I can't think of anything more important to say about this. If you
   *need* breaking symlinks, shortcuts would, uh, not work as well.

5. This is interesting. Of course, this second-class implementation
   leads to #4 as well.

> Let's not confuse a Good Idea with a Bad Implementation.

I think someone wanted shortcuts, but they wanted magic shortcuts that
would never "break". Well, they got 'em.


Symbolic links were first seen in 4.2BSD, UFS. Uh-huh.

Interesting reading:

http://c2.com/cgi/wiki?SymbolicLink

http://lists.nas.nasa.gov/archives/ext/linux-security-audit/1999/05/msg00087.html

(Interesting history of Unix on paper tape. ;-)

-- 
What women and psychologists call 'dropping
your armor,' we call 'baring our neck.'