rsync and extended attributes

jw schultz jw at
Sat Feb 22 09:46:18 EST 2003

On Fri, Feb 21, 2003 at 11:12:11AM -0800, Eric Chen wrote:
> Hi,
> Right now rsync is unable to preserve extended attributes when copying
> files. I want to be able to copy files over from one XFS Linux machine to
> another XFS Linux machine running redhat 7.1 kernel 2.4.19-xfs-1.1 on an
> i686 over the network and I thought rsync would be better because it
> supports incremental backup. Also, rsync supports symlinks, while file copy
> using rcp, scp, and smbfs do not.
> I was wondering if you knew where rsync does the actual file copy/transfer
> so I could try to add extended attribute functionality. I was thinking about
> adding code that is similar to getfattr and setfattr to rsync so that when a
> file is copied/transfered, the attributes are saved (getfattr), the file is
> copied/transferred, then the attributes are restored (setfattr). I'm not
> sure if this is a good approach to doing this task, so if anyone has
> comments or suggestions, please let me know. If anyone has been working on
> this type of project, please get in touch with me because I will be more
> than willing to help out.

I'm afraid it isn't that simple.  I wish it were.  Adding
this capability requires a significant protocol change.
We do not wish to make such a change in a way that
fails to support all the supportable filesystems and OSs.

The most pertinant info is this paragraph from the manpage:
| In the XFS filesystem, the names can be up to 256 bytes in
| length, terminated by the first 0  byte.   The intent  is
| that  they  be  printable  ASCII  (or other character set)
| names for the attribute.  The values can be up to 64KB  of
| arbitrary binary data.

There are several issues that need to be addressed to do
this in a sustainable way.

1) Do we provide an auxilliary mechanism such as an extra
file (what name?) for storing the EAs and/or ACLs on
filesystems that don't support them?

2) Do we use rsync algorithm on the extended attributs?
Some have the potential to be quite long (up to 64KB on
XFS).  Treating them as a file as (1) would indicate
simplifies this somewhat.  What about the aggegate EA size
for a file.

3) we should deal with ACLs at the same time and with same
mechanism.  And most likey use checksums here as well to
compare rather than transmit the data unneeded.  Treatment
of this may have some issues with regard to varying semantics.
ALCs would have to be filtered of the basic perms to avoid
sending ACLs for every file even when none have been added.
We also should be sure to filter the ACLs from the EAs when
that is the local method of storing them.

4) What to do when EAs overflow the allowed size on the
destination filesystem?

No doubt there are more issues than these and i've only just
grazed the surface even with these four.

For now i would suggest you use the recoursive
getfattr/setfattr commands and incorporate them in a wrapper

	J.W. Schultz            Pegasystems Technologies
	email address:		jw at

		Remember Cernan and Schmitt

More information about the rsync mailing list