From rfg@tristatelogic.com  Mon Jun 11 19:39:47 2012
Return-Path: <rfg@tristatelogic.com>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 30E351065744
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 11 Jun 2012 19:39:47 +0000 (UTC)
	(envelope-from rfg@tristatelogic.com)
Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118])
	by mx1.freebsd.org (Postfix) with ESMTP id 0BD158FC0C
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 11 Jun 2012 19:39:46 +0000 (UTC)
Received: by segfault.tristatelogic.com (Postfix, from userid 1237)
	id D461D5083A; Mon, 11 Jun 2012 12:39:39 -0700 (PDT)
Message-Id: <20120611193939.D461D5083A@segfault.tristatelogic.com>
Date: Mon, 11 Jun 2012 12:39:39 -0700 (PDT)
From: Ronald F.Guilmette <rfg@tristatelogic.com>
Reply-To: Ronald F.Guilmette <rfg@tristatelogic.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: cp should provide an option to copy file ACLs and attributes
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         168961
>Category:       bin
>Synopsis:       cp(1): cp should provide an option to copy file ACLs and attributes
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jun 11 19:40:09 UTC 2012
>Closed-Date:    
>Last-Modified:  Thu Apr 17 04:37:43 UTC 2014
>Originator:     Ronald F. Guilmette
>Release:        FreeBSD 8.3-RELEASE amd64
>Organization:
entropy
>Environment:

8.3-RELEASE amd64

>Description:

Based on the cp(1) man page, it appears that people will use the -p option
when they want as much stuff relating to the original file to be preserved
in the copy as possible.  Given that, it would make a great deal of sense
if "cp -p" also preserved:

	1)  Any & all ACLs associated with the input file(s), and

	2)  And and all extended file attributes associated with the
	    input file(s).

I have just now checked, and it appears that cp, either with or without the
-p option *does not* preserve extended file attributes in the copy.  I am
not able to easily check at the moment, but I would suspect that the same
is true also for file ACLs.

If the -p option is deemed unsuitable for requesting preservation of input
file ACLs and extended file attributes, then perhaps another new option
letter should be created/used for/by cp(1).

I will be filing a separate PR requesting also that the cp(1) man page be
enhanced so as to document cp's processing (or, as currently, its non-
process) of extended file attributes and/or file ACLs.

>How-To-Repeat:

	touch foo
	setextattr user name value foo
	getextattr user name foo
	cp -p foo bar
	getextattr user name bar

	<< At this point you will get an error because bar has no such
	   extended attribute as "name".  That's because the attribute
	   name/value pair did not get copied over to bar from foo.  >>

>Fix:

I dunno.  Hack the code, I guess.
>Release-Note:
>Audit-Trail:
>Unformatted:
