[haiku-development] Re: Proposal and questions: Support of BFS attributes in TAR archiver.
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 23 Oct 2012 18:12:13 +0200
FranÃois Revol wrote:
> On 23/10/2012 12:47, Ingo Weinhold wrote:
> > 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).
> > An exception are BFS attributes with the type B_XATTR_TYPE;
> > for those the name is identity mapped. In the other direction (xattr
> -> BFS attribute)
> > the scheme is simply reversed, i.e. the encoded (type, name) pair is
> decoded and for
> > genuine xattr attributes the name is identity mapped and they get the
> type B_XATTR_TYPE.
> >
> > Ideally our ported FS modules that support xattrs (ext*, ReiserFS,...)
> > would implement the same scheme.
> > That would e.g. make it possible to rsync to a remote Linux, reboot
> that machine to Haiku and read the
> > typed attributes as they were originally. If tar supported xattr on
> other systems and would use the same
> > name/type encoding scheme all kinds of roundtrips were possible, which
> would be very nice IMO.
>
> Except this scheme alone won't work when files are moved across other
> non-linux filesystems, cf.
> http://dcpapers.dublincore.org/index.php/pubs/article/view/3633
Yes, such a scheme would be nice. Alas it needs to be implemented on all
platforms. If there only were a Haiku developer who cares enough to start with
that in Haiku. :-P
> Known attributes like the MIME type could be converted directly to the
> corresponding linux one though, cf.
> http://www.freedesktop.org/wiki/CommonExtendedAttributes
> http://www.freedesktop.org/wiki/Specifications/shared-filemetadata-spec
I'm a bit skeptical about that. Such a mapping would also have to happen in FS
implementations which are supposed to store data without interpreting them
semantically. I already dislike the extension based file type attribute faking
in our FAT implementation.
CU, Ingo
Other related posts:
