Re: bug in mv while moving something into symlink-directory

[Bob Proulx]

Martin Grosup wrote:
> Hello. Sorry for my bad english. I will try my best:

Thank you for that very detailed report.  Details such as you provided
are most appreciated.

However, what you are seeing is not a bug.  You are seeing behavior by
the shell trying to help you but instead is only confusing you.

> gw:/home/mag81/incoming # mv --version
> mv (fileutils) 4.1.11

This is unrelated, but when convenient you should update to the later
coreutils-5.x series.  It is a whole major number later with various
fixes and improvements.

> gw:/home/mag81 # l in* v*
> lrwxrwxrwx    1 root     root           47 Jul 18 20:29 incoming -> 
> /home/mldonkey/mldonkey-distrib-2.5-3/incoming/
> lrwxrwxrwx    1 root     root           13 Mar  4  2003 video1 -> 
> /data1/video/
> lrwxrwxrwx    1 root     root           12 Oct 18 11:01 video2 -> 
> /data2/video/

Symlinks are purely name translations.  But the shell tries to hide
this from you.

> gw:/home/mag81/incoming # touch testfile
> gw:/home/mag81/incoming # mv testfile ../video2/
> mv: cannot stat `../video2/testfile': Not a directory

Correct.  /home/mag81/incoming is really
/home/mldonkey/mldonkey-distrib-2.5-3/incoming/ and therefore
../video2/testfile is really
/home/mldonkey/mldonkey-distrib-2.5-3/video2/testfile.  Does that
directory exist?  The command says no.

> gw:/home/mag81/incoming # mv testfile ../video2 

../video2 does not have a trailing slash and so can be a filename.
Again, symbolic links are purely name translations.  Remember you are
NOT in /home/mag81/incoming.  You are in
/home/mldonkey/mldonkey-distrib-2.5-3/incoming and .. in that
directory is /home/mldonkey/mldonkey-distrib-2.5-3.  So this command
is really the following.

  mv /home/mldonkey/mldonkey-distrib-2.5-3/incoming/testfile 
/home/mldonkey/mldonkey-distrib-2.5-3/video2

You will find your file now named video2.  The commands that you run
at the shell are not fooled by the shell.  To them the files '.' and
'..' are real files in your directory.  Try these commands and see
that the inodes are different for your 'incoming' directory.  If you
were in /home/mag81/incoming then .. would be the same as /home/mag81,
right?  But they are not if a symlink too you someplace else.

  cd /home/mag81/incoming
  ls -ldi .. /home/mag81

Starting with AT&T ksh and later lookalikes such as bash the shell
tries to hide symlinks from you.  So if cd into a symlink it won't
show you the actual directory.  It will instead store the way you got
there into the PWD variable.  That enables you to 'cd ..' and get out
the same way you got in.  A 'cd ..' to the shell just pulls the last
entry off of $PWD and then changes directory to the resulting path.

Many people like this behavior and so it is the default.  I personally
do not.  But symbolic links one way will  confuse 50% of the people
and the other way will confuse the other 50%.  There is no way to
please everyone.

The bash shell includes a way to turn this default behavior off.  Try
the following.  (Use 'set +P' to turn it back to the default mode.)

  set -P

The manual for bash states the following.

              -P      If  set, the shell does not follow symbolic
                      links when executing commands  such  as  cd
                      that  change the current working directory.
                      It uses the  physical  directory  structure
                      instead.  By default, bash follows the log­
                      ical chain of directories  when  performing
                      commands  which  change  the current direc­
                      tory.

Try running your commands in this mode to understand what is
happening.

Hope this helps,
Bob