search

snoyberg / tar-conduit

Conduit based tar extraction mechanism
MIT License
8 stars 9 forks source link

Re #13 Add partial support for pax header blocks #34

Closed mpilgrem closed 1 year ago

mpilgrem commented 1 year ago

Relies on the extended description of the pax interchange format at https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html.

The basic idea is that untarChunks already produces a stream of TarChunk that include the pax header block and pax extended header information, so applyPaxChunkHeaders consumes those TarChunk to produce TarChunk in which that information has been applied.

The pax keywords that are supported ('comment', 'gid', 'gname', 'linkpath', 'path', 'size', 'uid' and 'uname') are those that do not need any change to the Header data constructor. (In practice, the motivation for this was the path keyword and long directory names and filenames. See https://github.com/commercialhaskell/stack/issues/6186#issuecomment-1642588255)

Tested (in a limited way) for the 'path' keyword (see https://github.com/mpilgrem/tar-pax-conduit, where the code was first formulated). The other keywords are based on my reasoning only.

EDIT: I re-thought the API. untarChunks and untar now produce 'processed' TarChunks and untarChunksRaw and untarRaw behave like the previous version of untarChunks and untar. I assume that the Haskell PVP requires a major version bump because of the changed behaviour.

mpilgrem commented 1 year ago

@snoyberg, I'll aim to add a test. Separately, looking at the CI, would you be interested in another pull request that (a) moves CI onto GitHub Actions; and/or (b) tests against more recent versions of GHC (given what you explained at: https://www.snoyman.com/blog/babies-oss-maintenance/)?

snoyberg commented 1 year ago

yes and yes, thanks!

mpilgrem commented 1 year ago

I have rebased on the master branch to reflect the new CI.

snoyberg commented 1 year ago

Uploaded tar-conduit 0.4.0 to Hackage.