JDK-4635869 : ZipInputStream fails to read certain valid zip archives
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2002-02-11
  • Updated: 2014-09-01
  • Resolved: 2002-09-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 mantisFixed
Related Reports
Relates :  
Description

Name: rmT116609			Date: 02/10/2002


FULL PRODUCT VERSION :
java version "1.4.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-rc-b91)
Java HotSpot(TM) Client VM (build 1.4.0-rc-b91, mixed mode)

also tested with:

java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.3.1-FCS)
Java HotSpot(TM) Client VM (build Blackdown-1.3.1-FCS, mixed mode)


FULL OPERATING SYSTEM VERSION :

The problem is reproducible on Linux Redhat 7.1(seawolf), Debian GNU/Linux 3.0 (woody) using 1.4.0-rc.

ADDITIONAL OPERATING SYSTEMS :

The problem is also reproducible on Windows 2000, Solaris2.8 using 1.4.0-rc.

The bug is expected to be visible on all other operating systems, as it is a bug in the ZipInputStream source and should not be platform-dependent.

A DESCRIPTION OF THE PROBLEM :
Background:

The ZIP file format
(http://www.pkware.com/support/appnote.html) allows for zip files to contain a data descriptor placed at the end of a zip entry.  This descriptor stores the crc32, compressed size, and uncompressed size of a zipfile member in the case
where these values could not be determined before writing the entry, and the underlying filehandle is not seekable. 

The format also allows for spanned or split archives, in which case a spanning marker is used to indicate split points in the file.

Problem:

java.util.zip.ZipOutputStream incorrectly inserts this spanning marker (ZipConstants.EXTSIG) before each data descriptor.  Most zip libraries silently ignore this, but ZipInputStream incorrectly assumes this marker will be present before each descriptor block, and fails with the following exception if it is not present:

java.util.zip.ZipException: invalid EXT descriptor signature
	at java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:348)
	at java.util.zip.ZipInputStream.read(ZipInputStream.java:144)
	at java.io.FilterInputStream.read(FilterInputStream.java:93)
	at java.io.InputStreamReader.fill(InputStreamReader.java:173)
        ...

The Java zip library therefore succeeds in being compatible with itself, but fails on certain legitimate zip files which do not include the (strictly speaking) out of place spanning marker.

An example of a zip file it fails with is located at:
http://muted.org/zip/test.zip

An explanation of how to create a similarly failing zip file is located at: http://muted.org/zip/index.html

It is possible to unzip and rezip the sample to "work around" the incompatability, but this is not always possible, and is not a true solution.  It merely takes the defective code out of the execution path, by creating a zip
file that does not use the descriptor block.

This may be the actual cause of other bug reports, such as numbers 4341580 and 4368886.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Retrieve the test zipfile from http://muted.org/zip/test.zip

2. Execute the sample code with test.zip in the current working directory.

EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected:
  Application prints "read from test.txt: hi".

Actual:
  Application throws java.util.zip.ZipException: invalid EXT descriptor signature

ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.util.zip.ZipException: invalid EXT descriptor signature
        at java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:345)
        at java.util.zip.ZipInputStream.read(ZipInputStream.java:141)
        at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:404)
        at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:442)
        at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:179)
        at java.io.InputStreamReader.read(InputStreamReader.java:167)
        at java.io.BufferedReader.fill(BufferedReader.java:136)
        at java.io.BufferedReader.read1(BufferedReader.java:187)
        at java.io.BufferedReader.read(BufferedReader.java:261)
        at ZipTest.main(ZipTest.java:18)

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.io.*;
import java.util.zip.*;

public class ZipTest {

  public static void main(String[] args) {
    try {
      FileInputStream is = new FileInputStream("test.zip");
      ZipInputStream zis = new ZipInputStream (is);

      for (ZipEntry entry = zis.getNextEntry(); entry != null; entry = zis.getNextEntry()) {
        BufferedReader reader = new BufferedReader(new InputStreamReader(zis));

        int len = 0;
        char[] buf = new char[512];
        StringBuffer sb = new StringBuffer();

        while ((len = reader.read(buf, 0, buf.length)) > -1)
          sb.append(buf);

        System.out.println ("read from " + entry.getName() + ": " + sb);
      }

      is.close ();
    } catch (Exception e) {
      e.printStackTrace();
    }
  }
}

---------- END SOURCE ----------
(Review ID: 139417) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis mantis-b02 FIXED IN: mantis mantis-b02 INTEGRATED IN: mantis mantis-b02 VERIFIED IN: mantis
14-06-2004

EVALUATION To be fixed.
11-06-2004

PUBLIC COMMENTS Now we allow ZipFiles with no markers. ###@###.### 2002-06-13
13-06-2002