strange behaviour with mv (fwd)

I may have found a bug with mv.  When x is a symlink to
a directory, the behaviour of

   mv x y
and
   mv x/ y

is not the same.  Please read the below description
I wrote, and the response I got from Derrick Moser.

thanks,
-mike


---------- Forwarded message ----------
Date: Sat, 14 Sep 2002 22:54:38 -0400 (EDT)
From: Derrick Moser <[email protected]>
To: Michael McGuffin <[email protected]>
Cc: Brian Wong <[email protected]>
Subject: Re: strange behaviour with mv

The behaviour for "mv D E" and "mv D E/" is expected.  However, the
behaviour for "mv D/ E" and "mv D/ E/" is unexpected and is probably a
bug.  

The meaning of "D/" is kind of grey when "D" is a symlink.  lstat()
considers "D/" to mean the directory reached after following the symlinks
(assuming it does point to a directory).  rename() and unlink() considers
"D/" to be an error (but if "D" was a directory, "D/" would be valid).

I suspect the author of "mv" didn't understand how "D" and "D/" are
interpreted by different system calls and made a mistake.  It looks like
"mv" is being told that "D/" is a directory by lstat() but then assumes
the destination is on a different filesystem and needs a deep copy when
the call to rename() fails.

If you don't like the behaviour of "mv", you can write a shell function to
remove the trailing slash from the source filename before calling /bin/mv.

Cheers,
Derrick

On Sat, 14 Sep 2002, Michael McGuffin wrote:

> 
> Try this (with linux):
> 
>    mkdir A
>    cd A
>    mkdir B
>    cd B
>    echo "hello" > hello
>    cd ..
>    ln -s B C
> 
> Now C is a sym link to B, which contains the hello file.
> Now do this:
> 
>    mv C D
> 
> this changes the name of C to D.  So now D is a symlink
> to B.  However, if you now do this:
> 
>    mv D/ E
> 
> Now, E is not a symlink, but (apparently) a copy of B and
> everything under it.  You can edit the hello file under
> E, and it won't change the hello file under B.
> 
> The same thing happens if you try "mv D/ E/".
> However, "mv D E/" causes an error.
> 
> I use tab expansion a lot, so when there are directories
> (or symlinks to directories) as arguments, I usually get
> the slash at the end, which in the case above, leads
> to unexpected behaviour.
> 
> -mike