bug-tar
[Top][All Lists]
Advanced

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

Re: [Bug-tar] GNU tar generates malformed Pax attributes


From: Tim Kientzle
Subject: Re: [Bug-tar] GNU tar generates malformed Pax attributes
Date: Sun, 5 Jan 2014 11:12:21 -0800

On Jan 5, 2014, at 3:01 AM, Linda A. Walsh <address@hidden> wrote:

> Sorry for responding to this so far after the initial posting,
> but it caught my eye...
> 
> Joerg Schilling wrote:
>> Tim Kientzle <address@hidden> wrote:
>>> Quoting from ?IEEE Std 1003.1, 2013 Edition?
>>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html
>>>> An extended header shall consist of one or more records, each constructed 
>>>> as follows:
>>>> 
>>>> "%d %s=%s\n", <length>, <keyword>, <value>
>>>> 
>>>> The extended header records shall be encoded according to the ISO/IEC 
>>>> 10646-1:2000
>>>> standard UTF-8 encoding. The <length> field, <blank>, <equals-sign>, and 
>>>> <newline>
>>>> shown shall be limited to the portable character set, as encoded in UTF-8.
> ----
>       It is not entirely clear, but the "value" is not listed in the list of
> items that need to be UTF-8 encoded.
> 
>       Even though it says the extended header records shall be encoded in 
> UTF-8,
> it appears that the following line is designed to clarify which fields are to 
> be
> encoded in UTF-8.

The "portable character set" is a small subset of the Unicode
character set.  Among other details, these characters are all
represented as a single byte in UTF-8:
http://pubs.opengroup.org/onlinepubs/009696899/basedefs/xbd_chap06.html

So the language about "shall be limited to the portable character
set" is not clarifying which fields are in UTF-8 but rather putting
an additional restriction on those parts of each record.

But of course, practice matters more than standards,
and star and gtar are now storing raw binary blobs
in extended header records.  The rest of us will have
to adapt, I suppose.

> 
>> The next task for star is to implement NFSv4 ACL support for FreeBSD. From 
>> what I found in the net, there is currently no compatible NFSv4 ACL support 
>> on
>> Linux, so it currently seems to be a feature that only can be supported on 
>> OpenSolaris and FreeBSD.
> ----
>       Because SunOS didn't follow the only "standards" [sic] that were
> in existence at the time (the withdrawn POSIX standard).

As you mention, POSIX.1e was never ratified,
so we should all be working to support
NFSv4 ACLs, for which there is a proper ratified
standard.

Tim




reply via email to

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