From owner-freebsd-bugs  Tue Jul  9 20:23:39 1996
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id UAA01726
          for bugs-outgoing; Tue, 9 Jul 1996 20:23:39 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA01719
          for <freebsd-bugs@freefall.freebsd.org>; Tue, 9 Jul 1996 20:23:33 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id NAA20926; Wed, 10 Jul 1996 13:16:45 +1000
Date: Wed, 10 Jul 1996 13:16:45 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199607100316.NAA20926@godzilla.zeta.org.au>
To: bde@zeta.org.au, mrm@MARMOT.Mole.ORG, zach@blizzard.gaffaneys.com
Subject: Re: bin/1375: Extraneous warning from mv(1)
Cc: freebsd-bugs@freefall.freebsd.org
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>> attributes.  I now think it should refuse to the move if it can't
>> preserve all the attributes.  It can simply unlink the target and
>> avoid unlinking the source if there is a problem.

>Or, one could leave it as it is, and accept the known, rather predictable,
>and simple behavior instead of a more complicated and unknown behavior.

To predict the behaviour, you need to know if the move is across file
systems and the current bugs in mv.  Only mv's within a file system
are predictable.

Another bug in mv:

	touch /tmp/z
	chflags uchg /tmp/z
	mv /tmp/z /tmp/z1	# Fails as expected
	mv /tmp/z ~		# Copies the file to ~/z, then fails to
				# unlink ~/z, leaving two copies of the
				# file, one without the uchg flag.

If mv happens to use `cp -pRP' (which it does for everything except regular
files) then the result is similar.  cp knows about file flags and sets the
uchg flag in the copy, except of course if the target file system doesn't
support the uchg file flag.

Bruce