Copying EAs and ACLs

[jw schultz]

On Sun, Mar 09, 2003 at 10:31:16PM -0800, Ben Escoto wrote:
> >>>>> "JWS" == jw schultz <jw at pegasys.ws>
> >>>>> wrote the following on Sun, 9 Mar 2003 18:25:47 -0800
> 
>   JWS> What i do expect for the next few years is that almost all
>   JWS> files will have no EAs and that less than half will have ACLs.
>   JWS> I do however expect that ACL usage will affect entire trees
>   JWS> (setfacl -R -m) rather than scattered files.
> 
> Yes, this sounds likely to me also.  If so, it doesn't seem very
> important to apply the rsync algorithm to the contents of the EAs/ACLs
> - updating them as a whole if there is any change shouldn't be too
> inefficient.

My concern is not just the average use for the next year or
two.  The lead time from beginning development to general
use is more than a year.  Even with only scattered use rsync
should support more than just the average.  We should be
supporting the corner cases, the sites where every file has
long ACLs or huge EAs on every file.  Once people start
really using this stuff the efficiencies will matter.

> Also, if the ACL/EA information needs to be stored separately (because
> for instance the target system doesn't have ACL/EA capability), does
> it seem better then to use one big file, instead of, for instance, a
> whole tree of smaller files?  I was thinking that maybe the file's
> format could be the same as the (gzipped) output of getfattr/getfacl
> --recursive.  That would make things more compatible, but may be
> slightly inefficient compared to some other format.

I've considered the issue of storing EA/ACL data on
filesystems that don't support them.  With the possible
exception of rsyncd it gets really ugly fast.  Rsync is for
syncing arbitrary files and directory trees.  This means
that this info would have to be stored along with the
files.  For that you need magic files or directories that
don't collide with the real ones.  No thanks.  The
facilities not supported by the filesystem won't be
transferred.  If you want to have a repository that stores
ACLs or EAs you should use a filesystem that does.

> Also there may be
> no point if the getf[attr/acl] format is likely to change soon.

I don't see any sign of the formats changing.  I only see
two changes as probable.  One would be specifying either the
acl_t type or the format of the "contiguous, persistent data
item, the format of which is unspecified."  of the
acl_copy_ext() and acl_copy_int() functions.  The other
change would be for the proprietary platforms to add
compatibility interfaces.  Neither of these possibilities
negate the value of implementing support.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt