I'm using the latest build for this dll in a VS 2010 .Net 4.0 windows service project. The unzip function is below and it completes without error but, after it runs I have to shutdown the service to be able to delete the zip file or wait for it to process
another zip file for it to delete the previous zip file. The delete doesn't happen directly from this function, it will be called later to keep disk space from getting used up. I've searched the fourm and saw the other threads like this going back some time
and I even tried using the "using()" method with no improvement.
I've tried with a split zip file as well and the segment files delete without problem, its just the last file with .zip on the end that stays locked up.
private void UnZip_File(string sZipFile, string sExtractPath)
ZipFile zip = null;
zip = ZipFile.Read(sZipFile);
zip.ExtractExistingFile = ExtractExistingFileAction.OverwriteSilently;
zip.Password = @"<REMOVED for posting>
zip.ParallelDeflateThreshold = -1;
zip.FlattenFoldersOnExtract = true;
catch (Exception ex)
Exception_Handler("UnZip_File", ex, bUseExceptionReport);
if (zip != null)
zip = null;
I know there isn't much work going into this by looking at the last build date but any help would be appreciated. I really dont want to start looking for another zip componenet, I really like this one. Im using it in another project without problems but
that one is only zipping the files and not extracting them.
May 19, 2011 at 7:12 PM
Well there isn't much new development on DotNetZIp, but i haven't gotten tons of high-value requests for new features either. So... basically it works pretty well, which is why it hasn't been changed in a while.
As regards your particular problem, it seems like the file is being held by someone or something. It's puzzling to me that it would be the code you've shown here. here's why: I have a test suite with about 300 test cases, many of them deal with
the issue of open file streams, and being able to delete the files. In fact, before any test case can be declared successful, the zipfiles get deleted, whether the test case was for reading or writing zip files. So this is an area that has been exercises many
many many times, in many many different scenarios.
could it be that there is some other code in your service, somewhere else that is opening the file and keeping it open? When extracting, DotNetZip opens the file with a sharemode that allows reading by other apps. So it's possible that some other code
has opened the file, and then DotNetZip opens, reads, and extracts. When you call zip.Dispose, that leaves still the other filestream open, somewhere. Is this possible?
I'm just trying to imagine the failure scenario.
About the using() clause - it sounds like you are aware, but using() is equivalent to the try..catch..finally you have in place. Employing a using clause won't change things for you, since you already have a finally clause where you call Dispose().
Also, processing "another zip file" with DotNetZip will not magically close the stream for the first one. DotNetZip doesn't keep state around, about which files were opened or not. This state is kept only by application code, in the form of object
references. Is it possible that you have a stream opened somewhere, and when your service processes "another zip file" it drops the old stream variable, wipes it out and puts a new one in the same variable?
If this were my problem, I would grab the sysinternals tools - and run the listofds tool (something like that) that lists the open file descriptors on a machine. It may give you some insight into who or what is opening the file, how many times, when, and
These are the things I would look for.