SGI symlink bug?

[Viktor Dukhovni]

vjs at rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>Do I understand correctly that you feel it would be better if `ln -s foo bar`
>would never succeed if "bar" exists?

	Seems a good idea.
...

>I think the reason our `ln -s for bar` kills the target is because `ln foo
>bar` and `mv foo bar` are always effective in the SVR3 world.  It seems to
>me that `ln` and `ln -s` should be as identical as possible, except in the
>nature of the link they make.  It would be bad if `ln foo bar` would
>succeed where `ln -s foo bar` would fail.
	
	It is the behaviour of "ln" that seems wrong!  Note the
corresponding system call ln(2) will fail with EEXIST.  "ln" must take
special precaution to unlink the target before making the link,  this
is unnatural.

	In the case of "mv" (rename at the system level) at least the
destructive behaviour is identical for the C and shell programmers.
Seems we have a "historical" mess on our hands.

>A convincing argument for changing or not changing the IRIX "ln" would be
>an appeal to authority, in the form of POSIX or SVR[34]-SVID chapter and
>verse.  As far as I can see, the current IRIX way is least wrong.  What's
>more, changing `ln -s` to require that the target not exist would probably
>break a zillion scripts and cause a jillion people to complain bitterly and
>loudly.


	Yes a standard would be nice,  even if they decide by tossing
coins!  Though uniform conformance to one of the BSD or SYSV behaviours
would be nice.
--
	Viktor Dukhovni <viktor at math.princeton.edu>	: ARPA
		<...!uunet!princeton!math!viktor>	: UUCP
	Fine Hall, Washington Rd., Princeton, NJ 08544  : US-Post
		+1-(609)-258-5792		 	: VOICE