From owner-freebsd-bugs  Mon Jul  8 01:30:12 1996
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id BAA16677
          for bugs-outgoing; Mon, 8 Jul 1996 01:30:12 -0700 (PDT)
Received: (from gnats@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id BAA16658;
          Mon, 8 Jul 1996 01:30:07 -0700 (PDT)
Date: Mon, 8 Jul 1996 01:30:07 -0700 (PDT)
Message-Id: <199607080830.BAA16658@freefall.freebsd.org>
To: freebsd-bugs
Cc: 
From: Bruce Evans <bde@zeta.org.au>
Subject: Re: bin/1375: Extraneous warning from mv(1)
Reply-To: Bruce Evans <bde@zeta.org.au>
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The following reply was made to PR bin/1375; it has been noted by GNATS.

From: Bruce Evans <bde@zeta.org.au>
To: FreeBSD-gnats-submit@FreeBSD.org, james@jraynard.demon.co.uk
Cc:  Subject: Re: bin/1375: Extraneous warning from mv(1)
Date: Mon, 8 Jul 1996 18:24:01 +1000

 >According to mv(1), moving a file across filesystems is equivalent to
 >calling cp -pRP, surrounded by calls to rm(1). According to cp(1),
 >when the -p option is used, no error message should be displayed if
 >the user and group ID of the file cannot be preserved.
 
 This is probably a bug in mv.1.  mv should and does try harder than
 cp to preserve attributes.
 
 >mv(1) behaves as expected if the file and its destination directory
 >are on the same filesystem, or if a directory is moved across a
 >filesystem instead of a file.
 
 The latter is a bug in mv.  It really does use cp -pRP in this case,
 but cp -pRP is inadequate.  It snaps links, doesn't preserve preservable
 directory timestamps, and does the wrong thing for `mv dir existing-dir'.
 
 There should also be warnings for failures to preserve flags.  The
 fastcopy() case of mv doesn't actually attempt to preserve flags,
 although the cp -pRP case does (try `touch /tmp/z; chflags nodump
 /tmp/z; mv /tmp/z anotherfs').
 
 Bruce