Description
There seems to be a problem when a PAX header entry (link flag is 'x') has a name ending with "/". The TarArchiveEntry.isDirectory() check ends up returning true because of the trailing slash which means no content can be read from the entry. PAX header parsing effectively finds nothing and the stream is not advanced; this leaves the stream in a bad state as the next entry's header is actually read from the header contents.
If the name is modified to remove the trailing slash when the link flag indicates a PAX header everything seems to work fine. That would be one potential fix in parseTarHeader. Changing isDirectory to return false if isPaxHeader is true (before the trailing "/" check) would probably also fix the issue (though I can't verify that in the debugger like I can with changing the name).
So far I have only seen this when using Docker to save images that contain a yum database. For example:
docker pull centos:latest && docker save centos:latest | tar x --include "*/layer.tar"
Will produce at least one "layer.tar" that exhibits this issue. If I come across a smaller TAR for testing I will attach it.