[
https://issues.apache.org/jira/browse/COMPRESS-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12690163#action_12690163
]
Sebb commented on COMPRESS-11:
------------------------------
Just to expand on the previous comment:
The problem is that the ArArchiveInputStream does not break the stream into
chunks - the read() methods should report EOF for each entry; getNextEntry()
then allows read() to continue to the end of the new entry.
BTW, all three read() methods update the "offset" variable - it looks like this
is a mistake.
> Ar doesn't delete correct
> -------------------------
>
> Key: COMPRESS-11
> URL: https://issues.apache.org/jira/browse/COMPRESS-11
> Project: Commons Compress
> Issue Type: Bug
> Reporter: Christian Grobmeier
> Assignee: Torsten Curdt
> Fix For: 1.0
>
>
> When working on the Testcases i figured out that a deletion from an Ar
> Archive is not as successful as it look at first glance.
> For example: my bla.ar file contains test1.xml and test2.xml. I delete
> test2.xml
> The "getNextEntry" Method just delivers test1.xml. Looks correct.
> But checking the result file at commandline brings the following:
> $> ar -t /tmp/dir26673/bla.ar
> test1.xml
> test2.xml
> vi shows me that there is still the test2.xml entry in the archive,
> even when getNextEntry returns null.
> Deleting test2.xml and adding test.txt afterward brings the following:
> $> ar -t /tmp/dir24825/bla.ar
> test.txt
> ar: /tmp/dir24825/bla.ar: Inappropriate file type or format
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
