D. Allen [CGL]" <idallen@watcgl.waterloo.edu> (01/30/91)
I thought the Ultrix gurus would have fixed this mv/rename bug ages ago.
It's been around since at least Ultrix 2.1!
Script started on Tue Jan 29 17:04:27 1991
% cd /tmp
% mkdir a foo
% ln -s foo bar
% cd a
% mkdir xxx
% mv xxx /tmp/bar/xxx
mv: /tmp/bar/xxx: rename: No such file or directory
% mv xxx /tmp/foo/xxx
% mv /tmp/bar/xxx xxx
% mv xxx /tmp/bar/xxx
mv: /tmp/bar/xxx: rename: No such file or directory
% echo mv across a symlink is still broken on Ultrix 4.1
This can really get you if you're in /usr/tmp (a symlink to var/tmp)
and you try to move directories around.
DECsystem 5400 running "ULTRIX V4.1 (Rev. 52)"
--
-IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu
[129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canadalibove@libove.det.dec.com (Jay Vassos-Libove) (01/30/91)
In article <1991Jan29.221803.28905@watcgl.waterloo.edu> idallen@watcgl.waterloo.edu (Ian! D. Allen [CGL]) 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.
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!
% cd a
% mkdir 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
% cd ..
% rm bar
% ln -s /tmp/foo bar
% # so now /tmp/bar is a pointer to /tmp/foo
% cd a
% mv xxx ../bar
% ls -l ..
drwxr-x--- 2 libove 512 Jan 30 10:53 a
lrwxr-x--- 1 libove 8 Jan 30 10:53 bar -> /tmp/foo
drwxr-x--- 3 libove 512 Jan 30 10:53 foo
% ls -l ../foo ../bar
lrwxr-x--- 1 libove 8 Jan 30 10:53 ../bar -> /tmp/foo
../foo:
total 1
drwxr-x--- 2 libove 512 Jan 30 10:53 xxx
% exit
script done on Wed Jan 30 10:53:13 1991
This can really get you if you're in /usr/tmp (a symlink to var/tmp)
and you try to move directories around.
Now, it is true that /usr/tmp -> var/tmp so indeed this might cause
troubles... but I'd like to see a particular example, since you can't
move a directory across a filesystem boundary anyway!
--
Jay Vassos-Libove libove@libove.det.dec.com
Digital Equipment Corporation decwrl!libove.det.dec.com!libove
Detroit ACT/Ultrix Resource Center Opinions? They're mine, mine, all mine!
Farmington Hills, Michigan and D.E.C. Can't have 'em!paisley@cme.nist.gov (Scott Paisley) (01/31/91)
In article <LIBOVE.91Jan30105821@libove.det.dec.com> 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
libove@libove.det.dec.com (Jay Vassos-Libove) (02/01/91)
Oops. Well, I should have called that feature a "feature" - I have gone and found a nice reproduceable way for a non-privileged user to crash an ultrix v4.1 system using an extension of this mv/symlink bug... and I have submitted a Quality Assurance Report on the problem. -- Jay Vassos-Libove libove@libove.det.dec.com Digital Equipment Corporation decwrl!libove.det.dec.com!libove Detroit ACT/Ultrix Resource Center Opinions? They're mine, mine, all mine! Farmington Hills, Michigan and D.E.C. Can't have 'em!