Web lists-archives.com

Re: git archive generates tar with malformed pax extended attribute




On Fri, 24 May 2019 at 09:06, Jeff King <peff@xxxxxxxx> wrote:
>
> On Fri, May 24, 2019 at 08:45:23AM +0200, Keegan Carruthers-Smith wrote:
>
> > git archive can generate a malformed tar archive. bsdtar reports the
> > error "tar: Ignoring malformed pax extended attribute" when reading
> > the archive. Go's "tar/archive" package also reports the error
> > "archive/tar: invalid tar header". However, BusyBox's tar does not
> > report the error (unsure if it just has less error logging).
> >
> > I can reproduce this when generating the tar on linux and mac. I
> > tested this with "git version 2.21.0" and a build of next I did today:
> > "git version 2.22.0.rc1.257.g3120a18244"
> >
> > Reproduction:
> >
> >   $ git clone https://github.com/SSW-SCIENTIFIC/NNDD.git
> >   $ cd NNDD
> >   $ git archive --format tar c21b98da2ca7f007230e696b2eda5da6589fe137
> > | tar tf - > /dev/null
> >   tar: Ignoring malformed pax extended attribute
> >   tar: Error exit delayed from previous errors.
>
> I can't reproduce on Linux, using GNU tar (1.30) nor with bsdtar 3.3.3
> (from Debian's bsdtar package). What does your "tar --version" say?

bsdtar 2.8.3 - libarchive 2.8.3

> Git does write a pax header with the commit id in it as a comment.
> Presumably that's what it's complaining about (but it is not malformed
> according to any tar I've tried). If you feed git-archive a tree rather
> than a commit, that is omitted. What does:
>
>   git archive --format tar c21b98da2^{tree} | tar tf - >/dev/null
>
> say? If it doesn't complain, then we know it's indeed the pax comment
> field.

It also complains

  $ git archive --format tar c21b98da2^{tree} | tar tf - >/dev/null
  tar: Ignoring malformed pax extended attribute
  tar: Error exit delayed from previous errors.

Some more context: I work at Sourcegraph.com We mirror a lot of repos
from github.com. We usually interact with a working copy by running
git archive on it in our infrastructure. This is the first repository
that I have noticed which produces this error. An interesting thing to
note is the commit metadata contains a lot of non-ascii text which was
my guess at what my be tripping up the tar creation.

Keegan