JDK-4681995 : Add support for large (> 4GB) zip/jar files
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: 1.4.0,1.4.2,5.0,6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    generic,solaris_9,windows_2000,windows_2003,windows_xp generic,solaris_9,windows_2000,windows_2003,windows_xp
  • CPU: generic,x86,sparc
  • Submitted: 2002-05-08
  • Updated: 2017-05-16
  • Resolved: 2009-04-11
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.
JDK 7
7 b55Fixed
Related Reports
Duplicate :  
JDK-8036982 - Backport 4681995 (large zip/jar support) to JDK6
Duplicate :  
JDK-6740544 - mismatch of signed, unsigned values causes mmap failure
Relates :  
JDK-6860950 - Unable to READ zip files more than 2GB in size
Relates :  
JDK-5084334 - Cannot handle zip files with more than 65535 files
Description

Name: jk109818			Date: 05/08/2002


FULL PRODUCT VERSION :
Java version 1.4.0

FULL OPERATING SYSTEM VERSION : Windows 2000


ADDITIONAL OPERATING SYSTEMS : Novell NetWare 6.0



EXTRA RELEVANT SYSTEM CONFIGURATION :
The Novell JVM for NetWare is ported from the Win32/Solaris
Java code base.

A DESCRIPTION OF THE PROBLEM :
Sun needs to add 64-Bit file support to  java.util.jar &
java.util.zip classes.  To do this, Sun needs to code to
the 64-Bit Zip file standard.  PKZip and WinZip now offer
products that can create, read, and manipulate zip files
that are greater than 4GB in length.  One of Novell's
products creates zip files that are greater (much greater)
than 4GB in size.  Sun needs to make sure that .jar files
can also be created in lengths greater than 4 GB.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Try to create or read a zip or jar file that is larger
than 4GB.

2.
3.

EXPECTED VERSUS ACTUAL BEHAVIOR :
I expected to be able to create a zip or jar file that is
greater than 4GB in length.  Sun has not used the 64-Bit
Zip file standard in the java.util.zip or java.util.jar
class libraries.

This bug can be reproduced always.
(Review ID: 146349) 
======================================================================
Comments
EVALUATION To support ZIP64 format, items listed below need to be updated in implementation (collected from the http://www.pkware.com/documents/casestudies/APPNOTE.TXT) (1)LOC compressed size: (4 bytes) uncompressed size: (4 bytes) If an archive is in ZIP64 format and the value in this field is 0xFFFFFFFF, the size will be in the corresponding 8 byte ZIP64 extended information extra field. (2)Data descriptor: crc-32 4 bytes compressed size 4 bytes uncompressed size 4 bytes When compressing files, compressed and uncompressed sizes should be stored in ZIP64 format (as 8 byte values) when a files size exceeds 0xFFFFFFFF. However ZIP64 format may be used regardless of the size of a file. When extracting, if the zip64 extended information extra field is present for the file the compressed and uncompressed sizes will be 8 byte values. (3)Central directory No explicit Zip64 notes here, specified in (6) (4)Zip64 end of central directory record zip64 end of central dir signature 4 bytes (0x06064b50) 0 size of zip64 end of central directory record 8 bytes 4 version made by 2 bytes 12 version needed to extract 2 bytes 14 number of this disk 4 bytes 16 number of the disk with the start of the central directory 4 bytes 20 total number of entries in the central directory on this disk 8 bytes 24 total number of entries in the central directory 8 bytes 32 size of the central directory 8 bytes 40 offset of start of centraldirectory with respect to the starting disk number 8 bytes zip64 extensible data sector (variable size) The value stored into the "size of zip64 end of central directory record" should be the size of the remaining record and should not include the leading 12 bytes. Size = SizeOfFixedFields + SizeOfVariableData - 12. (5)Zip64 end of central directory locator zip64 end of central dir locator signature 4 bytes (0x07064b50) number of the disk with the start of the zip64 end of central directory 4 bytes relative offset of the zip64 end of central directory record 8 bytes total number of disks 4 bytes (6) -Zip64 Extended Information Extra Field (0x0001): The following is the layout of the zip64 extended information "extra" block. If one of the size or offset fields in the Local or Central directory record is too small to hold the required data, a Zip64 extended information record is created. The order of the fields in the zip64 extended information record is fixed, but the fields will only appear if the corresponding Local or Central directory record field is set to 0xFFFF or 0xFFFFFFFF. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (ZIP64) 0x0001 2 bytes Tag for this "extra" block type Size 2 bytes Size of this "extra" block Original Size 8 bytes Original uncompressed file size Compressed Size 8 bytes Size of compressed data Relative Header Offset 8 bytes Offset of local header record Disk Start Number 4 bytes Number of the disk on which this file starts This entry in the Local header must include BOTH original and compressed file size fields. If encrypting the central directory and bit 13 of the general purpose bit flag is set indicating masking, the value stored in the Local Header for the original file size will be zero. (7) version needed to extract (2 bytes) --->[sherman: should we change it?] When using ZIP64 extensions, the corresponding value in the zip64 end of central directory record should also be set. This field should be set appropriately to indicate whether Version 1 or Version 2 format is in use. --------------------------------------------------------------- Whether or not we have zip64 end recorder & locator is decided by (8)-(13) below, but we actually only look at the last 4 I. End of central directory record: end of central dir signature 4 bytes (0x06054b50) number of this disk 2 bytes number of the disk with the start of the central directory 2 bytes total number of entries in the central directory on this disk 2 bytes total number of entries in the central directory 2 bytes size of the central directory 4 bytes offset of start of central directory with respect to the starting disk number 4 bytes .ZIP file comment length 2 bytes .ZIP file comment (variable size) ---------------------------------------------------------------- (8) number of this disk: (2 bytes) --->[sherman: do nothing] The number of this disk, which contains central directory end record. If an archive is in ZIP64 format and the value in this field is 0xFFFF, the size will be in the corresponding 4 byte zip64 end of central directory field. (9) number of the disk with the start of the central directory: (2 bytes) --->[sherman: do nothing] The number of the disk on which the central directory starts. If an archive is in ZIP64 format and the value in this field is 0xFFFF, the size will be in the corresponding 4 byte zip64 end of central directory field. (10) total number of entries in the central dir on this disk: (2 bytes) The number of central directory entries on this disk. If an archive is in ZIP64 format and the value in this field is 0xFFFF, the size will be in the corresponding 8 byte zip64 end of central directory field. (11) total number of entries in the central dir: (2 bytes) The total number of files in the .ZIP file. If an archive is in ZIP64 format and the value in this field is 0xFFFF, the size will be in the corresponding 8 byte zip64 end of central directory field. (12) size of the central directory: (4 bytes) The size (in bytes) of the entire central directory. If an archive is in ZIP64 format and the value in this field is 0xFFFFFFFF, the size will be in the corresponding 8 byte zip64 end of central directory field. (13) offset of start of central directory with respect to the starting disk number: (4 bytes) Offset of the start of the central directory on the disk on which the central directory starts. If an archive is in ZIP64 format and the value in this field is 0xFFFFFFFF, the size will be in the corresponding 8 byte zip64 end of central directory field.
08-04-2009
EVALUATION This will be considered for a future release. -- ###@###.### 2002/12/16
12-10-0182