Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!ogicse!emory!mephisto!udel!princeton!idunno!cucumber.princeton.edu!viktor From: viktor@cucumber.princeton.edu (Viktor Dukhovni) Newsgroups: comp.sys.sgi Subject: Re: SGI symlink bug? Message-ID: <900@idunno.Princeton.EDU> Date: 14 Jun 90 21:53:11 GMT References: <9006140634.aa20043@WOLF.BRL.MIL> <62256@sgi.sgi.com> Sender: news@idunno.Princeton.EDU Lines: 39 vjs@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 : ARPA <...!uunet!princeton!math!viktor> : UUCP Fine Hall, Washington Rd., Princeton, NJ 08544 : US-Post +1-(609)-258-5792 : VOICE