On Wed, 2012-10-10 at 12:30 +0200, Joerg Schilling wrote: > Paul Eggert <[email protected]> wrote: > > > On 10/08/2012 08:52 AM, Pavel Raiskup wrote: > > > we are not able to store/restore extended attributes containing '=' > > > character in the keyword properly - same situation in star as our patch > > > uses the same approach. > > > > Can't we fix this by URL-encoding '=' and '%' when creating the tar file > > and URL-decoding when extracting? It sounds easy, but it's not done > > by that patch, so what am I missing? > > What is the problem?
Jörg, the problem is here: $ touch FILE $ setfattr -n 'user.=N=A=M=E=' -v VALUE FILE $ star H=exustar -xattr -c -f example.star FILE star: 1 blocks + 0 bytes (total of 10240 bytes = 10.00k). $ cat example.star [snip] 70 SCHILY.xattr.security.selinux=unconfined_u:object_r:user_tmp_t:s0 37 SCHILY.xattr.user.=N=A=M=E==VALUE [/snip] ^ this is the problem During extraction, the very first occurrence of '=' is interpreted like pax header KEY/VALUE splitter - both in star/patched GNU tar. > Given that these xattrs are just name=value tags, shouldn't '=' be foibidden > in xattrs? As Tim said, xattr keyword may contain anything except '\0' character. > - Are there really such tags? > > - The original implementaion was developed together with SuSE, so why was > there no such problem for SuSE? Nobody complained problems even in our implementation. Pavel
