On Jan 5, 2014, at 3:01 AM, Linda A. Walsh <g...@tlinx.org> wrote: > Sorry for responding to this so far after the initial posting, > but it caught my eye... > > Joerg Schilling wrote: >> Tim Kientzle <kient...@acm.org> 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