When copying with cp
, the extended attributes are not preserved, even with explicit
cp -a --preserve=all /source /dest
or
cp -a --preserve=xattr /source /dest
The same is with rsync
, i.e.
rsync -aq -A -X --delete /source /dest
However, on the destination filesystem, I can create extended attribute manually (with chattr
). This means that the target filesystem supports xattr.
Why am I unable to preserve xattr
with cp
or rsync
?
Additional information:
- Both source and target filesystems are ext4
- Both source and target filesystems are local (not nfs)
- I am using Debian Wheezy
Best Answer
Update
After messing around with this some more and looking at the code for
chattr
and othere2fsprogs
, it is clear that the attributes set bychattr
and those set bylibattr
(eg with the commandsetfattr
) are very different.chattr
setsext
filesystem flags which simply do not map to an named attribute or namespace. None of them show up with any call tolibattr
'slistxattr
. They probably should map to named attributes in thesystem
namespace as assumed below, but as of yet this is completely unimplemented. Also thesystem.posix_acl_access
attribute I mistook for the mapping to one of these attributes below, is nothing to do with theext
filesystem flags and is rather to do with access control lists. The associatedstrace
messages appear for any file and disappear when onlycp --preserve=xattr
is used.It seems that the attributes set by
chattr
are specific toext
filesystems and that the only way to affect them is throughe2fsprogs
tools. In fact theman
page does not actually use the term 'extended attributes' for them, but rather 'file attributes'. 'Real' extended attributes are name/value pairs which can be altered bylibattr
and are implemented on multiple filesystems. These are whatcp
andrsync
look for and transfer over to copied files when the right options are given. It does however seem thatsystem
namespace exists to map thechattr
attributes to names and ultimately to equivalent attributes on other filesystems, but for now this doesn't work.I have left the original answer intact as there is some good information there, although it does go quite far wrong at points.
Update 2
I should have came back to this again before now, but as per this answer,
chattr
works on more than justext
filesystems. According to Wikipedia, it is equivalent to thechflags
command on BSD based systems.I wrote a script to test the setting and reading of these attributes on a few filesystems and got the following results:
Note that all attempts to read/set
reiserfs
file flags gave the above error, despite it being listed on Wikipedia as having some functionality. I did not testreiser4
. Also while thec
flag can set onext4
it is not honoured. There may also be tuning/mount options that affect these flags, but I couldn't find any.It does however seem that currently
chattr
is the only utility on Linux capable of modifying these attributes and so no copy utility is capable of preserving them.Original Answer
The reason for
rsync
seems to be that is doesn't even try. From the-X
section of thersync
documentation:It is difficult to map the attribute letters used byThe other two namespaces not mentioned in thechattr
andlsattr
to the underlying named attributes used in the filesystem (for one there is no list on the internet). From my tests though, theA
attribute maps to thesystem.posix_acl_access
attribute and since this is thesystem
namespace,rsync
won't even try to copy it.man
snippet aretrusted
andsecurity
, root privileges are required to set these (andrsync
won't try without).Most likely the attributes you have tried to set fall in the
system
namespace whichrsync
ignores (and probably wisely). Either that or you need to be root to get the ones that aren't.As forRunningcp
, there appears to be bugs at play.strace
oncp -a
, I get the following two interesting lines:and
Firstly thefgetxattr
call doesn't return any data (probably because there isn't any - the existence of the attribute is enough), yet somehowcp
finds 28 bytes of (junk?) data to set as the attribute value in the destination file. This seems like a bug incp
, but rather what is causing the issues seems to be a bug inlibattr
as thefsetattr
call returns0
for success without actually setting the attribute.I get this behaviour on
ext4
regardless of whether I mount withuser_xattr
. I can't find any documentation on this other than to say that 'some systems' need this mount option for extended attributes to work. Seemingly mine (Debian Jessie) doesn't. Even there is a mounting issue I have missed, it is wrong forfsetattr
and thuscp
to fail silently.Actually
user_xattr
is needed onext2
,ext3
,reiserfs
and possibly some others. It is not necessary forext4
Note also that the
attr
toolssetfattr
,getfattr
andattr
(the latter is documented to be only forXFS
only, but seems to work just as well as the others forext4
) have problems working in anything but theuser
namespace. I getOperation not supported
if I try to usesetfattr
to put an attribute in the thesystem
namespace (or no namespace as per this bug).setfattr
appears to succeed in thetrusted
andsecurity
namespaces, but thengetfattr
fails to read anything back and also fails to read anything from thesystem
namespace set bychattr
. The reason thatchattr
succeeds is that it uses anioctl
call and notlibattr
.What does work perfectly though, is setting extended attributes in the
user
namespace withsetfattr
and usingrsync
orcp
to copy with them intact (there are even no issues withcp
if you don't specify a value when creating the attribute). I think the bottom line is that usingsystem
namespace values is currentlybuggy and/orunsupported, at least in Debian and probably other distros too. Likely thersync
developers know this, which is why they ignore them.