># gee...that's strange.  that's the way that *every other unix system
># does it*.
>
>Mea culpa -- I don't have an *every other unix system* to check on;
>I naturally assumed we were relatively compliant with said other systems.

well, i'll admit to not having "every other unix system" to check, but
based on the experience i've accumulated over the years, i feel i can
authoritatively say that the way 4.4bsd derived systems deal with
symlinks is a "little different".

>I'm actually surprised that other unices handle link(2) differently
>considering what link(2) describes itself to do.

personally, i think that the way in which our link(2) operates is
wrong.  it used to be different.  for example, in the antiquated 1.3H
machine that i still have lying around, we end up (after the series of
three operations you listed) with the following:

-rw-r--r--  2 andrew  wheel   0 Oct 30 11:17 /var/tmp/file
-rw-r--r--  2 andrew  wheel   0 Oct 30 11:17 /var/tmp/linktosymlink
lrwxr-xr-x  1 andrew  wheel  13 Oct 30 11:17 /var/tmp/symlink@ -> /var/tmp/file

there's a sentence at the top of the link(2) man page that states:

     The link() function call atomically creates the specified directory entry
     (hard link) name2 with the attributes of the underlying object pointed at
     by name1.

i think the phrase that's important is "underlying object pointed at
by name1".  the file to which the symlink refers should be the
"underlying object".

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."