GSP/Panel
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Added Cyg-Win

Browse source
This commit is contained in:
Frank Harris 2026-06-06 18:46:40 -04:00
parent 82cbc206eb
commit 413c315806
10586 changed files with 3806249 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

6
Agent-Windows/OGP64/usr/share/doc/zip/BUGS Normal file
View file

@ -0,0 +1,6 @@
- zip sometimes crashes on some versions of NetBSD (0.8, 0.9 and early
0.9-current), FreeBSD (<= 1.1) and BSDI (< 1.1) . This is due to a
bug in stdio.
Upgrading the stdio package in /usr/src/lib/libc/stdio should
fix the problem. See *BSD mirrors in src/lib/libc/stdio
You must at least replace setvbuf.o in all the libc's with a newer version.

3460
Agent-Windows/OGP64/usr/share/doc/zip/CHANGES Normal file
View file

File diff suppressed because it is too large Load diff

60
Agent-Windows/OGP64/usr/share/doc/zip/LICENSE Normal file
View file

@ -0,0 +1,60 @@
This is version 2007-Mar-4 of the Info-ZIP license.
The definitive version of this document should be available at
ftp://ftp.info-zip.org/pub/infozip/license.html indefinitely and
a copy at http://www.info-zip.org/pub/infozip/license.html.
Copyright (c) 1990-2007 Info-ZIP. All rights reserved.
For the purposes of this copyright and license, "Info-ZIP" is defined as
the following set of individuals:
Mark Adler, John Bush, Karl Davis, Harald Denker, Jean-Michel Dubois,
Jean-loup Gailly, Hunter Goatley, Ed Gordon, Ian Gorman, Chris Herborth,
Dirk Haase, Greg Hartwig, Robert Heath, Jonathan Hudson, Paul Kienitz,
David Kirschbaum, Johnny Lee, Onno van der Linden, Igor Mandrichenko,
Steve P. Miller, Sergio Monesi, Keith Owens, George Petrov, Greg Roelofs,
Kai Uwe Rommel, Steve Salisbury, Dave Smith, Steven M. Schweda,
Christian Spieler, Cosmin Truta, Antoine Verheijen, Paul von Behren,
Rich Wales, Mike White.
This software is provided "as is," without warranty of any kind, express
or implied. In no event shall Info-ZIP or its contributors be held liable
for any direct, indirect, incidental, special or consequential damages
arising out of the use of or inability to use this software.
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the above disclaimer and the following restrictions:
1. Redistributions of source code (in whole or in part) must retain
the above copyright notice, definition, disclaimer, and this list
of conditions.
2. Redistributions in binary form (compiled executables and libraries)
must reproduce the above copyright notice, definition, disclaimer,
and this list of conditions in documentation and/or other materials
provided with the distribution. The sole exception to this condition
is redistribution of a standard UnZipSFX binary (including SFXWiz) as
part of a self-extracting archive; that is permitted without inclusion
of this license, as long as the normal SFX banner has not been removed
from the binary or disabled.
3. Altered versions--including, but not limited to, ports to new operating
systems, existing ports with new graphical interfaces, versions with
modified or added functionality, and dynamic, shared, or static library
versions not from Info-ZIP--must be plainly marked as such and must not
be misrepresented as being the original source or, if binaries,
compiled from the original source. Such altered versions also must not
be misrepresented as being Info-ZIP releases--including, but not
limited to, labeling of the altered versions with the names "Info-ZIP"
(or any variation thereof, including, but not limited to, different
capitalizations), "Pocket UnZip," "WiZ" or "MacZip" without the
explicit permission of Info-ZIP. Such altered versions are further
prohibited from misrepresentative use of the Zip-Bugs or Info-ZIP
e-mail addresses or the Info-ZIP URL(s), such as to imply Info-ZIP
will provide support for the altered versions.
4. Info-ZIP retains the right to use the names "Info-ZIP," "Zip," "UnZip,"
"UnZipSFX," "WiZ," "Pocket UnZip," "Pocket Zip," and "MacZip" for its
own source and binary releases.

234
Agent-Windows/OGP64/usr/share/doc/zip/README Normal file
View file

