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.

Upgrade Apache Commons Compress to 1.15 #71

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions