File.WriteAllBytes does not block

Question

I have a simple piece of code like so:

File.WriteAllBytes(Path.Combine(temp, node.Name), stuffFile.Read(0, node.FileHeader.FileSize));

One would think that WriteAllBytes would be a blocking call as it has Async counterparts in C# 5.0 and it doesn't state anywhere in any MSDN documentation that it is non-blocking. HOWEVER when a file is of a reasonable size (not massive, but somewhere in the realms of 20mb) the call afterwards which opens the file seems to be called before the writing is finished, and the file is opened (the program complains its corrupted, rightly so) and the WriteAllBytes then complains the file is open in another process. What is going on here?! For curiosity sake, this is the code used to open the file:

System.Diagnostics.Process.Start(Path.Combine(temp, node.Name));

Anyone experience this sort of weirdness before? Or is it me being a blonde and doing something wrong?

If it is indeed blocking, what could possibly be causing this issue?

EDIT: I'll put the full method up.

var node = item.Tag as FileNode;
stuffFile.Position = node.FileOffset;
string temp = Path.GetTempPath();
File.WriteAllBytes(Path.Combine(temp, node.Name), stuffFile.Read(0, node.FileHeader.FileSize));
System.Diagnostics.Process.Start(Path.Combine(temp, node.Name));

What seems to be happening is that Process.Start is being called BEFORE WriteAllBytes is finished, and its attempting to open the file, and then WriteAllBytes complains about another process holding the lock on the file.

Answer 1

No, WriteAllBytes is a blocking, synchronous method. As you stated, if it were not, the documentation would say so.

Possibly the virus scanner is still busy scanning the file that you just wrote, and is responsible for locking the file. Try temporarily disabling the scanner to test my hypothesis.

Answer 2

I think your problem may be with the way you are reading from the file. Note that Stream.Read (and FileStream.Read) is not required to read all you request.

In other words, your call stuffFile.Read(0, node.FileHeader.FileSize) might (and definitely will, sometimes) return an array of node.FileHeader.FileSize which contains some bytes of the file at the beginning, and then the 0's after.

The bug is in your UsableFileStream.Read method. You could fix it by having it read the entire file into memory:

    public byte[] Read(int offset, int count)
    {
        // There are still bugs in this method, like assuming that 'count' bytes
        // can actually be read from the file
        byte[] temp = new byte[count];

        int bytesRead;
        while ( count > 0 && (bytesRead = _stream.Read(temp, offset, count)) > 0 )
        {
            offset += bytesRead;
            count -= bytesRead;
        }

        return temp;
    }

But since you are only using this to copy file contents, you could avoid having these potentially massive allocations and use Stream.CopyTo in your tree_MouseDoubleClick:

var node = item.Tag as FileNode;
stuffFile.Position = node.FileOffset;
string temp = Path.GetTempPath();
using (var output = File.Create(Path.Combine(temp, node.Name)))
    stuffFile._stream.CopyTo(output);

System.Diagnostics.Process.Start(Path.Combine(temp, node.Name));

Answer 3

A little late, but adding for the benefit of anyone else that might come along.

The underlying C# implementation of File.WriteAllBytes may well be synchronous, but the authors of C# cannot control at the OS level how the writing to disk is handled.

Something called write caching means that when C# asks to save the file to disk, the OS may return "I'm done" before the file is fully written to the disk, causing the issue OP highlighted.

In that case, after writing, it may be better to sleep in a loop and keep checking to see if the file is still locked before calling Process.Start.

You can see that I run into problems caused by this here: C#, Entity Framework Core & PostgreSql : inserting a single row takes 20+ seconds

Also, in the final sentence of OPs post "and then WriteAllBytes complains about another process holding the lock on the file." I think they actually meant to write "and then Process.Start complains" which seems to have caused some confusion in the comments.