From nobody@FreeBSD.org Tue Sep 25 08:03:25 2001 Return-Path: Received: from freefall.freebsd.org (unknown [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id CD59637B446 for ; 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 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 To: Jeremy Chadwick Cc: 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: