[COMPRESS-87] ZipArchiveInputStream doesn't report the end of a truncated archive

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.0, 1.1
• Fix Version/s: 1.1
• Assignee: Stefan Bodewig
• Reporter: Antoni Mylka
• Created: 24/Oct/09 21:28
• Updated: 05/May/10 10:23
• Resolved: 30/Oct/09 05:30

Description

If a Zip archive is truncated, (e.g. because it is the first volume in a multi-volume archive) the ZipArchiveInputStream.read() method will not detect that fact. All calls to read() will return 0 bytes read. They will not return -1 (end of stream), nor will they throw any exception (which would seem like a good idea to me because the archive is truncated).

I have tracked this problem to ZipArchiveInputStream.java, line 239. It contains a check

if (read == 0 && inf.finished()) {
return -1;
}

For truncated archives the read is always zero but the inf is never finished(). I suggest adding two lines below:

if (read == 0 && inf.finished()) {
return -1;
} else if (read == 0 && lengthOfLastRead == -1) {
throw new IOException("Truncated ZIP file");
}

This solves the problem in my tests.

Issue Links

• is duplicated by: COMPRESS-96 Corrupt zip files can cause infinite loop