On Thu, 2025-05-29 at 12:53 +0100, Gaël Donval wrote: > > On 29/05/2025 10:56, Gael Donval wrote: > > > On Thu, 2025-05-29 at 10:10 +0100, Pádraig Brady wrote: > > > > On 28/05/2025 16:14, Gael Donval wrote: > > > > > Dear list, > > > > > > > > > > We've unearth an odd behaviour in cp: `cp --preserve=xattr` tries to > > > > > copy both attributes of the chattr kind and extended attributes of > > > > > the getfattr kind with apparently no way to disable either one of > > > > > them (it's all or nothing). This is problematic in tools like mkosi > > > > > where non-filesystem-specific xattributes need to be preserved whilst > > > > > FS-specific attributes must be discarded for cross-filesystem support. > > > > > > > > > > I have added a MWE at the end of this email after my signature: it > > > > > creates two raw partitions as files (one as XFS, one as BTRFS), > > > > > mounts them in local folders and creates 3 files in the BTRFS > > > > > partitions later altered before copy. > > > > > > > > > > Referring to the script, we think there should be an option to copy > > > > > files foo (no-attr), bar (setfattr) and baz (chattr), keeping the > > > > > setfattr's xattr and discarding chattr's attr. Looking at the code, > > > > > it seems like cp eventually defers the actual attribute copying > > > > > libattr, which seems to handle both, but separately (which is what we > > > > > want). > > > > > > > > > > Would it make sense to add a separate `attr` preserve value for the > > > > > chattr case and keep `xattr` for getfattr case? > > > > > > > > I've not looked in detail at your case, > > > > but it's worth noting that /etc/xattr.conf > > > > gives the facility to skip copying certain xattrs. > > > > Does that suffice to handle your issue? > > > > > > As far as I can tell, xattr.conf cannot be used to ignore normal file > > > attributes (as opposed to extended attributes), can it? We need a way > > > to copy extended attributes without copying normal file attributes. > > > > Well there is no code in coreutils to copy "chattr" attributes. > > It was discussed previously, but we decided not to support those > > due to the incompat issues you're hitting. > > It does copy them though. If it's not the intent of `preserve=xattr`, > I'm afraid it's a bug. My reproducer makes it obvious that it tries to > copy them. If you change `mkfs.xfs` to `mkfs.btrfs`, it will all > succeed and you'll see chattr attributes are copied. If your remove `-- > preserver=xattr`, you'll see chattr attributes are not copied anymore. > > > > That version of cp are you using? > > cp (GNU coreutils) 9.7 > > > > > strace may be instructive as to that is reading/writing these chattrs > > (this is done with ioctl FS_IOC_GETFLAGS IIRC). > > I might be wrong but it looks like everything xattr-related is deferred > to libattr. > I'll investigate that tomorrow!
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? Cheers, Gaël > > Gaël > > > > > cheers, > > Pádraig
