Release Notes for TrueZIP 6.7
(July 16th, 2010)
Introduction
This is a feature and bug fix release. Upgrading is recommended for all users.
Transparent ZIP64 Support
This is the first release which supports ZIP64 extensions as introduced in version 4.5 of PKWARE's ZIP File Format Specification when reading or writing ZIP archive files with the low level API in the package de.schlichtherle.util.zip . This enables client applications to read and write ZIP archive files of more than 4GB size or with more than 65535 entries.
Handling ZIP64 extensions is fully transparent for client applications, so there are no public API changes involved. The only noticeable difference is that the setters and getters for the properties size and compressedSize (and the package private offset) in the class de.schlichtherle.util.zip.ZipEntry can now accept and return values ranging from 0L to Long.MAX_VALUE. Since these properties already had the primitive type long, this enhancement does not affect the binary compatibility of the JAR for TrueZIP 6.7.
In order to retain maximum interoperability with third party tools, by default, ZIP64 extensions are written to a ZIP file only if they are required. Currently, TrueZIP's implementation of ZIP64 extensions is known to interoperate round trip (create, update, read in both directions) with WinZip 11.1 and 7-Zip 4.56. Older versions of WinZip may work, but have not been tested. Older versions of 7-Zip (namely 4.42) are known to have problems reading ZIP files with ZIP64 extensions; please upgrade your copy of 7-Zip accordingly.
If the system property de.schlichtherle.util.zip.zip64ext is set to true (case is ignored), then ZIP64 extensions are always added when writing a ZIP archive file, regardless of its size. This feature is intended for testing purposes only. During normal operations, it should not be set as many third party tools would not treat the redundant ZIP64 extensions correctly. Note that it's impossible to inhibit ZIP64 extensions.
Enhanced ZIP File Interoperability
Some improvements were made on the interoperability of ZIP files created by TrueZIP with third party tools.
A minor bug has been fixed which caused some tools like e.g. the Windows Explorer not to be able to treat directory entries correctly.
ZIP files utilize a simplistic date/time conversion algorithm which isn't detailed in the ZIP File Format Specification version 6.3.2 from September 28th, 2007. Hence, for ZIP files the date/time conversion of the package java.util.zip is not fully interoperable with tools like Windows Explorer, WinZip 12.0 or 7-Zip 4.65. Symptoms are time stamps which may differ by two seconds or even an hour if the daylight saving time has changed between the last modification time of an archive entry and the current system time.
In order to address this issue, TrueZIP's equivalent to the package java.util.zip in the low level interface package de.schlichtherle.util.zip now offers a new class, DateTimeConverter. This class is now used by the class ZipEntry in order to perform the date/time conversion. By default, JAR file date/time conversion is selected in order to maintain backwards compatibility to the JSE implementation. If an application utilizing the low level interface needs ZIP file date/time conversion however, then it needs to subclass ZipEntry and override the method getDateTimeConverter().
For the high level API in the package de.schlichtherle.io the ArchiveDrivers for the ZIP and JAR file family have been updated to select the appropriate date/time conversion automatically. So users of the high level API don't need to do anything in order to benefit from the enhanced interoperability.
For additional information, please check the change log below.
Legend | |
---|---|
New | Introduces a new feature. |
Fixed | Introduces a bug fix of an existing feature. |
Enhanced | Introduces the enhancement of an existing feature. This update is fully backwards compatible. |
Changed | Introduces the change of an existing feature. This update may cause backwards incompatibilities . |
Deprecated | Introduces the deprecation of an existing feature. |
List of Updates (Change Log)
Following is an overview of all updates in this release which affect the public API. Please note that internal refactorings are not listed. For a full list of updates, please refer to the CVS repository and diff to the tag TrueZIP-6_6.
Updates in the Default Package
- Deprecated: The command line utility classes in this package are now deprecated in favour of the same classes in the package de.schlichtherle . This is a minor step intended for better interoperability with the OSGi Framework.
Updates in the Package de.schlichtherle
- Changed: The visibility of the class CommandLineUtility has been changed to package private in order to reflect its very limited reusability. Client applications which sub classed this class should consider copying the source code instead.
Updates in the Package de.schlichtherle.io
- Fixed: Files.isWritableOrCreatable(java.io.File) threw an IllegalArgumentException if and only if File.lastModified() returned a negative value. These files are now considered read-only (see issue #18).
- Fixed: Files.isWritableOrCreatable(java.io.File) had a chance of leaving the first byte with its complement if the JVM gets killed unexpectedly (see issue #29).
- Enhanced: File.cat() has been optimized a very little bit.
Updates in the Package de.schlichtherle.io.archive
- New: The interface Archive now provides the method getEnclArchive() in order to enable archive drivers to detect if they are working on an enclosed archive file.
Updates in the Package de.schlichtherle.io.archive.spi
- Enhanced: The class AbstractArchiveDriver now logs details about the character set implementation at the CONFIG level.
Updates in the Package de.schlichtherle.io.archive.zip
- New: With the advent of ZIP64 support in the package de.schlichtherle.util.zip the name prefix "Zip32" of some classes and methods in this package has become obsolete. Hence, new substitutes with "Zip" as their name prefix have been added. The obsoleted classes and methods with the "Zip32" name prefix are now marked as deprecated and have been retrofitted so that binary compatibility is retained.
- Enhanced: The class ZipDriver (formerly Zip32Driver) and it's companion classes now utilize the newly introduced date/time conversion algorithm for ZIP files as implemented in the new object DateTimeConverter.ZIP in the low level API. Likewise, the class JarDriver and it's companion classes continue to utilize the existing date/time conversion algorithm for JAR files as implemented in the new object DateTimeConverter.JAR in the low level API. In the latter case, the effective behaviour of the API hasn't changed at all.
- Enhanced: Where the constructors of the class ZipDriver and its subclasses accepted the compression level parameter to use when writing a ZIP archive, this parameter now accepts the value java.util.zip.Deflater.NO_COMPRESSION, too. Please note that the compression level is independent of the compression method and is only used for the default compression method de.schlichtherle.util.zip.DEFLATED.
- Fixed: ZipEntry.clone() now throws an UnsupportedOperationException because cloning doesn't work with ArchiveEntryMetaData and is not required for ArchiveDrivers anyway.
Updates in the Package de.schlichtherle.io.archive.zip.raes
- New: With the advent of ZIP64 support in the package de.schlichtherle.util.zip the name prefix "Zip32" of some classes and methods in this package has become obsolete. Hence, new substitutes with "Zip" as their name prefix have been added. The obsoleted classes and methods with the "Zip32" name prefix are now marked as deprecated and have been retrofitted so that binary compatibility is retained.
- New: The classes ParanoidZipRaesDriver and SafeZipRaesDriver now provide an additional constructor which accepts the default compression level as its sole parameter.
Updates in the Package de.schlichtherle.util
- Fixed: The class CanonicalStringSet had bad boolean return values for its methods addAll(CanonicalStringSet) and addAll(String) . This has been fixed to match the set analogy of the class.
Updates in the Package de.schlichtherle.util.zip
- Enhanced: The classes BasicZipFile and BasicZipOutputStream now support ZIP64 extensions. For details and restrictions, please refer to their respective Javadoc.
- Fixed: The class BasicZipOutputStream now writes MS-DOS compatible External File Attributes for directory entries in the Central Directory Header. This enhances the interoperability with some third party tools, e.g. the Exlorer in Microsoft Windows Vista.
-
New: The class DateTimeConverter can be used to determine the strategy for date/time conversion between the system time (Java time) and DOS date/time fields in ZIP archive files.
This class comes with two predefined instances: When using DateTimeConverter.JAR TrueZIP's date/time conversion strategy is compatible to:
- Java SE: jar and java.util.zip package
- Info-ZIP: unzip
When using DateTimeConverter.ZIP TrueZIP's date/time conversion strategy is compatible to:
- Windows Vista Explorer (as of July 16th, 2010)
- WinZip 12.0
- 7-Zip 4.65
Use with caution: Using these instances affects the interoperability of TrueZIP with third party tools!
- New: The conversion of date/time values between Java and DOS in the class ZipEntry has been improved in interoperability: The new protected method getDateTimeConverter() is used to control the conversion of Java time to DOS date/time fields in ZIP archive files and vice versa. The implementation in this class returns DateTimeConverter.JAR for maximum compatibility with Java SE. Subclasses could override these methods to return other DateTimeConverter instances instead, e.g. DateTimeConverter.ZIP .
- Enhanced: If assertions are enabled, a RuntimeException is now thrown if an illegal DOS date/time field is detected when reading ZIP archive files. This can be used to detect bogus ZIP archive files created by third party tools. The exception is actually thrown by the class DateTimeConverter , but usually exposed by the class ZipFile .