Bug 240146 - 'man cp' does not discuss extended attributes; it really should since even -p discards them!
Summary: 'man cp' does not discuss extended attributes; it really should since even -p...
Status: Open
Alias: None
Product: Documentation
Classification: Unclassified
Component: Manual Pages (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2019-08-27 14:15 UTC by Sean McBride
Modified: 2019-08-27 22:25 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Sean McBride 2019-08-27 14:15:48 UTC
The man page for 'cp' does not contain the word "extended" nor "attribute".

I was very surprised to see that even 'cp -p' apparently does not preserve the extended attributes of a file.

I'd argue 'cp -p' behaviour is wrong, but at the very least it should be documented.

By contrast, the macOS 10.13 man page says: "-p    Cause cp to preserve the following attributes of each source file in the copy: modification time, access time, file flags, file mode, user ID, and group ID, as allowed by permissions.  Access Control Lists (ACLs) and Extended Attributes (EAs), including resource forks, will also be preserved."

A simple sentence to warn that cp -p will blow away EAs would help.  We're talking about data loss here. :(


root@freenas[/test]# lsextattr user A.txt 
A.txt	DosStream.com.apple.TextEncoding:$DATA	DosStream.AFP_Resource:$DATA	DosStream.AFP_AfpInfo:$DATA	DOSATTRIB	DosStream.com.apple.lastuseddate#PS:$DATA

root@freenas[/test]# cp -a A.txt A2.txt      

root@freenas[/test]# lsextattr user A2.txt
Comment 1 Conrad Meyer freebsd_committer 2019-08-27 15:59:19 UTC
Yeah, it's unfortunate!  Totally agree we should at a minimum document the gap.

cp(1) is an old tool and long predates extended attributes in FreeBSD.

FWIW, POSIX 1003.1-2017 cp(1) also does not mention extattrs at all:


GNU cp only touches on it obliquely:


>       -a, --archive
>              same as -dR --preserve=all
...                          ^^^^^^^^^^^^
>       -p     same as --preserve=mode,ownership,timestamps
>       --preserve[=ATTR_LIST]
>              preserve the specified attributes (default:
>              mode,ownership,timestamps), if possible additional attributes:
>              context, links, xattr, all

(And note that even GNU cp's bare '-p' option does NOT preserve extattrs; you need to pass '-a'.)

So this is a valid doc bug, but could also be filed as a Base system / bin bug to add the missing support.

As a workaround, tar(1) can be used to copy extended attributes (--xattrs).
Comment 2 Sean McBride 2019-08-27 20:32:41 UTC
I'm happy to file an additional bug against 'cp -p' behaviour.  I tried to search for an existing one, but didn't find it.  Surely I can't be the first to notice/want this?
Comment 3 Conrad Meyer freebsd_committer 2019-08-27 21:00:17 UTC
My impression is that extattr/fork use is much less common in BSD/Linux than Windows.  It seems like Mac gained support in 10.4 in ~2005.

It's quite possible that folks who ran into this shortcoming just installed coreutils and used gcp.

Btw, I don't think the cp(1) -p behavior is wrong here.  I was suggesting adding extattr support to '-a', like GNU cp does.
Comment 4 Sean McBride 2019-08-27 22:03:33 UTC
Not sure about Windows, but EAs are quite common on macOS.

Re: -p vs -a, don't much care myself, but I'd like *some* option for cp to preserve them. :)
Comment 5 Sean McBride 2019-08-27 22:11:21 UTC
For cp itself, I created https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240157
Comment 6 Conrad Meyer freebsd_committer 2019-08-27 22:25:06 UTC
(In reply to Sean McBride from comment #4)
On Windows, they're called "ADS" (alternative data streams) and the semantics are somewhat different, but they tend to be used in similar ways as extattrs.

> but I'd like *some* option for cp to preserve them. :)

Me too :-).

> For cp itself, I created ...