[
https://issues.apache.org/jira/browse/COMPRESS-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15291470#comment-15291470
]
Jeremy Gustie commented on COMPRESS-356:
----------------------------------------
I can confirm the fix
[here|https://github.com/apache/commons-compress/compare/master...blackducksoftware:bug/COMPRESS-356-pax-header-trailing-slash-name]
works (alas, no tests).
> PAX header entry name ending with / causes problems
> ---------------------------------------------------
>
> Key: COMPRESS-356
> URL: https://issues.apache.org/jira/browse/COMPRESS-356
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.11
> Reporter: Jeremy Gustie
>
> 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:
> {noformat}
> docker pull centos:latest && docker save centos:latest | tar x --include
> "*/layer.tar"
> {noformat}
> Will produce at least one "layer.tar" that exhibits this issue. If I come
> across a smaller TAR for testing I will attach it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
