Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cme!durer!paisley From: paisley@cme.nist.gov (Scott Paisley) Newsgroups: comp.unix.ultrix Subject: Re: Ultrix 4.1 still has the mv/rename symlink bug? Message-ID: Date: 30 Jan 91 23:07:22 GMT References: <1991Jan29.221803.28905@watcgl.waterloo.edu> Sender: news@cme.nist.gov Organization: National Institute of Standards and Technology Lines: 43 In-reply-to: libove@libove.det.dec.com's message of 30 Jan 91 15:58:21 GMT In article libove@libove.det.dec.com (Jay Vassos-Libove) writes: > Actually, this is probably a feature you are seeing... If you execute > % ln -s foo bar > then you are making the file "bar" point to a file "foo" _in the current > directory_ - wherever that current directory is located at the time of > reference to the file bar. *Whoa!* > Script started on Wed Jan 30 10:52:39 1991 > % cd /tmp > % mkdir a foo > % ln -s foo bar > % # so now /tmp/foo is a pointer to ./bar - where ./ varies as you cd! So, you are saying that the link is really *dynamic*? That's weird. I can't think of a case where I would want that or could use it. I wouldn't call this a feature at all. It's confusing. > % cd a > % mkdir xxx Change this to "% touch xxx" > % mv xxx /tmp/bar/xxx > mv: /tmp/bar/xxx: rename: No such file or directory > % # as expected, since /tmp/a/bar does not exist I wouldn't expect this. If that's true, then it shouldn't matter that xxx is a file or a directory. Try the 'mv' when 'xxx' is a file. The mv works when xxx is a file. If your reasoning was true, shouldn't it apply to files as well as directories? Straighten me out here, I think it's a bug. This works on my sun 3/80 (SunOS 4.1). --- *Experience to Extremes* -Rush from 'the enemy within' Scott Paisley paisley@cme.nist.gov ..!uunet!cme-durer!paisley