># ah, good point.  yes, to make a hardlink to a symlink when the
># location of the new link might not work would be pointless.  link(2)
># should, therefore, traverse the symlink.
>
>...to what end?  Don't you think that kind of special-cases symlinks?
>[Never mind that symlinks *are* a "special case"...]

that's funny...i thought that by making link(2) traverse the symlink,
it would be less of a special case and more like everything else.

>If I do:
>
>	...
>	(void) close(open("/var/tmp/file",O_CREAT|O_TRUNC|O_RDWR,0644));
>	(void) symlink("/var/tmp/file", "/var/tmp/symlink");
>	(void) link("/var/tmp/symlink","/var/tmp/linktosymlink");
>
>Then barring any problems with creation during that sequence (which I'm
>aware I'm ignoring because of course there won't be any ;) ), I should
>end up with (assuming a umask of 022):
>
>49 -rw-r--r--  1 root      wheel          0 [curtime] file
>50 lrwxr-xr-x  2 root      wheel         13 [curtime] symlink -> /var/tmp/file
>50 lrwxr-xr-x  2 root      wheel         13 [curtime] linktosymlink -> /var/tmp/file
>
>Indeed, this is precisely the projected, expected and verified result.

yes, the "projected, expected and verified result" for a *4.4bsd
derived system*.  on anything else, the last call to link(2) will
create a link to the file, not a link to the symlink.  symlinks are
less like first class citizens everywhere else.

>If link(2) starts traversing symlinks, I'm going to get a little worried.
>Besides, what if the symlink points off-device?

then the link call fails, just as it always does.  nothing new there.

># >If you want a hard link to an actual file, readlink()/link() becomes
># >the way to go.
>#
># to a point, yes.
>
>Well, I don't see much of an alternate.  link(2) was never designed with
>follow semantics in mind.  It does a very simple operation:
>
>	- adds a directory entry with the inum of the original
>	- increments the link count on the inode

symlink was also designed with simple operations in mind.  it provides
a facility for you to create a second name by which a file may be
known, such that all the normal operations:

	open(2)		will open the original file
	unlink(2)	will remove the name for that file
	stat(2)		will describe the original file
	chmod(2)	will change the original file
	utimes(2)	will affect the original file
	etc

making symlinks more like first class files is a design difference.

>[with locking, filesystem semantics, space and access checks, of course]
>
>Making link(2) traverse the link is, I believe, "broken".

gee...that's strange.  that's the way that *every other unix system
does it*.

>The other system calls traversing make a modicum of sense; however,
>I believe the extensions for symperm allow for some very clever
>filesystem manipulations!

clever, perhaps.  fascinating, even.  but you can't call them the
"most correct and only way to do things".

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