Re: git-archive's wrong documentation: really write pax rather than tar

["René Scharfe" <rene.scharfe@lsrfire.ath.cx>]

Am 10.08.2011 05:08, schrieb Hin-Tak Leung:
> --- On Sat, 6/8/11, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> 
>> That doesn't sound good.  Looking at the R source,
>> however, I can see
>> that they use a two different algorithms to compute the
>> checksum than
>> the one specified by POSIX (even though I don't fully
>> understand what it
>> actually is their doing, since I don't know R).  So
>> worry too much about
>> the warning; as long e.g. "tar tf <file>" doesn't
>> complain your archive
>> should be intact.
> 
> I filed the bug,
> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14654
> and they have fixed it bug has a few comments to make:
> 
> ---------------
> Fixed in R-devel and patched (your checksum field has more than 6 digits which
> is highly unusual [since it can't be larger than 6 digits] but technically
> allowable).
> 
> I should add that the original tar format mandated that checksums are
> terminated by NUL SPACE, so in that sense your tar file is invalid (there can't
> be more than 6 digits since the checksum field consists of 8 bytes). untar2
> will now be more forgiving, but whatever program created that tar file should
> be fixed.
> -----------------

That's good to read, thanks.

> Please feel free to respond directly at the R bug tracking system, or
> I can cut-and-paste bits of e-mails also...

I don't think any further action is needed; there's nothing to fix.

There is not such thing as "the" tar archive format -- there are
multiple dialects.  While compatibility is important, ancient versions
of tar haven't been a target for git archive so far.

It creates files in the same format as POSIX pax.  I called it "tar"
instead of "pax" because the result can be extracted using GNU tar,
bsdtar, 7-Zip etc., supports long file names as well as symlinks -- and
I had never heard of anyone actually using the pax command, while tar is
quite common.  (And pax doesn't restrict the checksum to six digits.)

It would be interesting to know which other tar extractor insists on the
checksum being stored as six zero-padded octal digits followed by NUL
and SPACE instead of seven zero-padded octal digits followed by NUL,
though.  (Side note: I guess the reason for using only six digits is
that this enough for even the biggest possible header checksum.)

René