rsync - Apr 2007 - xattrs questions

I see that rsync will eventually support extended attributes, which  
will be great.
But: will it allow backup from a file system that supports xattrs, to  
one that does not?
For this to work, rsync would have to represent the xattrs on the  
destination machine
in some special format, I suppose, which is outside the usual rsync  
mode of operation.

Moreover, even if both machines support xattrs, their might be  
restrictions and
subtle differences in semantics that could prevent one from directly  
mapping
an xattr on one machine to an xattr on another.  For example,  
com.apple.ResourceFork
on OSX may be arbitrarily large, and I could imagine that some  
filesystems may not allow
this.  I could also imagine that there may be restrictions on the  
names of xattrs that cause trouble.

So I wonder: has there been a clear discussion about what exactly  
rsync's xattr support is to be?
I can see that having an rsync that respected xattrs when both source  
and destination
have the same or very similar xattr semantics would be both desirable  
and sensible,
but I'm afraid that there may be no simple solution when the two  
filesystems take
radically different views on xattrs.

For example,  the approach taken by rdiff-backup may be
the most reasonable:  store xattrs on the foreign filesystem in a  
special archive, using rsync
to transport the data and the xattr archives.

Finally, why are filesystem designers doing this?  Do xattrs really  
make anyone's lives any better?
Indeed, they seem to break the age-old philosophy of Unix that a file  
is just data.
Of course, there have always been permission bits, which complicate  
matters (and BSD
went ahead and added more funny bits).  I can also understand ACLs.   
But any extra
data that goes beyond basic access control:  that should just be a  
separate file.
It seems that this xattr stuff is simply creating a tower of Babel  
that breaks interoperability....
and for what?

On Sat, Apr 07, 2007 at 07:13:16AM -0400, Victor Shoup
wrote:
> But: will it allow backup from a file system that supports xattrs, to  
> one that does not?
Not as currently envisioned.  It would not be hard to add some
compatibility code into lib/sysxattrs.c that would allow an alternate
storage method to be used via the regular xattr access functions.  For
instance, a DB access method could be configured into rsync that would
store records indexed by inode and xattr name.  However, I'm expecting
someone who wants to backup xattrs to supply a destination disk that
supports xattrs.
> Moreover, even if both machines support xattrs, their might be
> restrictions and subtle differences in semantics that could prevent
> one from directly  mapping an xattr on one machine to an xattr on
> another.
It's not expected that xattrs from one system type will be meaningful on
another, just stored.  There is already compatibility code in place that
makes sure that everyone is transmitting xattrs in a namespace, so Mac
xattrs get transmitted with a "user" namespace prefixed.  This allows
them to be backed up and restored between differing system types.  All
the implementations that I'm aware of allow arbitrary names in the user
namespace.

Rsync doesn't do anything to try to work around size restrictions
between differing implementations (just like it doesn't try to work
around differing path-length limits), so it will be up to the user
to make sure that their copy is possible.

If you see any problems/concerns with this, please feel free to discuss
them.  It would be nice to get them handled sooner rather than later.

..wayne..

On Sat, Apr 07, 2007 at 09:18:50AM -0700, Wayne Davison
wrote:
> There is already compatibility code in place that makes sure that
> everyone is transmitting xattrs in a namespace, so Mac xattrs get
> transmitted with a "user" namespace prefixed.
I should also point out that xattrs from non-user namespaces that get
sent to a Mac get stored inside a special rsync namespace.  This keeps
them from getting in the way of the "user" items on the Mac side, and
ensures that all the xattrs have the same values in a reverse copy.  The
"system" namespace is always ignored (since it holds things like ACLs
on
some systems), and non-user namespaces are only used if the receiver is
running with super-user privileges.  (See also the fake-super.diff in
the patches dir.)

..wayne..