[KLUG Advocacy] Symlinks and ideas vs. implementation

[Robert G. Brown]

On Wed, 28 Jan 2004 04:45:30 -0500, Peter Buxton wrote:

>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!

Objectively all this tells me is that you don't use symlinks, and others
(systems developers and distributors) do. I kinda figured that out from 
you anti-symlink bias.

>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.) 
Oh? show us 3.

>    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.
A Kluge, I'll agree.

>   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.
If someone came along and told me I had to come up with a reliable, stable
and flexible way (oh, and portable, too) to do this, I would NEVER think 
of doing it the ways it's widely implemented, which is IMO a bit fragile.

Probably it is written the way it is out of someone's personal choice, and
we both would not have made that choice. I would have written something that
holds the name (or the TEXT) of each startup and shutdown script, and then
a list of scripts to be run for each runlevel. I'd probably do this in a 
database, and every time the DB is modified, I'd regenerate any of the 
scripts effected by the change.

I'll also wager that few if any of the tools needed to do this right existed
(or existed pervasively accross platforms, which amonts to the same thing) at
the time runlevels were implemented. Time to revist? Maybe! Bigger fish to fry?
Probably!

>   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.
Sure, but handled in my scheme, and the current one (with some contortions).
Example of fragility: The current system depends on the collating sequence of 
the underlying character set... if we altered that (think Katakana, Cyrillic,
or Hebrew) perhaps (as I've listed) to character sets that don't have "K" or
"S" in the same places (or reverse the ranking, or DON'T have those characters)
.... hmm... in a real UNICODE world this wold not be a problem..of course, I'm
writing this message in English, not Esperanto....

>   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.
Agreed.

>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.
Oh, this one, as the formal grammarian types might say, really sucks wind and
blows chunks. It's REALLY context and circumstance-dependedent, and most people
find it hard to read. Stuff like this forms a nice base for mistakes, too.

>   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).
I think I agree.

>   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.

Traditionally, the only really good cure I've seen for this is DOCUMENTATION.
Yes, I'm shouting it. In several shops in which I was high in the food chain,
People who wrote makefiles that modified symlinks, or were somehow dependent
on particular symlinks, but FAILED to document this in at least the makefile
and the formal system docs... well, they got smaller bonuses at the end of
the year, their names were spoken with a snicker, and they just weren't
allowed to have as much fun at the Christmas party....

>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.
What tool[s] would you propose for breaking up shortcuts? 
What tool[s] do we have now for breaking symlinks?

>5. This is interesting. Of course, this second-class implementation
>   leads to #4 as well.
Oh? please elaborate.

>> 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.
They probably got the best thing they could at the time.

>Symbolic links were first seen in 4.2BSD, UFS. Uh-huh.
Thanks, the assimilation process has begun...

>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. ;-)
The history is on paper tape, or they talk about UNIX on paper tape??
Oh, it's NASA, probably the latter! :)

							Regards,
							---> RGB <---