System.IO.Compression.ZipArchive keeps file locked after dispose?

Question

I have a class that takes data from several sources and writes them to a ZIP file. I've benchmarked the class to check if using CompressionLevel.Optimal would be much slower than CompressionLevel.Fastest. But the benchmark throws an exception on different iterations and in different CompressionLevel values each time I run the benchmark.

I started removing the methods that add the file-content step by step until I ended up with the code below (inside the for-loop) which does basically nothing besides creating an empty zip-file and deleting it.

Simplified code:

var o = @"e:\test.zip";
var result = new FileInfo(o);
for (var i = 0; i < 1_000_000; i++)
{
    // Alternate approach
    // using(var archive = ZipFile.Open(o, ZipArchiveMode.Create))
    using (var archive = new ZipArchive(result.OpenWrite(), ZipArchiveMode.Create, false, Encoding.UTF8))
    {
    }

    result.Delete();
}

The loop runs about 100 to 15k iterations on my PC and then throws an IOException when trying to delete the file saying that the file (result) is locked.

So... did I miss something about how to use System.IO.Compression.ZipArchive? There is no close method for ZipArchive and using should dispose/close the archive... I've tried different .NET versions 4.6, 4.6.1, 4.7 and 4.7.2.

EDIT 1:
The result.Delete() is not part of the code that is benchmarked

EDIT 2:
Also tried to play around with Thread.Sleep(5/10/20) after the using block (therefore the result.Delete() to check if the lock persists) but up to 20ms the file is still locked at some point. Didnt tried higher values than 20ms.

EDIT 3:
Can't reprodurce the problem at home. Tried a dozen times at work and the loop never hit 20k iterations. Tried once here and it completed.

EDIT 4:
jdweng (see comments) was right. Thanks! Its somehow related to my "e:" partition on a local hdd. The same code runs fine on my "c:" partition on a local ssd and also on a network share.

Answer 1

In my experience files are may not be consistently unlocked when the dispose method for the stream returns. My best guess is that this is due to the file system doing some operation asynchronously. The best solution I have found is to retry the delete operation multiple times. i.e. something like this:

    public static void DeleteRetrying(this FileInfo self, int delayMs = 100, int numberOfAttempts = 3)
    {
        for (int i = 0; i < numberOfAttempts-1; i++)
        {
            try
            {
                self.Delete();
            }
            catch (IOException)
            {
                // Consider making the method async and
                // replace this with Task.Delay
                Thread.Sleep(delayMs);
            }
        }
        // Final attempt, let the exception propagate
        self.Delete();
    }

This is not an ideal solution, and I would love if someone could provide a better solution. But it might be good enough for testing where the impact of a non deleted file would be manageable.