Copying EAs and ACLs

[Andreas Gruenbacher]

On Monday 10 March 2003 08:20, jw schultz wrote:
> 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.

I recommend not to use the _ext() functions. There is no definition of the 
format at all, so it may not even be portable between two systems with 
different endianness, let alone different OS'es. I would use either the NFSv4 
format, or else the acl_to_text() format.

--Andreas.