DotNetZip created backup sometimes causes issues in (only) some unzip programs

[FFF]

Dick,
just for completeness: Did you try to open your problem zips with the new 7-zip beta 23.00 from May, 7th?

[ic2]

Hello Arne, Karl,

I just installed that beta version of 7-Zip; same result. Earlier I installed a program called Peazip, same result. So you would say DotNetZip is doing something wrong but only in some unknown situation. But on the other hand, Explorer sees all directories (and can open files if not AES256 encrypted)

Dick

[ArneOrtlinghaus]

For our program delivery and for our Oracle database backups we are also using different ZIP mechanisms. Zipping big files or many files or open files gives sometimes undesired effects. Also "fighting" against Antivirus programs is time-consuming and difficult if the files are in one big zip-container. For example we had cases where open files were missing in the zips and nobody realized the danger of having incomplete backups.

So If it is possible to devide zipping in some files I prefere this over having only one big zip. Better to find a conservative working way with existing possibilities then taking risks.

Arne

[ic2]

Over a year after this post I finally found the cause, thanks to logging. In this log I found an exception:

TimeSpan overflowed because the duration is too long. (exception during Saving_EntryBytesRead/Timespan)

So I wondered what TimeSpan could have to do with the zip process. In my program I use TimeSpan's for some progress info on the screen, like time elapsed and estimated time until the zipbackup is ready. So I disabled all the timespans and...the backup set which always failed now worked (that was: I get a complete backup but it only shoed in Explorer, in 7-zip or PeaZip it shows only the first file added to the zip).

I was unable to find out why only certain combinations of files/directories caused this error. What a working or faulty combination was didn't make sense. E.g. splitting a failing backup set in 2 backup sets worked. So you would say: the larger size caused the exception. But another set, witch a much larger zip file and number of files worked perfectly...
Eventually I didn't care as adding an error handler directly round the code the offending Timespan seems to solve the whole issue. And even without compromising the reported times.

Also I did not find out what actually happened when this exception occurred, that made the end result unreadable in everything except Explorer. The program continued (thanks to error handlers on a 'higher' level) until the end but apparently something was done/written differently when this error appears making the zip file unusable except in Explorer.

Bottom line is that DotNetZip was not (directly at least) to blame and that is good to know.

Dick

[Fabrice]

Hi Dick,
first, I'm happy you have found the error.

But I'm curious to know where you were calculating that TimeSpan ? Was it in a CallBack/Event Handler of the Zipping task ?
If so, the exception was maybe breaking the correct cleanup & save of zip entries ??

Regards,
Fab

[ic2]

Hello Fabrice,

But I'm curious to know where you were calculating that TimeSpan ? Was it in a CallBack/Event Handler of the Zipping task ?
If so, the exception was maybe breaking the correct cleanup & save of zip entries ??

I checked that. After collecting all the files (with a call to a method creating zip.AddFile), there is some code to actually create the zip file. Two important lines in there (C#) are:

Code: Select all

zip.SaveProgress += ZipSaveProgress;	// 17-2-2022 add progress bar, from https://www.whitebyte.info/programming/saveprogress-example-for-dotnetzip
zip.Save(cZipName);

ZipSaveProgress is a default callback method of DotNetZip implementing SaveProgress to maintain a progress bar and I added in this method:

Code: Select all

TimeSpan tsRemaining = TimeSpan.FromMinutes(dbRemainingTime); // Calculate remaining timespan

This is where it went wrong. Now the call back method has it's own error handler, the problem seems gone. Until then, the calling method (collecting the files and creating the zip) had an error handler. When an error in the callback method ZipSaveProgress was still only handled within this 'parent' method, the zip file got the described issues.

It is difficult to determine what exactly is skipped (the whole 'Save' method of DotNetZIp is a bit of a black box). I would expect the zip file to be not created at all (because it ended in an exception in this main method containing Save and the progress call back method), not a full blown zip file which is only readable in Explorer. (which is not a good alternative because it is terribly slow and does only support WinZip encryption, not AES)

And I also do not know why / under which circumstances the TimeSpan actually lead to the exception. There seems to be nothing special into the selections that would cause the timespan to overflow....

Dick