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
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 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).
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?
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.
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. :)
For cp itself, I created https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240157
(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 ...