[haiku-development] Re: Proposal and questions: Support of BFS attributes in TAR archiver.
- From: Siarzhuk Zharski <zharik@xxxxxx>
- To: <haiku-development@xxxxxxxxxxxxx>
- Date: Wed, 24 Oct 2012 23:08:30 +0200
Ingo Weinhold ÐÐÑÐÐ 23.10.2012 12:47:
BTW, Haiku has support for the GNU xattr API
(src/libs/gnu/xattr.cpp). That allows ported software that already
supports xattr (e.g. rsync) to be built without change. The xattr
support layer maps the BFS attribute and type according to the scheme
"user.haiku.<attrname>#<type>" to xattr attribute names (<type> is
either the four character variant, when all characters are printable
(isprint()) or an 8 char hex representation).
I have configured libarchive bsdtar to be build with xattr support and
can confirm that it stores and extract BFS attributes seamlessly.
Frankly speaking I'm not sure now about continuing implementation of
"native" BFS attributes support. May be we should count pros and contras
for both variants and decide what to do?
First of all let's look on the representation of keywords and values in
PaxHeaders area:
Using XATTR mapping:
58 LIBARCHIVE.xattr.user.haiku._trk/windwkspc#LONG=AgAAAA
74
LIBARCHIVE.xattr.user.haiku._trk/windframe#RECT=AACFRAAAOEIAgNpEAIAZRA
89
LIBARCHIVE.xattr.user.haiku.BEOS:TYPE#MIMS=YXBwbGljYXRpb24veC12bmQuQmUtZGlyZWN0b3J5AA
Using "native" representation:
55 HAIKU.BEOS:TYPE=SMIM application/x-vnd.Be-directory
64 HAIKU._trk/windframe=TCER 00C026440000AA420000A34400C07F4480
40 HAIKU._trk/windwkspc=GNOL 01000000FF
XATTR pros:
1) It is already implemented at least for libarchive;
2) It is implemented, tested and functional;
3) It is kind of standard way - so those data can be extracted in any
OS on any FS that supports such feature;
4) ???
XATTR cons:
1) Does it handle endiannes issues seamlessly too? Looks like this is
the our mapping code task, right?
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?
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;
4) AFAIK there are no support for xattrs in the official GNU tar
implementation and looks like it takes some time to appears in it;
5) BFS attributes, archived using xattr emulation can be restored on
any FS supporting such feature. Do we really want to populate foreign
file systems with BFS attributes?
6) ???
Thank you for attention and please share your meaning and arguments
about using any implementation you find more reasonable.
--
Kind Regards,
S.Zharski
Other related posts:
