[
https://issues.apache.org/jira/browse/COMPRESS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483223#comment-13483223
]
Gary Gregory commented on COMPRESS-206:
---------------------------------------
If you take care of your relationship with patience and package the test and
fix into an SVN diff patch file, the likelihood of this issue being addressed
quickly will increase tremendously!
> TarArchiveOutputStream sometimes writes garbage beyond the end of the archive
> -----------------------------------------------------------------------------
>
> Key: COMPRESS-206
> URL: https://issues.apache.org/jira/browse/COMPRESS-206
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
> Affects Versions: 1.0, 1.4.1
> Environment: Linux x86
> Reporter: Peter De Maeyer
> Attachments: GarbageBeyondEndTest.java
>
>
> For some combinations of file lengths, the archive created by
> TarArchiveOutputStream writes garbage beyond the end of the TAR stream.
> TarArchiveInputStream can still read the stream without problems, but it does
> not read beyond the garbage. This is problematic for my use case because I
> write a checksum _after_ the TAR content. If I then try to read the checksum
> back, I read garbage instead.
> Functional impact:
> * TarArchiveInputStream is asymmetrical with respect to
> TarArchiveOutputStream, in the sense that TarArchiveInputStream does not read
> everything that was written by TarArchiveOutputStream.
> * The content is unnecessarily large. The garbage is totally unnecessarily
> large: ~10K overhead compared to Linux command-line tar.
> This symptom is remarkably similar to #COMPRESS-81, which is supposedly fixed
> since 1.1. Except for the fact that this issue still exists... I've tested
> this with 1.0 and 1.4.1.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
