mtree: add xattr support #1400
mtree: add xattr support #1400
Conversation
|
While testing this I've discovered what might be considered a bug: when writing SCHILY.xattr PAX attributes, libarchive urlencodes the xattr name, but when reading back SCHILY.xattr it doesn't decode the name. LIBARCHIVE.xattr urlencodes and decodes the xattr name. As far as I can tell schily-tools tar does not perform any sort of encoding on the name (similar to the value) but considers it a string (so it must not contain a NUL). |
|
Please don't put functions into header files. |
This adds support for optionally writing xattrs to mtree output, and limited ability to read them from mtree input. The format of the keyword is the following, one for each xattr present for the entry: xattr.<name>=<b64 encoded value> This format is inspired by go-mtree by Vincent Batts, though there is a possible slight incompatibility: libarchive's existing base64 encoder does not perform padding because it was written to encode xattrs into PAX attributes which already have a length component. The decoder should accept padding ok, but the mtree parser may not like the unescaped '=' characters. The name is escaped according to existing mtree escaping practices which is octal encoding of [^!-}] except [ #=\] is also encoded. go-mtree performs its own implementation of vis(3) on it with the flags VIS_WHITE, VIS_OCTAL, and VIS_GLOB. There is some disjointedness here but it should be compatible in the common case of no escaping of course. Note that for output this is gated on --options=mtree:xattrs, which I've left out of the default mtree options. So far I've tested converting a PAX file directly to mtree with bsdtar and it seems to work well. todo: * when reading an mtree, also fill in xattrs from disk if available - this is tricky... * PAX tar files made by libarchive default to putting both the LIBARCHIVE and SCHILY PAX attributes in order to encode xattrs, but this causes libarchive to store the same xattr twice internally. Therefore if converting directly from PAX to mtree you get duplicated xattrs in the output. I don't think there's any easy way to fix this other than changing how libarchive keeps track of xattrs internally.
|
@mmatuska I've moved the functions to |
|
I think I could add grabbing xattrs from disk (when |
|
For PAX->mtree etc. duplicate xattrs issue it is a minor problem but it could potentially be fixed by storing xattrs on archive entries as a hash table with last one wins semantics instead of a linked list, but I'd probably do that in a separate PR. |
| char * | ||
| base64_decode(const char *s, size_t len, size_t *out_len) | ||
| { | ||
| static const unsigned char digits[64] = { |
There was a problem hiding this comment.
Seems identical to the digits[] in encode. If so, let's move it to global scope while preserving the static const notation.
This adds support for optionally writing xattrs to mtree output, and
limited ability to read them from mtree input. The format of the keyword
is the following, one for each xattr present for the entry:
xattr.<name>=<b64 encoded value>This format is inspired by go-mtree by Vincent Batts, though
there is a possible slight incompatibility: libarchive's existing base64
encoder does not perform padding because it was written to encode xattrs
into PAX attributes which already have a length component. The decoder
should accept padding ok, but the mtree parser may not like the
unescaped
'='characters.The name is escaped according to existing mtree escaping practices which
is octal encoding of
[^!-}]except[ #=\]is also encoded. go-mtreeperforms its own implementation of vis(3) on it with the flags
VIS_WHITE, VIS_OCTAL, and VIS_GLOB. There is some disjointedness here
but it should be compatible in the common case of no escaping of course.
Note that for output this is gated on
--options=mtree:xattrs, which I'veleft out of the default mtree options.
So far I've tested converting a PAX file directly to mtree with bsdtar
and it seems to work well.
todo:
--[no-]xattrsthis is tricky...
LIBARCHIVE and SCHILY PAX attributes in order to encode xattrs, but
this causes libarchive to store the same xattr twice internally.
Therefore if converting directly from PAX to mtree you get duplicated
xattrs in the output. I don't think there's any easy way to fix this
other than changing how libarchive keeps track of xattrs internally.
mtree(5)Comments and suggestions welcome! I'm opening this now to see if this is something upstream is interested in before I go further.