(unknown)

> On Wed, Aug 03, 2011 at 11:17:59PM
> +0100, Hin-Tak Leung wrote:
> 
> > The summary of the problem is that, git-archive's
> "--format=tar"
> > option really write the pax format most of the time,
> and some
> > cross-platform archive extraction library (rather than
> the
> > all-powerful GNU tar) really does not think that's the
> tar format and
> > bail out.
> 
> Out of curiosity, what is the library? Putting pax headers
> into ustar
> format has been standardized in POSIX since 2001.

> That header contains useful information (the commit id from
> which the
> archive was generated). And there is a way to turn it off:
> give a tree
> id instead of a commit id. There is an example in the
> git-archive
> manpage that does exactly this already. Look for the
> example mentioning
> "pax header" here:
> 
>   http://www.kernel.org/pub/software/scm/git/docs/git-archive.html
> 
> It might be a bit more obvious to find if we actually had
> a
> --no-pax-header option, though.
> 
> -Peff
> 

> --- On Thu, 4/8/11, Jeff King <peff@peff.net> wrote:
>> Out of curiosity, what is the library? Putting pax headers into
>> ustar format has been standardized in POSIX since 2001.
> 
> The R people wrote their own in the R language (and the person who
> responded to my post in that R-devel thread was possibly the one who
> wrote that part, I believe) - The main reason is probably
> cross-platform-ness and independence from other programming languages
> - they are gradually moving away from invoking system() (because they
> need to run on windows and they used to require many cygwin/mingw
> tools to build add-on packages).
> 
> The R code which does that, scan for certain patterns after seek()
> into the gunzip'ed stream after 512(?) bytes. It is in a file 
> R/src/library/utils/R/tar.R under the source repository.

> Ah, here it is:
> 
>   https://svn.r-project.org/R/trunk/src/library/utils/R/tar.R
> 
> It's the ctype handling in function untar2 that rejects
> unknown entry types.
> 
> For reference, the documentation of the pax format
> including a
> suggestion to treat unknown types like regular files can be
> found here
> (search for "typename"):
> 
>   http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html
> 
> > I think I tried the tree example and the R code also
> didn't like it
> > much... may be I'll give it another try.
> 
> Did you try adding a ":" to the tree argument, e.g. this:
> 
>     $ git archive HEAD:
> 
> instead of this?
> 
>     $ git archive HEAD
> 
> René

> --- On Thu, 4/8/11, René Scharfe <rene.scharfe@lsrfire.ath.cx>
> wrote:
> 
>> From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
> <snipped>
>> Ah, here it is:
>> 
>> https://svn.r-project.org/R/trunk/src/library/utils/R/tar.R
>> 
>> It's the ctype handling in function untar2 that rejects unknown
>> entry types.
>> 
>> For reference, the documentation of the pax format including a 
>> suggestion to treat unknown types like regular files can be found
>> here (search for "typename"):
>> 
>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html
>> 
>>> I think I tried the tree example and the R code also
>> didn't like it
>>> much... may be I'll give it another try.
>> 
>> Did you try adding a ":" to the tree argument, e.g. this:
>> 
>> $ git archive HEAD:
>> 
>> instead of this?
>> 
>> $ git archive HEAD
>> 
>> René
> 
> That's better! With a HEAD: , that code does a lot of:
> 
> Warning in untar2(tarfile, files, list, exdir) : checksum error for
> entry 'file...'
> 
> for each file it tries to extract, but at least it is extracting the
> files. 

> 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.

> --- 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.
> -----------------