1

Closed

DotNetZip Library Support for updating Zip64 comments

description

I have a 10GB SQL Server database file in a DotNetZip created archive using the UseZip64WhenSaving = AsNecessary option.
 
1) If I open the archive with DotNetZip and try to save, the file become corrupt. If I open the archive and set the UseZip64WhenSaving = AsNecessary option and then save, the file stays valid.
 
2) If I open the archive and set the UseZip64WhenSaving = AsNecessary option, change a comment on a non-Zip64 compressed file, and then save, the file stays valid. If I open the archive and set the UseZip64WhenSaving = AsNecessary option, change a comment on the large Zip64 compressed file, and then save, the file becomes corrupt.
Closed Aug 3, 2011 at 7:17 PM by Cheeso
This is fixed in v1.9.1.6.

comments

Cheeso wrote Nov 25, 2009 at 1:04 PM

Thanks for reporting this. couple things
  1. yep - this is documented behavior. I realized when I was building it that this was probably non-optimal. I've made a small change that now does the right thing when reading a Zip64-enhanced zip file. In other words, if you read a zip64 archive with dotnetzip, then add an entry (or make some other change), then save it, it just works. With this change, there's no need to set UseZip64WhenSaving in this case. This change will be in a future release of v1.9.
  2. I ran a couple tests and could not reproduce this behavior. The files are quite large and the tests take a looooong time to run, on my meager hardware. If you have additional information there, I'd like to have it. how large is the zipfile in total? How large is the compressed entry for which you modify the comment? are there other large (>4gb) entries in the zipfile? how many entries total? 10? 1000's ? 100,000?
Any chance you could make one of those corrupt zip files available for download?

stonethomasjames wrote Nov 30, 2009 at 8:44 PM

1) Thanks.

2a) Zip file total is 600MB.

2b) Compressed entry is 99.99% of the 600MB.

2c) Only one large (>4gb) entry in the zip file.

2d) Two entries total. Second entry is a 10MB file.

2e) As the zip files are of company data, I could not make them available for download.

The problem was nothing in specific to the large file. It was specific to how the DotNetZip library handled re-saving the opened Zip64 file when the comment on the one Zip64-compressed entry was modified. Go ahead and make a ZIP of a DVD rip and you should get the same problem.

#1 was annoying. #2 was a pushing-the-evelope test. I appreciate your adding Zip64 to the library.

Cheeso wrote Dec 2, 2009 at 12:05 PM

That change (#1) is now available in v1.9.0.31.

About your answers to #2 - ok. I'll have another look. My current tests have been different - 10's of files, and one of them is over 5gb, but it's uncompressible. My goal was to produce a zip archive that was larger than 4gb, but you're saying it happens when the archive is just 600mb. I'll see if using something more similar to what you do will allow me to reproduce the problem.

Sign in to add a comment