Firstly, thank you for a most interesting post. I wish all our posters were this good at describing things :-)
I don't have a lot of time spare today so this post will be brief, but hope to give you something to go on.
Have you seen the sample code in the wiki? I have done a lot of work on these, and I'm sure they would not have been there when you were writing your application originally. The most recent sample covers "Create a zip with FastZip using progress events".
SharpZipLib - Code Reference
Create a Zip with full control over contents
You could use the Progess Events as illustrated in the FastZip sample, but that still won't solve the "I can't grab logs that are open for write" problem.
If it were me, I would change to using ZipFile or ZipOutputStream instead. Of those two, ZipFile is the better choice for your case.
I suggest using the code in the "Create a Zip with full control over contents" sample. You can see how straight away it gives you total control over every aspect of your operation. You can change the File.Open parameters so you can read the in-use files, you can add error handling in a much easier way, and you can have progress events in whichever level of granularity suits you.
Re your questions:
- Handles: Does SharpZipLib open the file handles at AddEntry time or right before it processes the file inside CommitUpdate?
- will get back to you on that.
- Errors: If I want to append an error file to the zip after the rest
of the processing is complete, is there a way I can do that without
forcing it to copy the zip file again? (Perhaps if I supply a
zero-length file as the last file initially and then update it?)
- with ZipFile you just add that file at the end of the process. No problem.
- Scale: How big will SharpZipLib permit these files to be? (Assume
the 64 flag is on.) How many files can they contain? Will a single Zip
manage hundreds of gigabytes of 100Kb files, for instance? Or are there
system resources that are held onto during the creation of the zip that
limit how big we can go?
- The limit is gigantic, way bigger than any disk drive.
- Version: I am currently using version 0.86 from back in May when I
first put it into my project. Does the CommitUpdate bug with silent file
open failures in that version affect both ZipFIle and FastZip? Or just
FastZip? It might help explain some odd behaviors we've seen.
- bug was FastZip only. my bad, bug was in CommitUpdate which is in ZipFile. Only affected BeginUpdate - CommitUpdate. And the bug is fixed in 0.86 in case that's not clear.
Got to go. More later.