On Wed, 2012-10-10 at 12:42 +0200, Joerg Schilling wrote: > Pavel Raiskup <prais...@redhat.com> wrote: > > > > 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. > > > > Jorg, the problem is that the character '=' may really cause problems. > > Stored xtended keyword and value are binary clean but there is no > > unambiguous method how to restore xattr pax header when the keyword > > contains '=' character(s). > > > > Do you think that the solution here is suitable also for star? > > > > http://lists.gnu.org/archive/html/bug-tar/2012-10/msg00025.html > > > > I definitely don't want to make any incompatibilities in that case between > > GNU tar and star -- but I think that this issue has to be solved somehow. > > Do you have a better idea? > > AFAIK, the Linux xattr names are not living in the filesystem but inside > files, > so I would assume that there are other rules for them.
AFAIK, they resides in the filesystem on Linux. Thats the reason why linux xattrs have this low size limits comparing to NFSv4 standard. > A related OS implementation should from my view disallow '=' inside a the > name > of a name=value pair, but if this conceptional problem is not fixable at the > right location anymore, I would prefer to just encode '=' and '%'. There is probably no need to disallow '=' inside extended attributes keywords as the '=' may be encoded also inside separate files? The linux xattrs api would be able to encode/decode this informations... > I would prefer to just encode '=' and '%'. So do you think this solution is good enough? I also think that encode the whole keyword is not necessary. Would you be able to fix this also in star in future? Pavel
