Copying EAs and ACLs
agruen at suse.de
Mon Mar 10 20:18:13 EST 2003
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.
More information about the rsync