From owner-freebsd-bugs  Mon Nov 20 22:14:30 1995
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id WAA17266
          for bugs-outgoing; Mon, 20 Nov 1995 22:14:30 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA17261
          for <freebsd-bugs@freebsd.org>; Mon, 20 Nov 1995 22:14:24 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA06922; Tue, 21 Nov 1995 17:09:19 +1100
Date: Tue, 21 Nov 1995 17:09:19 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199511210609.RAA06922@godzilla.zeta.org.au>
To: bde@zeta.org.au, freebsd-bugs@freebsd.org, tege@matematik.su.se
Subject: Re: Bogus mv behaviour
Sender: owner-bugs@freebsd.org
Precedence: bulk

>>When moving directories across filesystems, e.g., "mv SOURCEDIR/A DESTDIR",
>>if DESTDIR/A exists, SOURCEDIR/A will be made into DESTDIR/A/A.  That's very
>>surprising, in particular when many directories are moved in the same
>>command, and they end up at different levels.

I wrote:
>This bug affects all mv's, not just ones across file systems.  I hope it

Actually it only affects cases when the final target dir is empty.  After
`mkdir a b a/a b/a'

	mv a b			# replaces b/a by the original a
	gnu-mv a b		# fails (under LInux)

After `mkdir a b a/a b/a a/a/a b/a/b', both mv's fail.  However, if b is
on a separate file system, then FreeBSD mv still tries to do the move,
and the move succeeds because it is reduced to cp -PRp and not to renam().

Other mv strangeness: after `mkdir a b', there seems to be no way using
gnu mv to rename a to b although the rename syscall would succeed because
the target is empty.

	mv a/ b/		# renames a to b
	gnu-mv a/ b/		# renames a to b/a (under Linux)

The trailing slashes somehow stops mv from concatenating the directory
names, and rename("a/", "b/") works right under FreeBSD.

Bruce