1
This is the README file for the 28 February 2005 public release of the
1
This is the README file for the 20 April 2009 public release of the
2
2
Info-ZIP group's portable UnZip zipfile-extraction program (and related
5
unzip552.zip portable UnZip, version 5.52, source code distribution
6
unzip552.tar.Z same as above, but compress'd tar format
7
unzip552.tar.gz same as above, but gzip'd tar format
5
unzip60.zip portable UnZip, version 6.0, source code distribution
6
unzip60.tar.Z same as above, but compress'd tar format
7
unzip60.tar.gz same as above, but gzip'd tar format
9
9
__________________________________________________________________________
54
54
CHANGES AND NEW FEATURES
55
55
------------------------
56
UnZip 6.0 finally supports nowadays "large" files of sizes > 2 GiB!
57
This is the first release containing support for the PKWARE Zip64
60
- Support PKWARE ZIP64 extensions, allowing Zip archives and Zip archive
61
entries larger than 4 GiBytes and more than 65536 entries within a single
62
Zip archive. This support is currently only available for Unix,
63
OpenVMS and Win32/Win64.
64
- Support for bzip2 compression method.
65
- Support for UTF-8 encoded entry names, both through PKWARE's "General
66
Purpose Flags Bit 11" indicator and Info-ZIP's new "up" unicode path
67
extra field. (Currently, on Windows the UTF-8 handling is limited to
68
the character subset contained in the configured non-unicode "system
70
- Added "wrong implementation used" warning to error messages of the MSDOS
71
port when used under Win32, in an attempt to reduce false bug reports.
72
- Fixed "Time of Creation/Time of Use" vulnerability when setting attributes
73
of extracted files, for Unix and Unix-like ports.
74
- Fixed memory leak when processing invalid deflated data.
75
- Fixed long-standing bug in unshrink (partial_clear), added boundary checks
76
against invalid compressed data.
77
- On Unix, keep inherited SGID attribute bit for extracted directories
78
unless restoration of owner/group id or SUID/SGID/Tacky attributes was
80
- On Unix, allow extracted filenames to contain embedded control characters
81
when explicitly requested by specifying the new command line option "-^".
82
- On Unix, support restoration of symbolic link attributes.
83
- On Unix, support restoration of 32-bit UID/GID data using the new "ux"
84
IZUNIX3 extra field introduced with Zip 3.0.
85
- Support for ODS5 extended filename syntax on new OpenVMS systems.
86
- Support symbolic links zipped up on VMS.
87
- On VMS (only 8.x or better), support symbolic link creation.
88
- On VMS, support option to create converted text files in Stream_LF format.
89
- New -D option to suppress restoration of timestamps for extracted
90
directory entries (on those ports that support setting of directory
91
timestamps). By specifying "-DD", this new option also allows to suppress
92
timestamp restoration for ALL extracted files on all UnZip ports which
93
support restoration of timestamps.
94
On VMS, the default behaviour is now to skip restoration of directory
95
timestamps; here, "--D" restores ALL timestamps, "-D" restores none.
96
- On OS/2, Win32, and Unix, the (previously optional) feature UNIXBACKUP
97
to allow saving backup copies of overwritten files on extraction is now
100
For the UnZip 6.0 release, we want to give special credit to Myles Bennet,
101
who started the job of supporting ZIP64 extensions and Large-File (> 2GiB)
102
and provided a first (alpha-state) port.
56
104
The 5.52 maintenance release fixes a few minor problems found in the 5.51
57
105
release, closes some more security holes, adds a new AtheOS port, and
58
106
contains a Win32 extra-field code cleanup that was not finished earlier.
171
219
- updated Solaris/SVR4 package facility
173
221
What is (still!) not added is multi-part archive support (a.k.a. "diskette
174
spanning") and a unified and more powerful DLL interface. These are the
175
two highest priorities for the 6.x releases. Work on the former is almost
222
spanning", though we really mean archive splitting and not the old diskette
223
spanning) and a unified and more powerful DLL interface. These are the two
224
highest priorities for the 6.x releases. Work on the former is almost
176
225
certain to have commenced by the time you read this. This time we mean it!
181
230
they should now be compatible with C/C++, Visual BASIC and Delphi. Weirder
182
231
languages (FoxBase, etc.) are probably Right Out.
184
Finally, note that support for unshrinking has now been turned OFF by default,
185
although the source code is still available (as with unreducing). This was
186
done for legal reasons, not technical ones, and no, we're not any happier
187
about it than you are. :-( See the COPYING file for details.
190
234
INTERNET RESOURCES
191
235
------------------
203
247
If you have a question regarding redistribution of Info-ZIP software, either
204
248
as is, as packaging for a commercial product, or as an integral part of a
205
249
commercial product, please read the Frequently Asked Questions (FAQ) section
206
of the included COPYING file.
250
of the included COPYING file. All Info-ZIP releases are now covered by
251
the Info-ZIP license. See the file LICENSE. The most current license
252
should be available at http://www.info-zip.org/license.html and
253
ftp://ftp.info-zip.org/pub/infozip/license.html.
208
255
Insofar as C compilers are rare on some platforms and the authors only have
209
256
direct access to a subset of the supported systems, others may wish to pro-
210
257
vide ready-to-run executables for new systems. In general there is no prob-
211
258
lem with this; we require only that such distributions include this README
212
file, the WHERE file, the COPYING file (contains copyright/redistribution
259
file, the WHERE file, the LICENSE file (contains copyright/redistribution
213
260
information), and the appropriate documentation files (unzip.txt and/or
214
261
unzip.1 for UnZip, etc.). If the local system provides a way to make self-
215
262
extracting archives in which both the executables and text files can be
223
270
BUGS AND NEW PORTS: CONTACTING INFO-ZIP
224
271
----------------------------------------
225
All bug reports and patches (context diffs only, please!) should go to
226
Zip-Bugs@lists.wku.edu, which is the e-mail address for the Info-ZIP
227
authors. (Note that a few rare systems require the Zip-Bugs part to be
228
capitalized as shown; most systems work OK with lowercase "zip-bugs,"
229
however.) DO NOT MAIL US LARGE BINARIES--EVER. If you need to send us
230
a problem archive that happens to be large (> 20K), contact us first for
272
All bug reports and patches (context diffs only, please!) should be
273
submitted either through the new Info-ZIP Discussion Forum at
274
http://www.info-zip.org/board/board.pl or through the Info-ZIP SourceForge
275
site at http://sourceforge.net/projects/infozip/. The forum allows file
276
attachments while SourceForge provides a place to post patches. The old
277
Zip-Bugs@lists.wku.edu e-mail address for the Info-ZIP authors was
278
discontinued after heavy continuous spam, as was the QuickTopic discussion
279
forum. The above methods are public, but we also can be reached directly
280
using the web reply page at http://www.info-zip.org/zip-bug.html. If you
281
need to send us files privately, contact us first for instructions.
233
283
"Dumb questions" that aren't adequately answered in the documentation
234
284
should also be directed to Zip-Bugs rather than to a global forum such
236
286
the documentation, however--a great deal of effort has gone into making
237
287
it clear and complete.)
239
Suggestions for new features can be discussed on Info-ZIP@lists.wku.edu,
240
a mailing list for Info-ZIP beta testers and interested parties; you need
241
to subscribe first, however (see below). We make no promises to act on all
242
suggestions or even all patches, but if it is something that is manifestly
243
useful, sending the required patches to Zip-Bugs directly (as per the
244
instructions in the ZipPorts file) is likely to produce a quicker response
245
than asking us to do it--the authors are always ridiculously short on time.
246
(Please do NOT send patches or encoded zipfiles to the Info-ZIP list.
247
Please DO read the ZipPorts file before sending any large patch. It would
248
be difficult to over-emphasize this point...)
289
Suggestions for new features can be discussed on the new Discussion Forum.
290
A new mailing list for Info-ZIP beta testers and interested parties may
291
be created someday, but for now any issues found in the betas should use
292
the forum. We make no promises to act on all suggestions or even all
293
patches, but if it is something that is manifestly useful, sending the
294
required patches to Zip-Bugs directly (as per the instructions in the
295
ZipPorts file) is likely to produce a quicker response than asking us to
296
do it--the authors are always ridiculously short on time. (Please do
297
NOT send patches or encoded zipfiles to the Info-ZIP list. Please DO
298
read the ZipPorts file before sending any large patch. It would be
299
difficult to over-emphasize this point...)
250
301
If you are considering a port, not only should you read the ZipPorts file,
251
302
but also please check in with Zip-Bugs BEFORE getting started, since the
274
325
interim ...) Feel free to use our bug-reporting web page for bug reports
275
326
and to ask questions not answered on the FAQ page above:
277
http://www.info-zip.org/zip-bug.html
328
http://www.info-zip.org/zip-bug.html
330
For now the best option is to monitor and contribute to the various threads
331
on the new discussion forum site at:
333
http://www.info-zip.org/board/board.pl
335
The second best way to contribute is through the various features at
336
SourceForge, such as the bug posting areas.
279
338
There is also a closed mailing list for internal discussions of our core
280
339
development team. This list is now kept secret to prevent us from being
added
removed
README
