I have a similar issue. That is, after extracting all files from a SPLIT archive, I would like to be able to delete the source zip file(s). I can successfully delete the segments .z01 .z02 .z03 etc, but, like your example, the final .zip
cannot be deleted (... because the file is being used by another process).
The underlying issue is that somewhere there is a file and/or stream that is not being .Close() and is instead just "left hanging" because it still has some internal reference (which I have not found yet).
So, without fully studying/understanding the entire issue, and how this area of the code is supposed to work, I have a
VERY-UGLY HACK-FIX that has worked for us. I certainly
DO NOT propose this as a final fix, and in our implementation have wrapped the following code sample with additional checks to ensure that this code is only enabled/run under the exact conditions described above ... and then our application exits
very soon thereafter.
In the ZipFile.cs file, in the private Dispose() method, after the "if" statement (something cleaning up ParallelDeflator), approx line 3244, you can add code something like:
if (_entries.Values != null)
foreach (var zfe in _entries.Values)
if (zfe.ArchiveStream != null)
This will close all the streams that are used, without concern as to where they came from.
Note this also breaks several Unit Tests, so "user beware". I have not studied the whole problem in enough detail (and understanding) to be able to provide a "real fix". I need some
help here ...