Subject: Re: chmod & symlink broken in 1.6
To: Greywolf <email@example.com>
From: Andrew Brown <firstname.lastname@example.org>
Date: 10/30/2002 11:19:57
># 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
i think the phrase that's important is "underlying object pointed at
by name1". the file to which the symlink refers should be the
|-----< "CODE WARRIOR" >-----|
email@example.com * "ah! i see you have the internet
firstname.lastname@example.org (Andrew Brown) that goes *ping*!"
email@example.com * "information is power -- share the wealth."