[ 
https://issues.apache.org/jira/browse/COMPRESS-330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15125336#comment-15125336
 ] 

Dye357 commented on COMPRESS-330:
---------------------------------

Sorry for the long delay, I can't upload the tar in question since it contains 
private information - so I have been trying to synthetically manipulate a dummy 
tar file but so far I have been unable to reproduce the issue using the dummy 
tar file. I will try and spend some more time on this later this week. If I'm 
unable to reliably reproduce the issue I will close the ticket.

> 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)

Reply via email to