-
The latest zipped archives of zip and unzip are all compatible with older versions of unzip (which is distributed with virtually every linux distro), so unzip 5.X can unzip them, and you can get unzip 5.X in .tar.gz form right from this site, or try info-zip.org or search the internet for binaries for your platform. What platform do you need?.
2009-01-29 13:44:12 UTC in Info-ZIP project
-
Confirmed. Okay w/me to close it.
2008-09-28 14:04:57 UTC in Info-ZIP project
-
Thank you for your efforts, Ed. I just wanted to comment that the impact is more than just the extra fields getting written to the wrong location. A memcpy() is done which violates the bounds of malloc'd() memory space, which is always bad news, plus it's in generic code (not specific to MinGW). That's why I wanted to get this in the release. I have done brief testing with the fix. Like I...
2008-07-01 13:05:45 UTC in Info-ZIP project
-
I think I found the bug. It's due to a memcpy() that writes outside the bounds of memory that was just allocated with malloc. The fix below eliminated the abort, and the resultant test archive passed the "unzip -t" test.
Fix: Lines 1192 and 1193 in zipfile.c in the function add_central_zip64_extra_field():
len = pZipListEntry->cext - oldefsize - len;
memcpy(pTemp + len...
2008-06-30 12:45:18 UTC in Info-ZIP project
-
Zip 3.0i/3.0 release candidate quits abruptly when I try to add 3 GiB worth of .mpg files (roughly 30 files) to an archive which is already just over 8 GiB in size (~2800 files). I've compiled it with MinGW in Windows XP. Below is the output of the command:
zip -r -sd test1.zip myfolder -i *.mpg
sd: Zipfile name 'test1.zip'
sd: Command line read
sd: Reading archive
sd: Scanning files...
2008-06-28 21:55:17 UTC in Info-ZIP project
-
Robert,
I've seen something similar with the MinGW compiled version, but it happens when working with a very large archive and when adding a large amount of new files (e.g. adding 1.5 GiB to a 4+ GiB archive). Is your archive much smaller? Is there any chance you could post the exact files you're working with so that I could try to reproduce the bug and see if it matches what I've already...
2008-06-25 03:07:16 UTC in Info-ZIP project
-
NOTE! The changes I've mentioned in this post are not required for correct compilation under MinGW after all. I had an issue with my include path which was causing the problem.
2008-02-18 04:37:34 UTC in Info-ZIP project
-
This is not fixed as of the latest internal release (unz60d05t.zip).
2007-11-27 15:29:19 UTC in Info-ZIP project
-
Because zip/unzip use brackets as part of their wildcard symbols, you have to use [[] to represent a left bracket, e.g.
unzip test.zip test_for_unzip[[]1].txt
From "zip -h2" output (zip 3.0):
Wildcards:
Internally zip supports the following wildcards:
? (or % or #, depending on OS) matches any single character
* matches any number of characters, including zero.
2007-11-27 03:23:10 UTC in Info-ZIP project
-
It would be nice if this could be fixed in unzip 6.0. I wouldn't think it would involve more than a few lines of code. Unzip should make every effort to restore the files exactly as they were.
2007-11-13 13:51:33 UTC in Info-ZIP project
