[
https://issues.apache.org/jira/browse/COMPRESS-330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15125381#comment-15125381
]
Stefan Bodewig commented on COMPRESS-330:
-----------------------------------------
Thanks [~dye357], please don't close the issue if there is a real problem. I
fully understand the problem of archives containing private information.
If you knew which tool generated the archive, maybe you could create a new
archive with dummy data using that tool. Otherwise it is pretty easy for us to
pick an arbitrary tar that contains a directory and manipulate the size
(getting the checksum to match is the only minor issue) - we can do so
ourselves. It's just that I'd personally prefer a real world archive.
> Tar UnArchive Fails when archive contains directory sizes which are non-zero.
> -----------------------------------------------------------------------------
>
> Key: COMPRESS-330
> URL: https://issues.apache.org/jira/browse/COMPRESS-330
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.10
> Environment: Java 1.8
> Reporter: Dye357
> Priority: Minor
> Attachments: Compress-330.patch
>
>
> Tar UnArchive Fails when archive contains directory sizes which are non-zero.
> I recently came across a set of files which failed to extract with
> commons-compress but I was able to successfully extract the files with GNU
> tar.
> The problem is TarArchiveInputStream.java gets the size of each entry in a
> tar archive to determine how many bytes to read ahead. Directories are always
> sized 0 bytes, however its technically possible a tar archive contains a size
> for a directory. This causes the Input Stream to loose it's place and
> eventually results in an exception being thrown.
> I was able to implement a proof-of-concept fix by checking if an entity is a
> directory and setting the directory size to 0. (A directory with Files in a
> Tar Archive still has a size of 0 as the directory itself does not have size
> in the archive.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
