From nobody@FreeBSD.org  Tue Sep 25 08:03:25 2001
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (unknown [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id CD59637B446
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 25 Sep 2001 08:03:25 -0700 (PDT)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.4/8.11.4) id f8PF3Pr42822;
	Tue, 25 Sep 2001 08:03:25 -0700 (PDT)
	(envelope-from nobody)
Message-Id: <200109251503.f8PF3Pr42822@freefall.freebsd.org>
Date: Tue, 25 Sep 2001 08:03:25 -0700 (PDT)
From: Jeremy Chadwick <jdc@best.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: /bin/mv results in warnings when /bin/cp -p does not.
X-Send-Pr-Version: www-1.0

>Number:         30819
>Category:       bin
>Synopsis:       /bin/mv results in warnings when /bin/cp -p does not.
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Sep 25 08:10:01 PDT 2001
>Closed-Date:    Fri Apr 14 19:23:53 GMT 2006
>Last-Modified:  Fri Apr 14 19:23:53 GMT 2006
>Originator:     Jeremy Chadwick
>Release:        4.4-STABLE
>Organization:
>Environment:
Not applicable.
>Description:
From mv(1):

  As the rename(2) call does not work across file systems, mv uses cp(1)
  and rm(1) to accomplish the move.  The effect is equivalent to:

  rm -f destination_path && \
  cp -pRP source_file destination && \
  rm -rf source_file

From cp(1):

-p    Cause cp to preserve in the copy as many of the modification time,
      access time, file flags, file mode, user ID, and group ID as
      allowed by permissions.

      If the user ID and group ID cannot be preserved, no error message
      is displayed and the exit value is not altered.

It seems to me the "warning" spit out by mv(1) is worthless, as cp(1) does not do this.

Could this warning in mv(1) be removed?  It seems very contradictory to what's in the cp(1) manpage.
>How-To-Repeat:
$ id
uid=502(jdc) gid=100(users) groups=100(users)
$ ls -ld /tmp
drwxrwxrwt   4 root     wheel         512 Sep 25 07:56 /tmp
$ touch /tmp/foo
$ ls -ld /tmp/foo
-rw-------   1 jdc      wheel           0 Sep 25 07:54 /tmp/foo
$ cp -pRP /tmp/foo ./foo
$ ls -ld ./foo
-rw-------   1 jdc      users           0 Sep 25 07:54 ./foo
$ rm ./foo
$ mv /tmp/foo ./foo
mv: ./foo: set owner/group (was: 502/0): Operation not permitted
>Fix:

>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: Jeremy Chadwick <jdc@best.net>
Cc: <freebsd-gnats-submit@FreeBSD.ORG>
Subject: Re: bin/30819: /bin/mv results in warnings when /bin/cp -p does not.
Date: Thu, 27 Sep 2001 00:44:40 +1000 (EST)

 On Tue, 25 Sep 2001, Jeremy Chadwick wrote:
 
 > >Description:
 > >From mv(1):
 >
 >   As the rename(2) call does not work across file systems, mv uses cp(1)
 >   and rm(1) to accomplish the move.  The effect is equivalent to:
 >
 >   rm -f destination_path && \
 >   cp -pRP source_file destination && \
 >   rm -rf source_file
 
 This is a bug in the man page.  mv across file systems is not quite
 equivalent to the above.  In particular, mv is required to report all
 errors for duplicating file attributes, although such errors do not
 affect mv's exit status or the removal of the source file (POSIX spec).
 
 > >From cp(1):
 >
 > -p    Cause cp to preserve in the copy as many of the modification time,
 >       access time, file flags, file mode, user ID, and group ID as
 >       allowed by permissions.
 >
 >       If the user ID and group ID cannot be preserved, no error message
 >       is displayed and the exit value is not altered.
 >
 > It seems to me the "warning" spit out by mv(1) is worthless, as cp(1) does not do this.
 
 cp -p is different from mv because it is normal for cp -p to be unable to
 preserve attributes, and cp -p doesn't destroy the original copies.  mv
 always preserves attributes unless the move is across filesystems.
 
 Bruce
 
State-Changed-From-To: open->closed 
State-Changed-By: maxim 
State-Changed-When: Fri Apr 14 19:23:33 UTC 2006 
State-Changed-Why:  
Duplicate of bin/1375. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=30819 
>Unformatted:
