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

Previous Next

Package: coreutils;

Reported by: Gael Donval <gael.donval <at> manchester.ac.uk>

Date: Thu, 29 May 2025 05:04:02 UTC

Severity: normal

Full log


View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Gael Donval <gael.donval <at> manchester.ac.uk>, "78623 <at> debbugs.gnu.org" <78623 <at> debbugs.gnu.org>
Subject: bug#78623: cp --preserve=xattr copies attr as well as xattr which breaks cross-FS copy
Date: Fri, 30 May 2025 10:37:47 +0100
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




This bug report was last modified 13 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.