From: jenkins@DPW.COM (Colin Jenkins) Subject: Re: Directory rename FX Date: 16 Feb 1993 02:31:35 GMT
In article <1lfh5c$muv@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:
>In comp.os.linux, article <1993Feb12.005637.7538@tc.cornell.edu>,
> mdw@theory.TC.Cornell.EDU (Matt Welsh) writes:
>> In article <1lek9f$5g5@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:
>> >
>> >$ cd /tmp ; mkdir x ; cd x
>> >$ (cd ../ mv x y )
>> >$ cd .
>> >.: No such file or directory
>>
>> Same behaviour. What's the problem?
>>
>My point is that renaming a directory should not cause a program (which
>happens to be in that directory at the moment) to fail on every path which
>happens to begin with "./".
[Suggested bug fix deleted]
I don't think this is a kernel bug, but a shell bug. I suspect that the
shell is not bothering to cd() to ".", (for efficiency reasons) but instead
cd()s to its internal notion of the current working directory. If you print
$PWD in your example, you will see that the shell still thinks it is in
"/tmp/x". You can also repeat the problem using symlinks:
$ cd /tmp; mkdir dir; ln -s dir x
$ cd x
$ rm ../x
$ cd .
.: No such file or directory
$ echo $PWD
/tmp/x
$ pwd
/tmp/dir
Note also, that more complex paths involving "." do work, so in both examples,
something like this works:
$ cd ./..
One last thing, other programs do not have problems, so doing these things
work:
$ ls .
$ sh
$ cd .
$ echo $PWD
/tmp/dir
Colin