2) The large attributes issue that was already discussed in this
thread. Wiki says that "Unlike forks, which can usually be as large
as
the maximum file size, extended attributes are usually limited in
size
to a value significantly smaller than the maximum file size." Don't
we
get into troubles trying to use foreign API in the way it was not
initially designed for?
I only see two alternatives:
* Store attributes in a way that they will be ignored completely when
extracting the archive on other OSs.
* Store attributes as files, so that they the will be extracted as
(specially named) files on other OSs.
IMO the first alternative is worse than using xattrs in all respects,
since it makes round-trips (extract and re-archive on the other OS)
lossy for sure. The second alternative has a greater chance of being
lossless (as long as files aren't renamed/moved). It will clutter the
extracted file tree, though.
3) Because of libarchive design populating BFS attributes processing
to
other formats supported by libarchive like ZIP and RAR may require
"demangling" the attribute type and name back from the xattr name;
Yes, our zip and rar tools would need to support the same scheme
(they would automatically, if they supported the xattr interface). I
don't think that is an xattr con, though. Whatever scheme you
implement, the other tools would need to support it.
