Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/24
[](https://coveralls.io/builds/11469394)
Coverage increased (+0.09%) to 84.309% when pulling
**77f5ce3714e194704
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/24
@kvr000 what do you think about
https://github.com/apache/commons-compress/commit/620196621e15a87cdd5e3382504bd8a9829f4698
?
---
If your project is set up for it, you can reply to this ema
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/24
I don't see a chance of making it independent of `ZipArchiveOutputStream`,
you are certainly correct.
I was thinking along the lines of `ZipArchiveOutputStream` calculates the
lengt
Github user kvr000 commented on the issue:
https://github.com/apache/commons-compress/pull/24
@bodewig : Thanks for suggestions. There are definitely some pros with the
approach, especially if it reaches Zip RFC :-)
On the other hand, I don't think it could be made completely
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/24
Many thanks @kvr000
Have you thought about adding a class implementing `ZipExtraField` for
padding? You could add that to the entry if you detect padding is necessary and
could rem
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/24
[](https://coveralls.io/builds/11383081)
Coverage increased (+0.05%) to 84.279% when pulling
**e42d33b01848cd46c
