![[Info-ZIP]](images/InfoZIP-gold2.gif)
Short answer: ftp://ftp.info-zip.org/pub/infozip/ : either cd into an appropriate subdirectory and grab an appropriate executable distribution, or else get the source code from the src subdirectory and compile your own.
Long answer: do something similar to the following. This is for a Unix-like, text-mode ftp client, but others will work similarly. (The stuff after "//" is comments; don't type any of it. This example assumes you want UnZip for a Windows 9x or NT system, but the procedure is similar for other systems.)
ftp ftp.info-zip.org // run the ftp program and connect to Walnut Creek anonymous // username for anonftp you@your.email.addr // use your real e-mail address for password cd /pub/infozip // change into the Info-ZIP subdirectory dir // list the contents of the subdirectory cd WIN32 // change into the WIN32 subdirectory dir // list the contents of the subdirectory bin // set transfer mode to binary (IMPORTANT!) get unz550xN.exe // get self-extracting Win9x/NT UnZip 5.50 archive quit // quit the ftp program
[Download unz550xN.exe in binary mode to your Win9x/NT system if necessary.]
Remember: if the file size of the downloaded archive isn't EXACTLY the same as the size listed on the original ftp site with the "dir" command, you did something wrong. It is probably corrupted in that case. (Yes, this is a little harder to check via WWW since the size is usually given in KB or MB, but our README file in the same directory lists exact byte sizes. Also, most browsers automatically download in binary mode, so it shouldn't be a problem with them.)
For self-extracting archives such as the one used in the example above, simply copy or move it into the directory of your choice, cd into that directory and run the self-extracting archive:
unz550xN // extract contents of unz550xN.exe
// archive to the current directory
This can be done either from a command-line prompt or via a "Run This" menu item (e.g., in Windows). If the archive doesn't run, either you don't have enough memory available (try exiting to plain DOS if running a graphical shell) or you didn't download the archive properly (see FAQ #1).
After successful extraction, read the enclosed unzip.doc file for explicit directions on using the newly extracted unzip.exe program. Then use it! For example:
unzip -t foo.zip // test the archive `foo.zip' (see
// unzip.doc for other examples)
Note that currently all but three ports are command-line only! The three exceptions are the Macintosh port (MacZip, with integrated Zip support), the Windows 3.x/9x/NT port (WiZ, also with integrated Zip support), and the Windows CE/NT port (Pocket UnZip).
Yes. See our new Open Source license for details.
Note that it applies only to our more recent releases (starting in November 1999): Zip 2.3, UnZip 5.41, WiZ 5.01, MacZip 1.04, and subsequent updates. All older releases are still covered by our COPYING file (UnZip) or the README file in official Zip distributions.
Zip 2.1 had a -t option that was not Y2K-ized, but that was fixed in 2.2 and seems to have been the only problem.
Note that it's possible that some PC-based C compilers or libraries have Y2K bugs in them that would affect Zip and UnZip. The Info-ZIP group has not explicitly tested any compilers for such problems. To check what compiler was used to create any of our pre-compiled executables, do ``unzip -v'' or ``zip -v'' with no other arguments.
Finally, note that this is not a warranty or certification of Y2K readiness, and we will not honor requests for such certifications. (It's a tad late now anyway, but still...) We believe the statements above to be completely truthful and accurate, but we accept no liability for errors in either the statements or the software. You don't pay for the code; don't expect us to do so, either.
The encryption key in Zip is 96 bits long, which requires an export license to export from the US, even though the encryption code is imported into the US in the first place. We don't have one.
In January 2000, the Bureau of Export Administration (BXA) of the US Department of Commerce relaxed its restrictions on the export of free encryption source code, so new Info-ZIP releases now include the full crypto sources. But compiled binaries that include encryption (as opposed to decryption-only) are still restricted, and we have no particular interest in filling out the paperwork that would lift that restriction. So our main US distribution site will continue to carry only non-encrypting Zip binaries.
Note, however, that the encryption scheme used in all versions of Zip (including PKWARE's products) is quite weak; see ``A Known-Plaintext Attack on the PKZIP Stream Cipher'' (also as gzip'd PostScript) by Eli Biham and Paul C. Kocher.
The `shrink' compression method is encumbered by a patent. Although it appears that stand-alone unshrinking is not covered, the owner has claimed otherwise in public statements, and the matter has never been tested in court. (For what it's worth, the same algorithm is used in other utilities that have been included in every Linux and FreeBSD distribution that has ever shipped or been downloaded, and no one has ever complained about that. So the public statements may simply be the usual legal posturing. On the other hand, Info-ZIP has no particular desire to become the test case.)
Thus, by default, unshrinking is not enabled in newer releases of Info-ZIP's distributed binaries. Those who wish to download older binaries or compile their own versions may still do so. See UnZip's COPYING and INSTALL files for more information.
This is almost certainly an error in the Symantec ``emergency boot disk,'' which, according to a Symantec response on their German web site, has an outdated virus signature file. The standard version 5.0 of Norton AV (for Windows 95/98) does not report any such thing. Many thanks to Michael Kilby for tracking this down.
If the password was very short (i.e., essentially useless), there are various brute-force password-crackers available. If it was more than 8 or 10 characters and not restricted to a small subset of ASCII (e.g., not just the 26 lowercase letters), it might still be recoverable via a known-plaintext attack (see above). Either way, the comp.compression FAQ list is the place to start looking.
Alas, we're really slow and still don't support the creation of multi-volume (or multi-disk) archives. That's at the top of the to-do list, however. Look for UnZip 6.0 and Zip 3.0 someday, but no more promises as to when. (Actually, the whole zipfile format is showing its age; arguably it would be better to start over from scratch than to retrofit support for PKWARE's broken multi-part scheme onto the existing code base, but that's even more work.)
Extraction is currently supported, however, albeit in a crude manner. First concatenate all of the pieces together (in order!), using whatever command is appropriate for your system:
copy/b part1.zip+part2.zip+etc.zip monster.zip // under DOS, OS/2 or Win*
cat part1.zip part2.zip etc.zip > monster.zip // under Unix
Then use Zip's ``zipfix'' option to patch up the big archive (optionally get rid of all of the little pieces first if you're short on disk space):
zip -F monster.zip // fix up the concatenated archive
The archive is now a large but perfectly ordinary zipfile; extract, test or list its contents just like you normally would.
This is not yet supported by UnZipSFX. It may be supported in a future release, but no promises. (Adding functionality to run a custom install program is pretty simple, however; grab the sources and roll your own!)
The procedure is basically described in the UnZipSFX man page. First grab the appropriate UnZip binary distribution for your target platform (DOS, Windows, OS/2, etc.), as described above; we'll assume DOS in the following example. Then extract the UnZipSFX stub from the distribution and prepend as if it were a native Unix stub:
unzip unz550x.exe unzipsfx.exe // extract the DOS SFX stub cat unzipsfx.exe yourzip.zip > yourDOSzip.exe // create the SFX archive zip -A yourDOSzip.exe // fix up internal offsets
That's it. You can still test, update and delete entries from the archive; it's a fully functional zipfile. Note that Zip versions prior to 2.2 will emit a warning about a ``preamble of xxx bytes.'' This can be ignored.
You may or may not be hosed. Info-ZIP's utilities use the normal C library functions to read and write files; those functions, in turn, depend on the operating system to provide file-system support. Plain DOS, even the DOS 7.0 at the heart of Windows 9x, does not support VFAT or FAT32 long filenames. And writing very low-level, OS-dependent code to support one system violates Info-ZIP's goal of maximal portability (even if most of the necessary code is already freely available in Linux and elsewhere, though possibly with incompatible licenses).
So while Info-ZIP's Win32 versions do support long filenames in Win9x DOS boxes, they don't even run under plain DOS. And the DOS versions mostly don't support long filenames, with one exception: if UnZip is compiled with the free djgpp 2.x compiler (now part of Cygwin?), it will support long filenames under Windows 95/98/ME (not NT/2000) or short filenames under plain DOS. The currently available 32-bit executable in unz550x3.exe was compiled with djgpp 2.x.
Your best bet, therefore, is to try Chris Jones' LFNDOS VFAT/FAT32 device driver for DOS, which is somewhat similar to the OS/2 HPFS device drivers already available for DOS (e.g., HPFS-Access, Amos, etc.). We have not tested it ourselves, but it sounds like it does exactly what's needed. Thanks to Joe Forster, Bruno Binet and Jim O'Dell for the tip.
Other possibilities include Duncan Murdoch's DOSLFNBK and LFNSORT utilities. For archiving only (i.e., not extracting), J. Tigchelaar's LDZIP can be used to back up long filenames under plain DOS. (Note that DOS 7.1 or later is required to support the newer FAT32 partitions.)
Yup, there are recursion bugs in the Win32 port of both Zip 2.1 and 2.2. The documented way in 2.1 is this:
zip -r foo.zip . -i *.exe // doesn't recurse as expected under Windows 9x, NT
This is what actually works:
zip -r foo.zip * -i *.exe // recursively archive all *.exe files
This bug was fixed in Zip 2.2, but that version in turn has a bug in its new -R option:
zip -R foo.zip *.exe // doesn't recurse as expected
For now, the previous method (using -r and -i) will work. The -R bug is fixed in 2.3. We apologize for the inconvenience.
The root cause is a longstanding bug in Windows NT, Windows 95/98, and Windows CE. If an archived file was last modified during Daylight Savings Time (a.k.a. Summer Time) and is being extracted during Standard Time--or vice versa--Windows applies the current timezone offset (including DST) to the extracted file instead of using the offset that was applicable on the date the file was created or otherwise modified. This results in an off-by-one-hour problem in some extracted files, especially around April and October when locales that observe DST typically switch between it and Standard Time. (Aside: You can see the bug in action, completely independent of Zip and UnZip, by saving a Windows directory listing just before the switch and comparing it with one taken just after the switch. All file times will appear to shift by an hour.)
We addressed this problem in 1997 for UnZip 5.3, and while there may have been some lingering oversights in that series, the UnZip 5.4x series should be completely fixed. However, if and when the Windows bug is ever fixed, it's possible that Info-ZIP's workaround will recreate the bug in reverse. To our knowledge, this has not yet happened.
You need to upgrade your copy of Internet Explorer to version 4.0 or later. There is a bug in older versions.
Zip and UnZip executables for both OS/390 OpenEdition and OS/390 Base (a.k.a. MVS Classic) are now available here.
MacZip, a Macintosh port by Dirk Haase that includes both Zip and UnZip capability, was officially released in January 2000 and is available in both source and binary forms.
We currently have no plans to do a WinCE port of Zip. We'd like to do one eventually, but only if time permits, and it has been on hold for more than two years.
UnZip (and Zip, and all of the other Info-ZIP utilities) must be set up as a VMS foreign command, as noted in the README.VMS file included with our VMS distributions. Add some lines similar to the following to your LOGIN.COM file:
$ unzip == "$disk:[dir]unzip.exe"
$ zipinfo == "$disk:[dir]unzip.exe ""-Z"""
...where "disk" and "dir" refer to the true disk and directory where unzip.exe is located. The "$" before the disk name is important; i.e., don't delete it. All of the quotes in the ZipInfo line are necessary, too, so don't delete any of them, either.
Finally, run UnZip just as on any other system (see FAQ #2). Do not type ``run'' before the command.
Two reasons:
This is a known bug with HPFS386-based network drives (LAN Server 4.0 or Warp Server), and IBM has not provided a patch. UnZip 5.2 and later have a work-around for the problem, however. (Note that the same bug will affect any program that uses the DosSetPathInfo() call.)
Yes, at least the UnZip 5.4 DLLs and Zip 2.3 DLLs (and later versions).
The UnZip DLL is believed to be thread-safe. The Zip DLL is not.
According to strict interpretation of the 2.x zipfile specification (but see the PKZIP 4.50 comments below), the following limits apply to all zipfile archives:
| statistic | limit | comments |
|---|---|---|
| number of files | 65,536 | This is not a "hard" limit, and Zip 2.2 will happily store more than 64K files (we've tested with 70,001); UnZip 5.41 and later will extract them again. (Earlier releases will not.) Note that Zip will first store in memory the path/filename and various parameters for every file that will be in the final archive; the actual limit on the number of files may be determined by the amount of RAM and/or virtual memory available on the system. Also note that 16-bit DOS versions of Zip are limited to around 16,000 files. |
| uncompressed size of a single file | 4 GB | This is also not a hard limit, in that the deflate algorithm used in all recent releases has its own "end of stream" marker. Some file systems and/or C libraries may not support files this big, however, and there are other zipfile limits (see below) that may have an impact. However, we do have a report that a user of the Win32 versions of Zip and UnZip succeeded in compressing and extracting a 7 GB database file. (The only reported oddity was in listing the archive's contents; UnZip has no way to know that the true file size is bigger than what the zipfile directory reports.) |
| compressed size of a single file | 4 GB | In practice, the real limit may be 2 GB on many systems, due to UnZip's use of the fseek() function to jump around within an archive. Because's fseek's offset argument is usually a signed long integer, on 32-bit systems UnZip will not find any file that is more than 2 GB from the beginning of the archive. And on 64-bit systems, UnZip won't find any file that's more than 4 GB from the beginning (since the zipfile format can only store offsets that big). So the last file in the archive can potentially be arbitrarily large (in theory, anyway--we haven't tested this), but the combined total of all the rest must be less than 2 GB or 4 GB, respectively. |
| total size of archive | 256 TB | While the only theoretical limit on the size of an archive is given by (65,536 files x 4 GB each), realistically UnZip's random-access operation and (partial) dependence on the stored compressed-size values limits the total size to something in the neighborhood of 2 to 4 GB. This restriction may be relaxed in a future release. (On 64-bit IRIX with the native compiler, the options "-mips4 -64" or "-mips4 -64 -ipa" [for both compiling and linking] may help. "-ipa" is reported to generate incorrect code sometimes, however.) |
| maximum path/filename length | 64 KB | Zipfiles have essentially no limits on the length of pathnames (or on the depth of directory trees); the actual limits will be imposed by the file system on which the archive was created. DOS and its derivatives (Windows, OS/2, etc.) generally limit paths to 256 characters or less; Unix systems typically have a 1024-character limit. Some CD-ROM file systems have an 8-level subdirectory limit. |
Note that there are other limitations of the zipfile format beyond its dependence on 16-bit and 32-bit fields. These include its weak encryption, poorly designed "extra field" capability, poorly designed "multi-disk" support, mediocre robustness, support for streaming encoders only as an afterthought, low-precision timestamps (two-second granularity), lack of cross-timezone support (i.e., Universal Time) except as a third-party add-on, lack of any support for "solid" packing of small files, lack of support for alternate character sets (e.g., EBCDIC) and encodings of international characters (e.g., UTF-8), unnecessary redundancy, and merely acceptable (but no longer outstanding) compression efficiency. All of these things suggest that it's time for a brand-new format, not just a few more patches on an aging standard. (And no, we're not volunteering, either--although we have discussed what we consider some of the requirements for such a new format.)
Also note that in August 2001, PKWARE released PKZIP 4.50 with support for large files and archives via a pair of new header types, "PK\x06\x06" and "PK\x06\x07". So far these headers are undocumented, but most of their fields are fairly obvious. We don't yet know when Zip and UnZip will support this extension to the format. In the short term, it is possible to improve Zip and UnZip's capabilities slightly on certain Linux systems (and probably other Unix-like systems) by recompiling with the -DLARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 options. This will allow the utilities to handle uncompressed data files greater than 2 GB in size, as long as the total size of the archive containing them is less than 2 GB. (The operating system also must have support for large files; for Linux, this involves the kernel [2.4 or later], the file system [at least Reiser and ext2 are supported], the C library [glibc 2.x], and possibly other file utilities [ls, rm, etc.] and the shell itself [bash, tcsh, etc.] if redirection is involved.)
There have been a few over the years. This table was created in August 2001 and last updated in March 2002. It is probably not 100% complete, but it's close:
| program | platform | nature of bug |
|---|---|---|
| Zip 2.0.1 | any Unix | With Zip 2.0.1's -y option, symbolic links got stored as empty files--i.e., all knowledge of the file to which the link pointed was lost within the archive. This bug was fixed in Zip 2.1. |
| Zip 2.x | OS/2 3.x? | There was some bug involving updating archives (-u and -f options) on a networked HPFS386 partition, wherein part of the zipfile would be filled with zeros instead of the actual compressed data and header info. I don't recall the exact details, but a fixpak is/was available to take care of the problem. |
| Zip |
Solaris, AIX, Red Hat Linux, others? |
Creating zipfiles on NFS file systems under Red Hat 6.x could result in silent corruption. This was a known bug in Solaris (Sunsolve ID 4071076), AIX (IBM APAR IY06322) and possibly other Unixen that seems to have been exacerbated by Red Hat's knfsd. It affected many archivers and other programs, and it could be fixed only by patching the NFS server. |
| UnZip 5.42 and earlier | virtually all | All versions of UnZip through 5.42 have a directory-traversal security vulnerability that allows them to unpack files in unexpected places. Specifically, if an archive contains files with leading "/" characters (i.e., relative to the top-level/root directory) or with ".." components ("previous directory level"), UnZip will unpack the files in the indicated locations, possibly creating directory trees in the process--and, if the -o ("overwrite") option is given, quietly destroying existing files outside the intended directory tree. This is fixed in version 5.50, and a patch (slight overkill, but apparently effective) is available on the Bugtraq page that reported the problem. (Thanks to Anya Berdichevskaya for the pointer.) |
| Zip 2.x | all |
When compiled with either BIG_MEM or MMAP defined (MMAP
overrides BIG_MEM if both are defined), Zip will silently
corrupt stored (uncompressed) files when forced via either
the -0 (``store'') or -n (``don't compress these suffixes'')
options. Because the stored CRC-32 value is consistent with
the corrupted data, testing with UnZip will not expose the
error; only extraction and byte-for-byte comparison with the
original files will. This has now been
confirmed to be a long-standing bug in Zip itself
(within zipup.c only, not deflate.c). It does not
affect files that are stored due to small size or
incompressibility; these files use the code path in deflate.c.
Thus any of the following workarounds will suffice:
|
| UnZip 5.50 | 16-bit ports (e.g., DOS) | For all ports using 16-bit integers, textmode output (-a or -aa options) is broken in such a way that half of the output-buffer chunks are silently skipped. Because the bug is located in the output routine after the CRC check has been carried out (because there isn't any way to know the CRC for the text-converted data), it is not detected by any built-in consistency check. (Note that the more common 32-bit and 64-bit UnZip ports are not affected.) The workaround is to disable 64-bit deflate support when compiling 16-bit UnZip ports (define NO_DEFLATE64). This bug will be fixed in the 5.51 maintenance release. |
| WiZ 5.x? | Windows | Chad Loder of Rapid7 discovered a crash bug and potential security vulnerability in WiZ, involving very long filenames inside archives. This problem does not appear to affect any of Info-ZIP's command-line tools or MacZip. See Rapid7's advisory for test archives and subsequent links, including CERT and CVE. This bug will be fixed in WiZ 5.03. |
We'll fill in further details as time permits.
No--unless UnZip is compiled with USE_ZLIB defined and the relevant version of zlib has the bug (i.e., any version of zlib before 1.1.4; check UnZip with ``unzip -v''). The double-free bug affected only the version of inflate() in zlib; UnZip's version is not vulnerable, and Zip does not use inflate(). (Thanks to Mark Adler for verifying this.)
There is an optimization bug in the native (non-GNU) HP C compiler for HP-UX 10.20 that breaks Zip's encryption code and UnZip's decryption code. Recompile crypt.c with optimization turned off (no -O or +O2 option) or turned down to the lowest level (+O1). Note that this bug affects both decryption of zipfiles created elsewhere and encryption of zipfiles created on HP-UX (i.e., the latter cannot be decoded on other systems).
Yes, Sherlock, we know. It's intentional. It's humor. Ar ar. Now go away.
![[Info-ZIP]](images/InfoZIP-gold-sml.gif){kind=small}
Return to the Info-ZIP Home Page.
| Copyright © 1995-2002 Greg Roelofs. | Primary ftp site hosted by LEO. |