You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After the upgrade there is a test failing so I'll postpone the upgrade until the issue is found and resolved. I'll debug it to see where the problem is.
I think we have the same issue in mind. ZipArchiverTest#testSymlinkArchivedFileSet fails because the symlinks in the resulting archive does have several null characters at the end. Do you encounter the same issue?
I found the root cause. In AbstractZipArchiver#zipFile there is the following code:
The offender is enc.encode( symlinkDestination ).array();. Accordion to the ZipEncoding#encode Javadocs the returned "...byte buffer is positioned at the beginning of the encoded result, the byte buffer has a backing array and the limit of the byte buffer points to the end of the encoded result." We take the whole backing array. We should take its content up to the limit instead. Commons Compress 1.15 returns different ZipEncoding implementation(compared to 1.14) when ZipEncodingHelper.getZipEncoding( getEncoding() ) is called and that is why the bug manifests with the upgrade.
I'll submit a fix tomorrow after I double check that we don't have the same bug somewhere else in the code.
Activity
plamentotev commentedon Oct 18, 2017
After the upgrade there is a test failing so I'll postpone the upgrade until the issue is found and resolved. I'll debug it to see where the problem is.
michael-o commentedon Oct 19, 2017
Are you having the same null character issue? Compress 1.15 seems to be broken for me.
plamentotev commentedon Oct 19, 2017
I think we have the same issue in mind.
ZipArchiverTest#testSymlinkArchivedFileSet
fails because the symlinks in the resulting archive does have severalnull
characters at the end. Do you encounter the same issue?I found the root cause. In
AbstractZipArchiver#zipFile
there is the following code:The offender is
enc.encode( symlinkDestination ).array();
. Accordion to theZipEncoding#encode
Javadocs the returned "...byte buffer is positioned at the beginning of the encoded result, the byte buffer has a backing array and the limit of the byte buffer points to the end of the encoded result." We take the whole backing array. We should take its content up to the limit instead. Commons Compress 1.15 returns differentZipEncoding
implementation(compared to 1.14) whenZipEncodingHelper.getZipEncoding( getEncoding() )
is called and that is why the bug manifests with the upgrade.I'll submit a fix tomorrow after I double check that we don't have the same bug somewhere else in the code.
michael-o commentedon Oct 19, 2017
Correct, I see several null chars in the debugger.
michael-o commentedon Oct 20, 2017
@plamentotev Are you talking about
Buffer#limit()
?plamentotev commentedon Oct 21, 2017
Yes. I've made a merge request with the fix and the upgrade - #72