[haiku-development] Re: Proposal and questions: Support of BFS attributes in TAR archiver.
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 25 Oct 2012 13:31:53 +0200
Siarzhuk Zharski wrote:
> 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?
There's no endianess conversion happening in the xattr layer. ATM it's just a
different view on native attributes. I guess one could consider it an
export/import layer, which would rectify implementing endianess conversion
there as well. In that case I would recommend using little endianess, though,
since that would be compatible with existing data and little endian CPUs are
predominant anyway.
> 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.
> 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;
Yeah, that is baffling considering how long ago xattrs were introduced.
> 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?
As Stephan/you already wrote in the meantime this is really a pro. I think a
new option is needed to control whether xattrs shall be archived/extracted (not
sure, if opt-in or opt-out), but other than that the round-trip support is
great, I think.
CU, Ingo
Other related posts:
