stack install ghc-core fails because it mishandles special tar entries

[Blaisorblade]

stack install ghc-core fails, but stack build after cabal unpack ghc-core succeeds. Apparently it fails while trying to use setFileMode on file pax_global_header.
TL;DR. ghc-core's tarball contains an entry pax_global_header which does not represent a file, and stack incorrectly assumes all entries are files, so stack fails unpacking. It turns out that stack unpack ghc-core fails while cabal unpack ghc-core works. Such entries are valid, and git-archive creates them.

Investigation shows that

• pax_global_header is a special tar entry contains extra attributes; newer tar versions special-case it, older ones don't (see e.g. backdrop-ops/contrib#55 (comment))
• the tarball for ghc-core appears to contain a pax_global_header entry (confirmed e.g. through gzcat ghc-core-0.5.6.tar.gz| strings |grep pax_global_header, or with zcat on Linux).
• stack calls setFileMode on each entry in the tar file, without checking if they're real entries or not:
  https://github.com/commercialhaskell/stack/blob/master/src/Stack/Fetch.hs#L524-L532
• The tar package itself seems to mark these entries as with EntryContent = OtherEntryType ..., with specific type codes, see e.g.
  haskell/tar@6c0acf8.
• So stack should ignore the same entries — I'm just not sure how to do that without duplicating too much knowledge about the format from the Tar package. Looking at unpack (https://github.com/haskell/tar/blob/4557fdeab9363fcce16ed0be1f41eda022ba7c55/Codec/Archive/Tar/Unpack.hs#L77-L82), we might want to filter for entries of "type" (EntryContent) being NormalFile, Directory, HardLink, SymbolicLink.

Failing invocation:

$ stack install ghc-core
Run from outside a project, using implicit global project config
Using resolver: lts-6.6 from implicit global project's config file: /Users/pgiarrusso/.stack/global/stack.yaml
/private/var/folders/_7/hlxv4yv95x95vgnn416b4q4m0000gp/T/stack96236/pax_global_header: setFileMode: does not exist (No such file or directory)

Working:

$ cabal unpack ghc-core
Downloading ghc-core-0.5.6...
Unpacking to ghc-core-0.5.6/
# Standard setup (omitted)
$ stack build
ghc-core-0.5.6: configure
Configuring ghc-core-0.5.6...
ghc-core-0.5.6: build
Preprocessing executable 'ghc-core' for ghc-core-0.5.6...
[1 of 1] Compiling Main             ( ghc-core.hs, .stack-work/dist/x86_64-osx/Cabal-1.24.0.0/build/ghc-core/ghc-core-tmp/Main.o )
Linking .stack-work/dist/x86_64-osx/Cabal-1.24.0.0/build/ghc-core/ghc-core ...
ghc-core-0.5.6: copy/register
Installing executable(s) in
/Users/pgiarrusso/AeroFS/Mine/Sorgenti-Sync/Haskell/Stack-GHC-7.8.4/.stack-work/install/x86_64-osx/lts-0.7/7.8.4/bin

(At this point, stack install ghc-core seems to work in cases where it failed before in the same snapshot, but I haven't investigated). (EDIT: Given my setup that's not surprising).

[Blaisorblade]

I'm writing a patch.

I just investigated the set of possible entry types, according to the POSIX standard (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_02), and there are no surprises. The only uses of OtherEntryType defined there use typecode g and x, that are represented as OtherEntryType 'g' and OtherEntryType 'x'; no other values are possible.