zip4j: ZipException while extracting in version 2.1.x, but works fine in 1.x

Hello,

I´m getting the following exception while extracting using 2.1.2. The same file works fine in 1.3.3. I also checked the file with unzip -t and with WinZIP and 7z -> no problems there.

 Caused by: net.lingala.zip4j.exception.ZipException: Reached end of entry, but crc verification failed for {--file--}
 	at net.lingala.zip4j.io.inputstream.ZipInputStream.verifyCrc(ZipInputStream.java:240) ~[zip4j-2.1.1.jar!/:na]
 	at net.lingala.zip4j.io.inputstream.ZipInputStream.endOfCompressedDataReached(ZipInputStream.java:154) ~[zip4j-2.1.1.jar!/:na]
 	at net.lingala.zip4j.io.inputstream.ZipInputStream.read(ZipInputStream.java:122) ~[zip4j-2.1.1.jar!/:na]
 	at java.base/sun.nio.cs.StreamDecoder.readBytes(Unknown Source) ~[na:na]
 	at java.base/sun.nio.cs.StreamDecoder.implRead(Unknown Source) ~[na:na]
 	at java.base/sun.nio.cs.StreamDecoder.read(Unknown Source) ~[na:na]
 	at java.base/java.io.InputStreamReader.read(Unknown Source) ~[na:na]
 	at java.base/java.io.Reader.read(Unknown Source) ~[na:na]
 	at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:2001) ~[commons-io-2.4.jar!/:2.4]
 	at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1980) ~[commons-io-2.4.jar!/:2.4]
 	at org.apache.commons.io.IOUtils.copy(IOUtils.java:1957) ~[commons-io-2.4.jar!/:2.4]
 	at org.apache.commons.io.IOUtils.copy(IOUtils.java:1907) ~[commons-io-2.4.jar!/:2.4]
 	at org.apache.commons.io.IOUtils.toString(IOUtils.java:778) ~[commons-io-2.4.jar!/:2.4]
 	at de.xxx.xxx.helper.ExtractImport.content(ExtractImport.java:90) ~[classes!/:1.5.0-SNAPSHOT]
 	... 14 common frames omitted
final Map<String, String> data = new HashMap<>();
final Charset charset = Charset.forName("Cp1252");

tempFile = createTempFile(bin);
ZipFile zipFile = new ZipFile(tempFile, password.toCharArray());
ZipInputStream zis;

final Map<String,FileHeader> fileheaders = zipFile.getFileHeaders()
        .stream()
        .collect(toMap(FileHeader::getFileName, Function.identity()));
...
for(Map.Entry<String,IBaseModel> file: toParseFiles.entrySet()) {
    final String filename = file.getKey();
    final FileHeader fileHeader = fileheaders.get(filename);

    if(fileHeader == null) {
        ...
    } else {
        zis = zipFile.getInputStream(fileHeader);
        data.put(filename, IOUtils.toString(zis, charset));
        zis.close();
    }
}

and…Thanks for your great work!

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 27 (16 by maintainers)

Commits related to this issue

Most upvoted comments

On some more thoughts, I think I can do something in zip4j to overcome this. Although I will still say that the root cause of this issue is in the .NET application, but I think a small workaround can be done in zip4j without causing much harm to the valid zip files. I will update this thread again soon.

I just verified that the work around (in version 2.1.4) for the ZipFile mode works with the corrupt files we get from our data provider. thank you

@JensSchliesser @jochenr Fix for this issue is now released (v2.1.4). Please note that this will work only when using ZipFile api. It will still fail for zip files with such missing header blocks when using ZipInputStream api. In this case, unfortunately, there is nothing I can do to work around this issue.