Upgrade Apache Commons Compress to 1.15

[plamentotev]

It brings some fixes and most importantly should fix #57

[plamentotev]

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]

Are you having the same null character issue? Compress 1.15 seems to be broken for me.

[plamentotev]

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:

            if ( ze.isUnixSymlink() )
            {
                ZipEncoding enc = ZipEncodingHelper.getZipEncoding( getEncoding() );
                final byte[] bytes = enc.encode( symlinkDestination ).array();
                payload = new ByteArrayInputStream( bytes );
                zOut.addArchiveEntry( ze, createInputStreamSupplier( payload ), true );
            }

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.

[michael-o]

Correct, I see several null chars in the debugger.

[michael-o]

@plamentotev Are you talking about Buffer#limit()?

[plamentotev]

Yes. I've made a merge request with the fix and the upgrade - #72