bug-tar
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-tar] xattr support on Linux


From: Joerg Schilling
Subject: Re: [Bug-tar] xattr support on Linux
Date: Fri, 5 Oct 2012 12:46:25 +0200
User-agent: nail 11.22 3/20/05

Tim Kientzle <address@hidden> wrote:

> >> bsdtar also URL encodes the xattr name when building the pax property
> >> name.  This ensures the final key will be entirely ASCII (and hence will
> >> not cause any problems with readers that expect all keys to be valid 
> >> UTF-8).
> >> 
> >> I can point you to the code in libarchive that handles this if you want
> >> a detailed reference.  (The code is BSD-licensed; you're welcome
> >> to copy it if you wish.)
> > 
> > Mmm, is bsdtar incompatible to star?
> > 
> > Do you have a documentation for your format?
>
> https://github.com/libarchive/libarchive/wiki/TarExtendedAttributes

OK, then bstar is not compatible to star at this point.

BTW: converting name/value pairs with unknown meaning into something different 
(as UTF-8) may cause problems and is not needed as the meta data in extended 
tar headers is binary clean due to it's length tag.


> As mentioned there, I'm also missing documentation for
> star's xattr format.  In particular, I'm not clear how it handles
> non-ASCII bytes in the attributes name.

Thank you for this hint, I thought that I did document everything.....


In general, after ZFS added support for an in-kernel SMB implementation a few 
years ago, Solaris started _using_ extended attribute files (as defined by the 
NFSv4 standard). The additional metadata (such as DOS flags like "system") is 
hold in files:

        -r--r--r--   1 root     root         156 Oct  5 12:36 SUNWattr_ro
        -rw-r--r--   1 root     root         472 Oct  5 12:36 SUNWattr_rw

inside the attribute directory of a file. As you see, the name/value pairs are 
not at filename level but inside the files.

It seems that putting "further metadata" (which is what Linux calls xattrs) into
extended attribute files implements the only method that allows to share 
extended attributes via the network, but on Solaris uses vendor specific 
filenames 
and codings. 

Note that I was trying to get people together to discuss a OS-independent 
method for extended attribute handling since 2001 and I am still interested in 
this topic.

Jörg

-- 
 EMail:address@hidden (home) Jörg Schilling D-13353 Berlin
       address@hidden                (uni)  
       address@hidden (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily



reply via email to

[Prev in Thread] Current Thread [Next in Thread]