mike@BRL.MIL (Mike Muuss) (06/14/90)
In the past two days, I have accidentally blown away two files of mine due to (a) my inate dyslexia w.r.t the arguments to "ln -s", and (b) a difference in behavior of "ln -s" on BSD machines -vs- an SGI. Here is a command sequence taken from a Gould PN 9080 running UTX/2.0, a 4.2 BSD system: 15 spark> echo > foo 16 spark> ls -l foo -rw-rw-r-- 1 mike 0 Jun 14 06:28 foo 17 spark> ln -s /tmp foo foo: File exists 18 spark> ls -l foo -rw-rw-r-- 1 mike 0 Jun 14 06:28 foo 19 spark> Here is the same command sequence tried on an SGI Predator 4D/280 running IRIX 3.2.2: 1 wolf> echo > foo 2 wolf> ls -l foo -rw-rw-r-- 1 mike graphics 0 Jun 14 06:28 foo 3 wolf> ln -s /tmp foo 4 wolf> ls -l foo l--------- 1 mike graphics 4 Jun 14 06:28 foo -> /tmp 5 wolf> If it would not be too much trouble, I'd like to ask the SGI folks to duplicate the "foo: File exists" behavior, if it isn't too hard. Best, -Mike
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") (06/14/90)
I whole heartedly agree. Doing a symbolic link over an existing file should not be allowed. Some systems I have used give an error like file exists others don't give any error, but still don't try to do the link. -- Brent L. Bates NASA-Langley Research Center M.S. 361 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (06/14/90)
In article <9006140634.aa20043@WOLF.BRL.MIL>, mike@BRL.MIL (Mike Muuss) writes: > > ...[`ln` command sequence]... Do I understand correctly that you feel it would be better if `ln -s foo bar` would never succeed if "bar" exists? Because of the dangers of my typing, I alias "ln" to "ln -i". I do the same for rm and mv. (In the pure SVR3 world, there is no notion of `ln -i` or `mv -i`.) 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. 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. Vernon Schryver, vjs@sgi.com
krk@cs.purdue.EDU (Kevin Kuehl) (06/15/90)
In article <62256@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >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. I agree with Vernon. Although I think `ln -s for bar' should not write over bar (I grew up in a BSD world), all of the SVR3 machines I tried blew `bar' away. Since more of the world seems to be going SVR3 or SVR4 everyday, I would rather IRIX was consistent with them. Just my opinion, Kevin krk@cs.purdue.edu ..!{decwrl,gatech,ucbvax}!purdue!krk
viktor@cucumber.princeton.edu (Viktor Dukhovni) (06/15/90)
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 <viktor@math.princeton.edu> : ARPA <...!uunet!princeton!math!viktor> : UUCP Fine Hall, Washington Rd., Princeton, NJ 08544 : US-Post +1-(609)-258-5792 : VOICE
rpw3@rigden.wpd.sgi.com (Rob Warnock) (06/15/90)
In article <900@idunno.Princeton.EDU> viktor@cucumber.princeton.edu (Viktor Dukhovni) writes: +--------------- | vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: | >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. +--------------- But the ln(1) *program* does succeed, even with hard links. Try this on your favorite S5r3 system: % touch foo bar % ls -li foo bar 12151 -rw-r--r-- 1 rpw3 engr 0 Jun 14 19:31 bar 12147 -rw-r--r-- 1 rpw3 engr 0 Jun 14 19:31 foo % ln foo bar % ls -li foo bar 12147 -rw-r--r-- 2 rpw3 engr 0 Jun 14 19:31 bar 12147 -rw-r--r-- 2 rpw3 engr 0 Jun 14 19:31 foo Sorry, that's System-V... :-{ -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") (06/15/90)
I disagree. A lot of scripts I have seen remove the file first, then do the simbolic link. Also the man page I have for ln does not have a -i option. -- Brent L. Bates NASA-Langley Research Center M.S. 361 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov
merritt@iris613.gsfc.nasa.gov (John H Merritt) (06/15/90)
In article <62307@sgi.sgi.com> rpw3@sgi.com (Rob Warnock) writes: >But the ln(1) *program* does succeed, even with hard links. Not if you don't have write permission to the directory. Also, you are warned when you have no write permission to the target file. iris613 42> touch foo bar iris613 43> chmod 0 foo bar iris613 46> ls -li 18475 ---------- 1 merritt fire 0 Jun 15 09:44 bar 18469 ---------- 1 merritt fire 0 Jun 15 09:44 foo iris613 47> ln foo bar ln: bar: 0 mode? y iris613 48> ls -li 18469 ---------- 2 merritt fire 0 Jun 15 09:44 bar 18469 ---------- 2 merritt fire 0 Jun 15 09:44 foo iris613 49> rm foo bar foo: 0 mode ? y bar: 0 mode ? y Remember we are modifying the directory entries. Personally, I prefer that the files are clobbered and no warning issued. The "Do what I say, not what I mean!" attitude. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ John H. Merritt # Yesterday I knew nothing, Applied Research Corporation # Today I know that. merritt@iris613.gsfc.nasa.gov #