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

[Greg Freemyer]

 >>  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.

Samba treats ACLs as a ./configure parameter, not run time.  Maybe that would 
be better for rdiff-backup as well.

Also, I suspect you will need to just have --record-acls and --record-eas.  If 
someone wants both, they need to ask for both.

i.e.
My primary use for this feature is to backup samba exported Linux FSs.

For that situation, I need --record-eas xor --record-acls.

Either would work, but doing both would capture the ACLs twice.

Later on, I would like to run rdiff-backup on a Windows box and capture ACLs 
and EAs.

I think they are totally separate on NTFS, so I could use both.

NTFS support is likely to be pretty far down the road because the NTFS native 
ACLs and EAs are not available from cygwin.
 
 >>  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.

I agree in both senses of the word.  

They will be common and IIRC Linux supports each individual EA being 64K, so 
they could be large.

 >>  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.  

I like that idea.

 >>  file could be similar to the format of the mirror_metadata file now.

Linux EAs are simple name value pairs, where the value can be binary.

Does that make sense with your current format?

 >>  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.

That makes sense.

 >>  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?

I can see that growing to hundreds of megs or more.  Wouldn't it be slow to 
have to update that large a file due to a small EA change.

You will definitely be getting lots of small changes.

For instance, I use xfsdump to backup my samba shares currently.  xfsdump 
accepts a dump-level as an arg.

For every file it backs up, it modifies a dump-level EA.  So if I were to do:
   rdiff-backup --record-eas ...
   xfsdump ...
   rdiff-backup --record-eas ...

You could have thousands (tens of thousands, hundreds of thousands) of EA 
changes, but no data changes.

 >>  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


Greg
-- 
Greg Freemyer