@ -0,0 +1,234 @@
Zip 3.0 is the first Zip update adding large file support. For now Zip 2.3x
remains available and supported, but users should switch to this new release.
Testing for Zip 3.0 has focused mainly on Unix, VMS, Max OS X, and Win32,
and some other ports may not be fully supported yet. If you find your
favorite port is broke, send us the details or, better, send bug fixes. It's
possible that support for some older ports may be dropped in the future.
Copyright (c) 1990-2008 Info-ZIP. All rights reserved.
See the accompanying file LICENSE (the contents of which are also included
in unzip.h, zip.h and wiz.h) for terms of use. If, for some reason, all
of these files are missing, the Info-ZIP license also may be found at:
ftp://ftp.info-zip.org/pub/infozip/license.html and
http://www.info-zip.org/pub/infozip/license.html.
Zip 3.0 is a compression and file packaging utility. It is compatible with
PKZIP 2.04g (Phil Katz ZIP) for MSDOS systems. There is a companion to zip
called unzip (of course) which you should be able to find in the same place
you got zip. See the file 'WHERE' for details on ftp sites and mail
servers.
So far zip has been ported to a wide array of Unix and other mainframes,
minis, and micros including VMS, OS/2, Minix, MSDOS, Windows, Atari, Amiga,
BeOS and VM/CMS. Although highly compatible with PKware's PKZIP and PKUNZIP
utilities of MSDOS fame, our primary objective has been one of portability
and other-than-MSDOS functionality. Features not found in the PKWare version
include creation of zip files in a pipe or on a device; VMS, BeOS and OS/2
extended file attributes; conversion from Unix to MSDOS text file format; and,
of course, the ability to run on most of your favorite operating systems. And
it's free.
See the file zip30.ann for a summary of new features in Zip 3.0 and WhatsNew
for the detailed list of new features and changes since Zip 2.32. The file
CHANGES details all day-to-day changes during development.
Notes:
Multi-volume support. This version does not support multi-volume spanned
archives as in pkzip 2.04g, and there is no intention at this point to support
spanned archives, but Zip 3.0 supports split archives. A split archive is an
archive split into a set of files, each file a piece of the archive and each
file using an extension, such as .z02 as in the file name archive.z02, that
provides the order of the splits. In contrast, a spanned archive is the
original multi-floppy archive supported by pkzip 2.0g where the split order
is contained in the volume labels. The contents of split and spanned archives
are mostly identical and there is a simple procedure to convert between the
formats. Many current unzips now support split archives.
Zip64 support. This version supports Zip64 archives as described in the
PKWare AppNote. These archives use additional fields to support archives
greater than 2 GB and files in archives over the 2 GB previous limit (4 GB
on some ports). The Zip64 format also allows more than 64k entries in an
archive. Support by the OS for files larger than 4 GB is needed for Zip to
create and read large files and archives. On Unix, Win32, and some other
ports, large file and Zip64 support is automatically checked for and
compiled in if available. Use of Zip64 by Zip is automatic and to maximize
backward compatibility the Zip64 fields will only be used if needed. A
Zip64 archive requires a pkzip 4.5 compatible unzip, such as UnZip 6.0.
Unicode support. This version has initial Unicode support. This allows
paths and names of files in other character sets to be accurately recreated
on OS that have sufficient character set support. On Win32, if wide
character calls are supported (not Win 9x unless Unicode support has been
added) all files (including paths with illegal characters in the current
character set) should now be readable by zip. Unicode support is provided
using a new set of UTF-8 path and comment extra fields and a new UTF-8 bit
for flagging when the current character set is already UTF-8. Zip 3.0
maintains backward compatibility with older archives and is mostly compliant
with the new Unicode additions in the latest PKWare AppNote. The exception
is UTF-8 comments, which are not supported if UTF-8 is not the native
character set, but should be fully implemented in Zip 3.1.
16-bit OS support. Though Zip 3.0 is designed to support the latest zip
standards and modern OS, some effort has been made to maintain support
for older and smaller systems. If you find Zip 3.0 does not fit on or
otherwise does not work well on a particular OS, send in the details and
we might be able to help.
Compression methods. In addition to the standard store and deflate methods,
Zip now can use the bzip2 compression format using the bzip2 library. Though
bzip2 compression generally takes longer, in many cases using bzip2 results
in much better compression. However, many unzips may not yet support
bzip2 compressed entries in archives, so test your unzip first before using
bzip2 compression.
Installation. Please read the file INSTALL for information on how to compile
and install zip, zipsplit, zipcloak, and zipnote and please read the manual
pages ZIP.txt, ZIPSPLIT.txt, ZIPCLOAK.txt, and ZIPNOTE.txt for information on
how to use them. Also, if you are using MSDOS or Windows, note that text
files in the distribution are generally in Unix line end format (LF only)
and Windows and DOS users will need to either convert the files as needed to
DOS line ends (CR LF) or extract the distribution contents using unzip -a.
Utilities. At this point zipsplit, zipcloak, and zipnote should work with
large files, but they currently do not handle split archives. A work around
is to use zip to convert a split archive to a single file archive and then use
the utilities on that archive.
Encryption. This version supports standard zip encryption. Until recently
the encryption code was distributed separately because of the US export
regulations but now is part of the main distribution. See crypt.c for
details. Decryption can be made with unzip 5.0p1 or later, or with zipcloak.
Bug reports. All bug reports or patches should go to zip-bugs via the web
site contact form at http://www.info-zip.org/zip-bug.html (we have discontinued
the old email address zip-bugs@lists.wku.edu because of too much spam lately)
and suggestions for new features can be submitted there also (although we don't
promise to use all of them). We also are on SourceForge at
http://sourceforge.net/projects/infozip/ and now automatically get Bug Reports
and Feature Requests submitted there. In addition, a new Info-ZIP discussion
forum is available as well. See below. Though bug reports can be posted there,
we don't have automatic monitoring of all postings set up yet so you may want
to use the web form or SoureForge for a quicker response. A good approach may
be to post the details on the forum so others can benefit from the posting,
then use the web reply form to let us know you did that if you don't get a
reply in a reasonable time.
Ports. If you're considering a port, please check in with zip-bugs FIRST,
since the code is constantly being updated behind the scenes. We'll
arrange to give you access to the latest source.
Discussion group. If you'd like to keep up to date with our Zip (and companion
UnZip utility) development, join the ranks of BETA testers, add your own
thoughts and contributions, etc., check out the new discussion forum. This is
the latest offering, after the various Info-ZIP mailing-lists on
mxserver@lists.wku.edu (courtesy of Hunter Goatley) were no longer available
and the temporary QuickTopic discussion group for Info-ZIP issues at
http://www.quicktopic.com/27/H/V6ZQZ54uKNL died a horrible death due to large
amounts of spam. The new discussion forum is now available at
http://www.info-zip.org/board/board.pl (thanks again to Hunter Goatley) and
can be used to discuss issues, request features, and is one place new betas
and releases are announced. It also is a place to post bug reports, and
patches can be submitted as attachments. However, we don't yet get
automatic notification of all postings there so try one of the other methods
if you don't get a response. You can also post Bug Reports and Feature
Requests at Source Forge. However, the web site contact form remains
available if you would rather not post on the public forums.
Frequently asked questions on zip and unzip:
Q. When unzipping I get an error message about "compression method 8".
A. This is standard deflate, which has been around for awhile. Please
get a current version of unzip. See the file 'WHERE' for details.
Q. How about "compression method 12"?
A. Compression method 12 is bzip2 and requires a relatively modern unzip.
Please get the latest version of unzip.
Q. I can't extract this zip file that I just downloaded. I get
"zipfile is part of multi-disk archive" or some other message.
A. Please make sure that you made the transfer in binary mode. Check
in particular that your copy has exactly the same size as the original.
Note that the above message also may actually mean you have only part
of a multi-part archive. Also note that UnZip 5.x does not and UnZip 6.0
probably won't have multi-disk (split) archive support. A work around
is to use Zip 3.0 to convert the split archive to a single-file archive
then use UnZip on that archive. As a last result, if there's something
readable in what you have, zip -FF should be able to recover it.
Q. When running unzip, I get a message about "End-of-central-directory
signature not found".
A. This usually means that your zip archive is damaged, or that you
have an uncompressed file with the same name in the same directory.
In the first case, it makes more sense to contact the person you
obtained the zip file from rather than the Info-ZIP software
developers, and to make sure that your copy is strictly identical to
the original. In the second case, use "unzip zipfile.zip" instead
of "unzip zipfile", to let unzip know which file is the zip archive
you want to extract.
Q. Why doesn't zip do <something> just like PKZIP does?
A. Zip is not a PKZIP clone and is not intended to be one. In some
cases we feel PKZIP does not do the right thing (e.g., not
including pathnames by default); in some cases the operating system
itself is responsible (e.g., under Unix it is the shell which
expands wildcards, not zip). Info-ZIP's and PKWARE's zipfiles
are interchangeable, not the programs.
For example, if you are used to the following PKZIP command:
pkzip -rP foo *.c
you must use instead on Unix:
zip -R foo "*.c"
(the quotes are needed to let the shell know that it should
not expand the *.c argument but instead pass it on to the program,
but are not needed on ports that do not expand file paths like
MSDOS)
Q. Can I distribute zip and unzip sources and/or executables?
A. You may redistribute the latest official distributions without any
modification, without even asking us for permission. You can charge
for the cost of the media (CDROM, diskettes, etc...) and a small copying
fee. If you want to distribute modified versions please contact us at
www.Info-ZIP.org first. You must not distribute beta versions.
The latest official distributions are always on ftp.Info-ZIP.org in
directory /pub/infozip and subdirectories and at SourceForge.
Q. Can I use the executables of zip and unzip to distribute my software?
A. Yes, so long as it is made clear in the product documentation that
zip or unzip are not being sold, that the source code is freely
available, and that there are no extra or hidden charges resulting
from its use by or inclusion with the commercial product. See the
Info-ZIP license for more. Here is an example of a suitable notice:
NOTE: <Product> is packaged on this CD using Info-ZIP's compression
utility. The installation program uses UnZip to read zip files from
the CD. Info-ZIP's software (Zip, UnZip and related utilities) is
freely distributed under the Info-ZIP license and can be obtained as
source code or executables from various anonymous-ftp sites,
including ftp://ftp.info-zip.org/pub/infozip.
Q. Can I use the source code of zip and unzip in my commercial application?
A. Yes, as long as the conditions in the Info-ZIP license are met. We
recommend you include in your product documentation an acknowledgment
and note that the original compression sources are available at
www.Info-ZIP.org. If you have special requirements contact us.

