It looks like we inadvertently introduced a regression in v1.2.0. It no longer correctly handles opening a PAX global header.

We still correctly record the presence of the pax_global_header entry in the tarfs entries map. However e.reader() returns an error for it when calling tr.Next().

Here's a tar.gz that exhibits the regression: https://github.com/helm/examples/archive/refs/tags/hello-world-0.1.0.tar.gz

Use tarfiles from https://github.com/golang/go/tree/master/src/archive/tar/testdata in the tests

Some tar files may have file entries with a path inside of a directory (eg dir1/file11), but miss corresponding directory entries (eg have no entry for dir1).

ping @mihaibuzgau @viovanov I saw both of you had forks to support this, I just released a v1.1.0 which supports this.

I've been a user of this library, and I find it really useful (thanks!).

However, I've noticed that the files within the tar are fully read into memory, even if the underlying reader supports io.ReaderAt. If the underlying reader does support io.ReaderAt, it seems like it would be a significant memory optimization to use io.SectionReader instead of bytes.Buffer, so that fs.FS operations could read file contents directly out of the reader.

Is this something that would be possible to explore in this library?

STEPS

1. Create an archive:

   mkdir empty_dir
   tar -cf fs_test_infinite_loop.tar -C empty_dir .

2. Walk the archive using fs.WalkDir function.

EXPECTED:
The walk function is called once.
OBSERVED:
The walk function is in an infinite loop.