From nobody@FreeBSD.ORG Wed Jun 23 22:54:27 1999
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id 2D48114CA8; Wed, 23 Jun 1999 22:54:27 -0700 (PDT)
Message-Id: <19990624055427.2D48114CA8@hub.freebsd.org>
Date: Wed, 23 Jun 1999 22:54:27 -0700 (PDT)
From: shirai@nintendo.co.jp
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@freebsd.org
Subject: mv(1) cannot inherit the file flags.
X-Send-Pr-Version: www-1.0

>Number:         12375
>Category:       bin
>Synopsis:       mv(1) cannot inherit the file flags.
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    miwi
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jun 23 23:00:00 PDT 1999
>Closed-Date:    Sun Aug 6 10:28:13 PDT 2000
>Last-Modified:  Fri Feb 08 00:03:07 UTC 2008
>Originator:     Takashi SHIRAI
>Release:        2.2.7-RELEASE
>Organization:
Nintendo Co., Ltd.
>Environment:
FreeBSD tp235 2.2.7-RELEASE FreeBSD 2.2.7-RELEASE #0: Thu Apr  8 20:33:21 JST 1999     shirai@tp235:/usr/src/sys/compile/tp235  i386
>Description:
mv(1) man page says the following:
>      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

But, cp(1) is actually used only if source_file is not the regular file.
Then, mv(1) of the regular file cannot inherit its file flags.

>How-To-Repeat:
$ > /foo
$ chflags nodump /foo
$ ls -lo /foo
-rw-r--r--  1 shirai  user  nodump 0 Jun 24 14:06 /foo
$ mv /foo /var/tmp
$ ls -lo /var/tmp/foo
-rw-r--r--  1 shirai  user  - 0 Jun 24 14:07 /var/tmp/foo

>Fix:
The following is a bug fix patch for FreeBSD-current.
--- mv.c.org    Tue Oct 13 14:52:31 1998
+++ mv.c        Thu Jun 24 22:49:36 1999
@@ -283,6 +283,8 @@
        }
        if (fchmod(to_fd, sbp->st_mode))
                warn("%s: set mode (was: 0%03o)", to, oldmode);
+       if (fchflags(to_fd, sbp->st_flags))
+               warn("%s: set flags (was: 0%07o)", to, sbp->st_flags);

        tval[0].tv_sec = sbp->st_atime;
        tval[1].tv_sec = sbp->st_mtime;

(Sorry for transformed TAB.)


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: asmodai 
State-Changed-When: Mon Jul 10 02:27:36 PDT 2000 
State-Changed-Why:  
This is not the case anymore on 4.0-STABLE.  With 4.0-STABLE mv(1) 
honours flags. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=12375 
State-Changed-From-To: closed->analyzed 
State-Changed-By: sada 
State-Changed-When: Mon Jul 10 05:20:54 PDT 2000 
State-Changed-Why:  
On my -current the same problem occurs. 
Take care that source and destination dirs are not on same FS 
in this case. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=12375 
State-Changed-From-To: analyzed->closed 
State-Changed-By: sada 
State-Changed-When: Sat Jul 15 07:59:27 PDT 2000 
State-Changed-Why:  
Committed for HEAD branch, thanks. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=12375 
State-Changed-From-To: closed->analyzed 
State-Changed-By: sada 
State-Changed-When: Tue Jul 18 09:03:02 PDT 2000 
State-Changed-Why:  
Should be kept opening until MFC. 
Pointed out by: sheldonh 

http://www.freebsd.org/cgi/query-pr.cgi?pr=12375 
State-Changed-From-To: analyzed->closed 
State-Changed-By: nbm 
State-Changed-When: Sun Aug 6 10:28:13 PDT 2000 
State-Changed-Why:  
sada MFC'd this in 1.24.2.1 of mv.c 

http://www.freebsd.org/cgi/query-pr.cgi?pr=12375 
Responsible-Changed-From-To: freebsd-bugs->miwi 
Responsible-Changed-By: miwi 
Responsible-Changed-When: Fri Feb 8 00:03:06 UTC 2008 
Responsible-Changed-Why:  
I'll take it. 

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