bug#78623: cp --preserve=xattr copies attr as well as xattr which breaks cross-FS copy

On 30/05/2025 10:02, Gael Donval wrote:
> Ok, I've done that and you were right. I guess BTRFS implements its
> file attributes as extended attributes. The relevant part of the strace
> is this:
> 
> openat(AT_FDCWD, "btrfs/baz", O_RDONLY) = 4
> openat(3, "baz", O_WRONLY|O_CREAT|O_EXCL, 0644) = 5
> flistxattr(4, NULL, 0)                  = 18
> flistxattr(4, "btrfs.compression\0", 18) = 18
> openat(AT_FDCWD, "/etc/xattr.conf", O_RDONLY) = 6
> read(6, "# /etc/xattr.conf\n#\n# Format:\n# "..., 4096) = 622
> fgetxattr(4, "btrfs.compression", NULL, 0) = 4
> fgetxattr(4, "btrfs.compression", "zlib", 4) = 4
> fsetxattr(5, "btrfs.compression", "zlib", 4, 0) = -1 EOPNOTSUPP (Operation not supported)
> 
> and updating /etc/xattr.conf to ignore it does work.
> 
> I can't see any way to tweak this behaviour at command-line level yet
> the behaviour can be triggered by normal users: would it make sense to
> add a flag to filter xattr out at CLI level?

It would get unwieldy as CLI options I think,
and you'd usually want a static list of FS specific options.

There are additional complications with a static list though,
as you would probably want to attempt to copy xattrs within
or between file systems of the same type, so unconditionally
avoiding them in a static list may not be appropriate.

Note `cp -a` will attempt to copy all xattrs
but ignore "operation not supported" errors.
So we only have this issue with --preserve=xattr which diagnoses any issues.
Perhaps we would benefit from a --preserve=supported-xattr option?

BTW there is a further complication with the "btrfs.compression" xattr
as its behavior is dependent on whether you write that xattr
before or after you write the data:
https://lists.gnu.org/archive/html/coreutils/2020-05/msg00013.html
(Though note we reflink by default now, since the above discussion
which alleviates the issue somewhat).

cheers,
Padraig