I'm using the very latest release of 7-zip to compress some files from the command line on my Windows XP machine.
All the small archives work fine... but the bigger ones... always give "invalid or corrupted" messages.
I have to compress from the commmand-line (7-zip)... and I have to produce zip files that can be uncompressed with the standard unzip that's built into Windows XP. (NOT forcing all my users/customers to get 7-zip.... or anything else... just to compress these files.)
All the invalid/corrupted zip files seem to have this in common:
They are big (>7gb). (The files inside are about 600mb each)
They are compressed with a basic "a" option using 7-zip
They are trying to be uncompressed with Windows XP's standard unzipper
They all test 100% ok with 7-zip's "-test" or "-list" options
Any ideas? Maybe 7-zip is using some "big file" or "high compression" algorithm, that I need to avoid? (But the "-m" option is a nightmare to figure out.)
I don't need to "fix/repair" these "corrupted" (but actually fine) zip files. I just need a way to get FUTURE files compressed with 7-zip... that can be later safely uncompressed with a basic Windows XP machine.
DEFLATE
, and open flawlessly in (Windows 8.1) Explorer and 7zip.zipinfo
shows no issues. Did you ever find out what the issue was caused by, and is there a chance the same limitation that was still in Windows XP's Explorer code, but not in that of more recent Windows versions, is still in the .NET code for unzipping?