142
Agent-Windows/OGP64/usr/share/doc/zip/TODO Normal file
View file

@ -0,0 +1,142 @@
Todo list (last updated 12 June 2008).
Features for next official version:
- Extended attributes for Windows, Linux, and Mac OS X.
- Win32 ACL rewrite to use backup api to create new and more useful extra
field (need unzip support) (Kai).
- Allow -d@ to read in a list of names to delete (11/17/2005).
- AES encryption (3/19/05).
Features that may make the next release:
- Allow reading in list of files using @filename.
- When -R, -x, or -i pattern ends in a directory add / to the end
(11/5/2004 Nehal).
- Decide if -R, -i and -x should use external rather than internal patterns.
Also, change pattern matching to not do ex2in() and then in2ex() if
appropriate. (12/26/2005 SMS)
- Though Unicode paths have been implemented and tested, Unicode comments
are not yet supported (except for comments on UTF-8 native systems which
are supported).
- Verbose mode -v may still need work.
- Add C# example for Zip 3.0 (need to be converted to new DLLs) - original
C# example added with note.
- Path Prefix maybe, so entries added to an archive can have a directory
path string prepended to each path so can zip multiple drives and avoid
name conflicts (4/17/2006).
- UNC paths like \\server\path (4/26/2005).
- Support for other languages maybe.
- Add About page option similar to -h2 and -v but lists Info-ZIP
information (could be -sa) (4/29/2006).
- Update utilities ZipSplit, ZipNote, and ZipCloak to handle split archives.
- Update ziperr and finish if needed.
- Review memory allocation and fill in memory leaks if any.
- Enhance -FF to fix common problems such as archives ftp in text mode
and fixing checksums so entries can be extracted if that makes
sense (6/17/2007).
- Add \ to / conversion in zipsplit to fix problem in
1/29/2004 email.
- Encryption bug with small stored file (12/27/2005) (fixed?).
- When updating large archives with few entries being
updated maybe display something in large periods of
quiet (1/23/2006).
- Windows OEM comments (5/17/2006).
- Example of using MVS zip and unzip (3/30/2004) (Need one).
- UTF-8 comments need to be implemented (6/17/2007)
- Maybe convert ../ in archive (5/20/2006).
- Per so many buffers dll callback (12/23/2005 Ale).
- Allow rename stdin "-" to something else (12/27/2005 gregor).
- Check for possible buffer overrun weaknesses while reading zip files.
- Do Active Template Library (ATL) (4/27/2005).
- Flush Win16 support - to be determined (Mike).
- Way to convert file names on input, converting foo.c to dir/foo_bar.c
for instance (4/8/2004, 3/12/2004).
- French WiZ (not a Zip thing actually but dependent on zip and unzip).
- Then there is that wierd ^D being converted to \000 error reported
in 6/21/2003 email when Zip is outputted into a pipe on Windows ports.
Old list:
Main features still missing for next official version (last updated 2/11/2001):
- what about the binary/text detection ? (seems done)
- -b and -t options in help screen (covered in -h2)
- findfirst/findnext and after that LSSTAT (performance!!)
- use IS_EXEC from djgpp stat.h
- use install in unix/Makefile instead of mkdir -p, look at install sh script.
- #elif for those ports that can handle it.
- what about zopen vs. fopen ?
- Add zcreate or zfcreate for win32.
- Assembler stuff in match.S (subexpressions)
- zipping huge files (> 2G, unsigned 32bit) (done)
- Testsuite for zip and unzip (John D. Mitchell)
- make a version.c or version.h that includes all the compiler names
- run utils with dmalloc().
- what to do with zip -F and zip -FF (readzipfile2()) ? (done?)
- profiling of the code
- multi disk zip files (could be done)
- zipfile modification tool (Greg)
- Implement -- option (Thomas Klauser, wiz@danbala.tuwien.ac.at) (could be done)
- don't add files with "Archive bit" or add files with "Archive bit"
(uwe.becher@metronet.de) (could be done with -AS and -AC)
- 32 bit file attributes
- generate output without having to seek at all (this seems to be stream output)
- remove contractions from zip error messages, make them clearer (Steve)
- display "[text]" for ascii files when not quiet (no -q) (Timo Salmi)
- does zipnote accept names with version number?
- for a WORM, zip should create temp file only when updating; new archives
should be created directly.
- APPNOTE.TXT specifies "4) The entries in the central directory may
not necessarily be in the same order that files appear in the zipfile"
but readzipfile() relies on same order. (new read does not, and now
the read for -FF searches for central directory matches rather than
rely on the order)
- on Mac, MPW C 3.3.1 requires #if (a || b) ["#if a || b" taken as "#if a"]
- on Unix, let -S be "include non-regular files without reading from them"
(as pkzip on Unix). This requires unzip support.
- zip -l should do ebcdic->ascii translation on CMS and MVS
- zip as subroutine (zdig/241) (some work done on this)
- accept k and M in zipsplit
- store / (part of file name) as ! in OS/2 (problem only with -E ?)
- in addition to -l (LF to CR LF) and -ll (CR LF to LF) add -lc
(LF to CR LF but CR LF remains unchanged)
Known bugs:
- On VMS, zip fails reading some files with "byte record too large for
user's buffer". You must use the "-V" option for such files.
(many changes to VMS so may be fixed)
- on MSDOS, zip386.exe does not like "zip -bc: foo ..."
- on MSDOS, zip386.exe is sometimes much slower than zip.exe. This is
probably a problem with DJGPP (to be investigated).
- on NT with C shell, zip should not do file name expansion again.
- zip zipfile ... ignores existing zipfile if name does not have an extension
(except for the -A option, generally used on self-extracting files).
(archives should probably have extensions. Things like archive.jar work)
- For an sfx file without extension, "zip -A sfx" works but "zip sfx -A"
doesn't. (because options were required first, but now both OK)
- When storing files in a zipfile (-0), zip marks all of them as binary.
- On VMS, some indexed files are not restored correctly after zip -V and unzip.
(This is now known to be a problem of UnZip. The workaround for Zip 2.2
and newer is to use PK-style VMS extra fields; this is now the default.
NOTE that UnZip 5.32 has been fixed [971019]!) (many VMS changes so
this may be fixed)
- zip and unzip should use the same pattern matching rules, particularly
on MSDOS and OS/2. On OS/2, "zip foo *.*" should also match files
without extension.
Partially DONE (OS/2 "*.*" matches "*".)
- there should be a way to avoid updating archive members (only addition
of new files allowed)

