Open traktofon opened 2 years ago
I have the same issue. It seems to be related to the kernel version that is running. With kernel version 4.19.0-27 rsync between ext4 and xfs worked great, including xattr sync.
After booting with kernel version 5.10.0-0, no xattrs are synced on the first sync. From the second sync on, only a subset of files/directories get xattrs. But never all of them.
With kernel version 6.1.0-23, I exeperience the exact same behavior of @traktofon. After the first sync, all files have correct xattrs. Afterwards, they are subsequently deleted and restored.
When rsync'ing a directory from an ext4 filesystem to an xfs filesystem (on Linux) as root, and trying to preserve both ACLs (option -A) and extended attributes (option -X), then on the first pass the ACLs are copied correctly, but on a second pass (which should be idempotent if there are no changes on the source) the ACLs on the target are deleted. (A third pass will restore the ACLs, etc.)
Steps to reproduce:
Be root. Let
/a
be an ext4 filesystem (also tested: ext3; I guess anything non-xfs would do, as long as it supports ACLs). Let/b
be an xfs filesystem (created with default options in Debian 11). Have any files/folders on/a
with ACLs, e.g.Now rsync the
TEST
directory to/b
:We see that the ACLs have been copied correctly. But running the same
rsync
command again:We see that the ACLs on the target have been deleted.
I suspect that this is caused by xfs storing ACLs in an extended attribute:
and perhaps this needs to be special-cased inside rsync when copying xattrs?
Workaround:
If you know which extended attributes are actually in use (e.g. only those of the
user.*
kind) then an additional rsync option like--filter='-x! user.*'
can be used to only process these specific attributes, and this seems to prevent the destruction of ACLs on the target.Software version:
Tested with
v3.2.4pre3-18-gd821e4cb
(current git master) and3.2.3
(from Debian 11). Tested with a local source as well as a remote source (over ssh).