Bug 2793 - xattr support fails with multiples attributes
xattr support fails with multiples attributes
Status: RESOLVED FIXED
Product: rsync
Classification: Unclassified
Component: core
2.6.9
All Linux
: P3 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-13 08:32 UTC by Pierre Dinh-van
Modified: 2006-10-25 20:17 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pierre Dinh-van 2005-06-13 08:32:43 UTC
When I try to use -X option with a patched rsync (using XFS as file system), I
obtain this when a file have multiple user attributes:

[root@Chakra data]# echo "test" > test_pierre/test.file 
[root@Chakra data]# setfattr -n user.test1 -v testval1 test_pierre/test.file 
[root@Chakra data]# setfattr -n user.test2 -v testval2 test_pierre/test.file 
[root@Chakra data]# getfattr test_pierre/test.file 
# file: test_pierre/test.file
user.test1
user.test2

[root@Chakra data]# rsync -AavX -P -W --numeric-ids --delete --force
test_pierre/ gargamel:/data/test_pierre/
building file list ... 
17608 files to consider
./
test.file
           5 100%    0.00kB/s    0:00:00  (1, 0.0% of 17608)
logs_test/
.test.file.cAW83c: rsync_xal_set: lsetxattr system.posix_acl_default failed: Not
a directory

sent 559013 bytes  received 78 bytes  65775.41 bytes/sec
total size is 5611168219  speedup is 10036.23
rsync error: some files could not be transferred (code 23) at main.c(791)

File is transmitted, but without its attributes.

If I remove an attribute, transmit seems to works fine...

[root@Chakra data]# setfattr -x user.test1 test_pierre/test.file 
[root@Chakra data]# getfattr test_pierre/test.file 
# file: test_pierre/test.file
user.test2

[root@Chakra data]# rsync -AavX -P -W --numeric-ids --delete --force
test_pierre/ gargamel:/data/test_pierre/
building file list ... 
17608 files to consider
./
test.file
           5 100%    0.00kB/s    0:00:00  (1, 0.0% of 17608)
logs_test/

sent 559013 bytes  received 78 bytes  58851.68 bytes/sec
total size is 5611168219  speedup is 10036.23

...but the attribute value and name is not ever kept in the other side :

[root@Chakra test_pierre]# getfattr -n user.test4 test.file3 
# file: test.file3
user.test4="testval4"

[root@Chakra data]# rsync -AavX -P -W --numeric-ids --delete --force
test_pierre/ gargamel:/data/test_pierre/
building file list ... 
17608 files to consider
test.file3
           5 100%    0.00kB/s    0:00:00  (1, 0.0% of 17608)
logs_test/

sent 559008 bytes  received 72 bytes  65774.12 bytes/sec
total size is 5611168219  speedup is 10036.43

[root@Gargamel test_pierre]# getfattr test.file3 
# file: test.file3
user.ARTE

[root@Gargamel test_pierre]# getfattr -n user.ARTE test.file3 
# file: test.file3
user.ARTE="h"

[root@Gargamel test_pierre]# getfattr -n user.test4 test.file3 
test.file3: user.test4: No such attribute

I set an attribute named "ARTE" for an other file in an other sync before. I
can't understand why it uses it now.
Comment 1 Matt McCutchen 2006-02-04 21:09:40 UTC
I can't reproduce this with CVS rsync.  I made test_pierre/test.file with the given attributes and values.  When I made a copy of test_pierre, the attributes were synchronized correctly, both with local rsync and with rsync over ssh to localhost.  I did notice, however, that rsync gets confused setting xattrs when copying a file to itself (i.e. rsync -X foo foo); this is a bug no one is ever likely to encounter in normal use, but perhaps it could be fixed.
Comment 2 Jörn Nettingsmeier 2006-08-07 11:07:16 UTC
for the record, this buglet persists in rsync-2.6.8 with acl and xattr patches enabled, and i reproduced it on two suse linux boxen (10.0/x86_64 and 10.1/i386).
would be nice to have it fixed, since it clutters the logs big time. seems to have vanished from the radar of the devs a little...
contrary to comment #1, i also see it on files with only one xattr.
Comment 3 Wayne Davison 2006-10-25 20:17:46 UTC
I just checked-in some fixes to the CVS version that were causing the xattr values to not get saved properly (the the bug was more obvious the more values you had).