333
Agent-Windows/OGP64/usr/share/doc/zip/WHATSNEW Normal file
View file

@ -0,0 +1,333 @@
What's New
Last updated 1 July 2008
This file is the full list of new features and major changes for Zip 3.0
by beta release. See the announcement file zip30.ann for a quick summary
of all features and changes in Zip 3.0. Also see the file README for
release information, INSTALL for installation procedures, and the manual
pages zip.txt, zipsplit.txt, zipcloak.txt, and zipnote.txt for how to use
the new features. The file CHANGES has all the day-to-day changes made
during development.
Below are some of the more significant items on the list for Zip 3.1
(see ToDo for a more complete list):
- AES encryption.
- Extended attributes for Windows, Linux, and Mac OS X.
- Support -d@ for deleting list of files.
- Decide if -R, -i and -x should use external rather than internal patterns.
- Though Unicode paths have been implemented and tested, Unicode comments
are not yet supported (except for comments on UTF-8 native systems which
are supported).
- Verbose mode -v may still need work.
- When pattern is directory add end / automatically.
- Add C# example for Zip 3.0 (need to be converted to new DLLs) - original
C# example added with note.
- Path Prefix maybe, so entries added to an archive can have a directory
path string prepended to each path.
- UNC path support maybe.
- Support for other languages maybe.
- Send in your suggestions.
- ...
MAJOR CHANGES BY BETA VERSION
-----------------------------
New things in Zip 3.0 since Zip 3.0h:
- Unicode fixes.
- Test and fix various ports as needed.
- Update Win32 resource to support more Windows ports.
- Add djgpp 2.x makefile that includes bzip2.
- Add Win32 version resource to Win32 executable.
- Bug fixes.
- Documentation updates.
- Package for release.
New things in Zip 3.0h
- Allow -@ and -x to work together.
- Unicode code cleanup.
- Allow forcing use of UTF-8 storage in standard path and comment.
- Update symbolic link checks.
- Add support for storing 32-bit UIDs/GIDs using new extra field.
Backward compatible support for the old 16-bit UID/GID extra field
remains if Zip is compiled on an OS that has 16-bit UID/GID
storage.
- Update VMS notes.
- Directory scan using -AS (include only files with Windows archive
bit set) now ignores archive bit on directories to include all files
with archive bit set in all directories. Also, to avoid empty
directories being created, -AS now does not store directory
entries.
- Add Unix IBM support.
- Change -W to -ws to free -W for later use.
- Fix large file support for MinGW.
- Fix large file support for bzip2.
- Fix compile error in ZipCloak when UNICODE_SUPPORT is not enabled.
- Fix Unicode bug in ZipCloak involving Unicode paths.
- Long Unicode escapes changed from #Lxxxxxxxx to #Lxxxxxx to shorten
paths with escaped Unicode.
- Bug fixes.
New things in Zip 3.0g
- Add split support to VB project for Zip64.
- Disable reading of Unix FIFOs unless new -FI option used to avoid an
archiving operation stopping when it hits an active unfed FIFO.
- The "[list]" wildcard expression (regular expression matching of any
character or range of characters in list) is now disabled on DOS and
Windows as it has caused confusion when filenames have [ and ] in
them. The new -RE option reenables it.
- Add negation to many display options such as -dc and -db.
- Allow -FF to read and fix archives having local entries that appear
after central directory entries.
- Bug fixes.
New things in Zip 3.0f
- bzip2 - The bzip2 compression method looks supported for at least
Windows, Unix, and VMS using the bzip2 library. A new option, -Z cm,
selects the compression method.
- Split archives - Can now use -s to create a split archive. The
default is to update split files as the archive is being written,
which requires all splits to remain open until the archive is done.
This should be no problem when writing the archive to a hard drive,
for example, and this approach creates archives that should be
supported by all unzips that support splits. Adding the -sp option
enables split pause mode that instead writes splits that do not
need updating and pauses Zip after each split. This allows splits
to be written directly to removable media, however -sp archives
may not be as universally compatible.
- Unicode support - Zip now stores Unicode paths that should be more
portable across character sets and languages. The unzip must have
Unicode support enabled or the Unicode paths are ignored. If
reading an archive with Unicode paths, unsupported characters are
replaced by #Uxxxx and #Lxxxxxxxx escapes in the file name. Option
-UN controls how Unicode is handled. Also, on systems where the
current character set is UTF-8, preliminary support for the new
General Purpose Bit Flag, bit 11, UTF-8 flag, that indicates UTF-8
is stored in the path and comment fields is implemented for paths.
- Unicode on Win32 - On WIN32 systems that support the wide character
calls (mainly NT and later systems using NTFS), when UNICODE SUPPORT
is enabled Zip will now do directory scans using Unicode and convert
the Unicode paths to the local character set for storage in the standard
path field and store UTF-8 in the Unicode extra field. This allows
directory scans to complete successfully regardless of the character
set the path is in. On Win9x systems wide character scans are not
generally supported and Zip automatically uses a local character scan
instead.
- Keep extra fields option - The default operation has been, and continues
to be, to read then strip old extra fields when reading entries from an
existing archive and then recreate the extra fields that Zip knows about.
Extra fields specific to each operating system get added by default also.
The new option -X- (negated -X) keeps any old extra fields, copying
them to the updated archive unchanged (unless Zip has updated them).
The unnegated -X still strips most all extra fields except Zip64,
Unicode, and UT time.
- License - minor updates to the license.
- Windows OEM - When compiled with WIN32_OEM (the default for WIN32),
Zip on WIN32 now stores OEM paths, which should be more compatible
with other zips and should fix some character set problems.
- Windows Archive Bit support - On Windows can now use new -AS
(include if archive bit set) option to select files with the DOS
archive bit set and use new -AC (clear archive bits) option to clear
the archive bits on files after the archive has been created.
But -DF is probably better.
- Difference mode - A new option -DF (--dif) creates an output archive
that includes only files changed or new since the input archive was
created. Can use to create incremental backups.
- File Sync - The new option -FS enables File Sync, a new mode that
synchronizes the entries in an archive with the files on the file
system, adding updating, and deleting entries as needed. This
should create the same results as creating a new archive, but
since existing entries are copied, may be much faster.
- Copy Mode - A new --out option allows creating a new archive with a
different name than the input archive, leaving the input archive
unchanged. This allows updating split archives. It also allows
for a new copy mode to select entries in one archive and copy them
directly to a new archive.
- Empty archives - Now an empty archive is created when -i or -i@ is used
and the file patterns given do not match anything. This has been
requested to support scripts.
- Global dots - A new -dg option now displays progress dots as -dd does,
but instead of displaying them for each file, the dots track the total
bytes read for the archive. The -dg option also works when -q is used
to disable most output, which allows for something like zip -qdgds 100m
to be used to not display specific files but display a dot every 100 MB
as a global status.
- Date range - Can now use -t and -tt to set a date range
- Fix options - Option -F redone and can recover files from an archive
with a mostly complete central directory more reliably, but no longer
can handle truncated archives. Option -FF redone and now can salvage
files from slightly more damaged archives, including truncated archives.
In some ways -F is less powerful but more stable than it was and -FF will
be needed where -F in Zip 2.32 was enough. One big change is -F and -FF
both now support split archives.
- Console writing - Updates to how messages are written to the console have
been made including more consistent handling of line breaks.
- Show Files options - Option -sf lists the files that would be operated
on. This option can be used alone to list the files in an archive.
Also see options -su and -sU for showing Unicode paths.
- UnZip Check - Now check that UnZip 6.00 or later is being used for
unzip if testing a Zip64 archive. A new option -TT can be used to set
the unzip to use with the -T check. Currently UnZip does not support
split archives so split archives can't be tested by UnZip.
- Streaming - Directories are now handled better when streaming.
- Case matching - Normally all matching against archive entries is case
sensitive, so *.BAR will not match or find foo.bar in an archive
when deleting, copying, or freshening entries (deleting and copying
only on VMS). New option -ic (--ignore-case) enables case insensitive
matching. Currently -ic is only implemented on WIN32 and VMS.
- Delete date bug fixed - Bug when using -d to delete files while
using -t or -tt to select the files based on date is fixed
- Large file encryption bug fixed - Fix for bug that very rarely
results in bad data being stored when deflating and encrypting
uncompressable data and resulting in CRC errors when extracting,
but the chance of error increases with file size (thanks to
WinZip for finding this bug). See CHANGES for details.
New things in Zip 3.0e
- Bugs described in Debian patches 004 (unix configure script update) and
005 (large path bug) fixed
- Various fixes
- Add optional running stats and also end stats if not all files could
be read
- Options -l and -ll now do quick binary check on first buffer and skip
formatting if first buffer has binary - still check at end to note
if formatting was done on file that was later determined to be binary,
but now potential file corruption is generally avoided
- Main binary check now uses new algorithm that should also treat UTF-8 and
other similar encodings as text, allowing proper line end translation
for UTF-8 files
- When output is not updatable by seeking back and Zip64 is enabled, output
is forced to Zip64 to avoid possible later need for Zip64 when not enabled
- More work on splits, but still not usable
- Fixes for djgpp
- Add log file capability to save all errors and optionally messages
- Add code to test for a Zip64 archive when compiled without Zip64 support
- New VC6 projects for Win32 and WinDLL
- Updates to extended help
- Changes to force-zip64 option
- ZE_BIG error now given also for files too big to read or write
- Fix file delete bug
- Update license
- Update export documentation
- Add VMS extended filename support
- Add directory traversal improvements, some for Win32 ports and some for
all ports, that can result in a 10 times increase in speed in some cases
New things in Zip 3.0d
- Some large file crypt fixes
- Some updates to support WiZ
- On VMS, changed -V (/VMS) processing to truncate file at EOF, allowing
greater compatability with non-VMS systems. New -VV (/VMS=ALL) option
saves all allocated blocks in a file. (Previously, -V did neither.)
- On VMS, pushed 2GB file size limit with -V out to 4GB
- On VMS (recent, non-VAX), with SET PROCESS /PARSE = EXTEND,
command-line case is preserved. This obviates quoting upper-case
options, like -V, when enabled
- On VMS, fixed problems with mixed-case directory names. Also changed
to keep ODS5 extended file name escape characters ("^") out of the
archived names in simple cases
- Changes to the display dots
- Option -W should now force wildcard matching to not cross directory
separators. For example, a/b*r/d will match a/bar/d but not a/ba/r/d
- Option -nw should turn off all wildcard matching so foo[bar] is matched
literally and [bar] is not considered a regular expression
- Atheos port
- Debugging of Unix and VMS large file ports. Most features may work now
on these ports for large files. Still need to fix 2 GB to 4 GB when not
compiled with large file support
- On VMS, added an open callback function which (where supported) senses
the process RMS_DEFAULT values for file extend quantity (deq)
multi-block count (mbc), and multi-buffer count (mbf), and sets the
FAB/RAB parameters accordingly. The default deq is now much larger
than before (16384 blocks, was none), and the default mbc is now 127
(up from 64), speeding creation of a large archive file. The "-v"
option shows some of the activity. On old VMS versions, RMS_DEFAULT
sensing (GETJPI) fails (silently, without "-v"), and no changes will
be made. Even there, (DCL) SET RMS /EXTEND = <big> can help
performance. RMS_DEFAULT values override built-in default values.
New things in Zip 3.0c
- Converted to using 64-bit file environment instead of transitional functions
like fseeko64 for ports that support it
- Added "--" argument to read all following arguments as paths
- Second help page added
- Binary detection adjusted from 20% binary is binary to 2%
- When -R and -i used together now -i has precedence over -R
- Archive names with spaces can now be tested on MSDOS and Win32
New things in Zip 3.0b
- Fixed ifdefs so can test base code by compiling with NO_LARGE_FILE_SUPPORT, then
compiling with NO_ZIP64_SUPPORT to test 64-bit file calls (if port enables) but
otherwise use base code, and compiling normally to enable Zip64 code
- Unix Zip64 fixes - should now be able to create and read large files
- WinDLL changes to support Zip64. Zip 3.0 dll named Zip32z64.dll
- New VB example to show use of Zip32z64.dll
- New options -sc (show final command line and exit) and -sd (show each
step zip is doing, a little different than verbose which is still there) added
to help debug but both or at least -sd might go away in the release
- Some minor posted bugs fixed (see Changes)
New things in Zip 3.0a
- Initial Zip64 support allowing large files and large numbers of files
- New command line processor
- Other changes, see file Changes
Note: Zip 2.4 was never released. That code was the start of the Zip 3.0
effort above.
New things in Zip 2.3
- IBM OS/390 port (Unix like, but EBCDIC) by Paul von Behren
- Apple Macintosh (MACOS) port by Dirk Haase
- Theos port by Jean-Michel Dubois
- Multibyte characterset support by Yoshioka Tsuneo
- Support for ISO 8601 date format with -t and -tt options
- Info-ZIP license
New things in Zip 2.2
- BEOS port by Chris Herborth
- QDOS port by Jonathan Hudson
- TANDEM port by Dave Smith
- WINDLL port (16-bit Win 3.x and 32-bit WinNT/Win95) by Mike White
- SYSV packages support by John Bush
- zip -P SeCrEt encrypts entries in the zip file with password SeCrEt
(WARNING: THIS IS INSECURE, use at your own risk)
- zip -R recurses into subdirectories of current dir like "PKZIP -rP"
- zip -x@exclude.lst excludes files specified in the file exclude.lst
- zip -i@include.lst includes files specified in the file include.lst
- zip -@ only handles one filename per line, but supports whitespace in names
- zip -t mmddyyyy, 4 digit year number for uniqueness of years beyond 2000
- zip -tt mmddyyyy only includes files before a specified date