Re: [rdiff-backup-users] ACLs/EAs (who is the audience?)

[Ben Escoto]

>>>>> "GF" == Greg Freemyer <address@hidden>
>>>>> wrote the following on Mon, 3 Mar 2003 11:53:02 -0500

  GF> ACL/EA support varies greatly between filesystems, so the only
  GF> way to fully mirror ACL/EA info is to require that you have the
  GF> same FS on each end.

  GF> FYI: Even worse, the xfs release from a year ago only supported
  GF> 12 EAs I believe.  The current release supports 25 I believe.
  GF> So your going to have to require the same FS and FS release.

  GF> Any attempt to mirror ACL/EAs will also likely be the source of
  GF> lots of bug reports and other confusion.

  GF> Even if that is your long term goal, it seems like overkill for
  GF> an initial release.

Yes, good points.  How about this as a first step then:  rdiff-backup
would support something like --record-acls and --record-eas-and-acls
switches.  These would cause rdiff-backup to save the ACL and EA
information on the source side, but it wouldn't attempt to actually
read/write ACLs or EAs on the destination side.

The ACLs and EAs would just be stored in text files on the remote
side.  I hear that linux considers ACLs a special kind of EA, so we
could use linux's system to store ACLs as EAs.  From Schultz' email I
get the idea that he expects EAs and ACLs to get big.  So maybe there
could be a separate rdiff-backup-data/extended-attributes tree with
the same structure as the mirror directory, but the files contain the
extended attributes instead of the regular data.  The format of each
file could be similar to the format of the mirror_metadata file now.
Also <basename>.<time>.diff and <basename>.<time>.snapshot files could
be written to compress differences in the same way they do now for
regular data.

Or maybe I should stick all the EA information in one huge file and
gzip it.  Anyone see why one would be better than the other?

As Greg said, we can add more ACL support later.  However, we don't
want to make any mistakes now that make future work harder.  Any
comments on this plan?


-- 
Ben Escoto

pgpwH74DDqh80.pgp
Description: PGP signature