File sharing not working as expected

Question

I have a file sharing issue where my process is trying to read a log file whilst it is currently still open by NLog. In diagnosing the issue, I found something surprising. The following fails:

using (var fileStream1 = new FileStream("test.file", FileMode.Append, FileAccess.Write, FileShare.Read))
using (var fileStream2 = new FileStream("test.file", FileMode.Open, FileAccess.Read, FileShare.Read))
{
}

The second FileStream constructor call fails with:

System.IO.IOException was unhandled
  Message=The process cannot access the file 'c:\...\test.file' because it is being used by another process.
  Source=mscorlib
  StackTrace:
       at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
       at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath)
       at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)

This is despite the fact that the first FileStream indicates its willingness to share reading. What I found even more surprising was that this works:

using (var fileStream1 = new FileStream("test.file", FileMode.Append, FileAccess.Write, FileShare.Read))
using (var fileStream2 = new FileStream("test.file", FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
{
}

Um, yes, requesting more access when opening the second stream actually bypasses the issue. I am completely baffled as to why that is the case, and can only assume I am misunderstanding something. I've read through the API docs but they just support my current mental model for how this should work, contrary to how it does work.

Here are some supporting quotes from the docs:

A typical use of this enumeration is to define whether two processes can simultaneously read from the same file. For example, if a file is opened and Read is specified, other users can open the file for reading but not for writing.

Here's another gem:

The following FileStream constructor opens an existing file and grants read-only access to other users (Read).

FileStream s2 = new FileStream(name, FileMode.Open, FileAccess.Read, FileShare.Read);

Can anyone shed any light on this behavior. I'm testing this on .NET 4 % Windows XP.

Answer 1

 var fileStream2 = new FileStream(..., FileShare.Read)

This trips up lots of programmers. Everybody assumes that this added read sharing. It didn't, the original file access request already allowed reading and specifying it again doesn't change anything. Instead it denies write sharing. And that cannot work because somebody already got write access. And is using it, you cannot remove that right. So your request to access the file will fail.

You must include FileShare.Write.

Answer 2

What actually happens, is that the fileStream2 can not change the subsequent access to a file which already is open for writing (or appending) by fileStream1.

fileStream2 will successfully open the file leaving a FileShare.Read as "legacy" for subsequent access only if there are no processes which already have Write file access to it. Even more, in our example we are talking about the same process. It wouldn't make too much sense to modify a file stream's properties from another file stream, wouldn't it?

Maybe the following comparison explains it even better:

// works
using (var fileStream1 = new FileStream("test.file", FileMode.OpenOrCreate, FileAccess.Read, FileShare.ReadWrite))
using (var fileStream2 = new FileStream("test.file", FileMode.Append, FileAccess.Write, FileShare.Read))
using (var fileStream3 = new FileStream("test.file", FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
{
}

// fails
using (var fileStream1 = new FileStream("test.file", FileMode.OpenOrCreate, FileAccess.ReadWrite, FileShare.ReadWrite))
using (var fileStream2 = new FileStream("test.file", FileMode.Append, FileAccess.Write, FileShare.Read))
using (var fileStream3 = new FileStream("test.file", FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
{
}

In my opinion, the description phrase for FileShare.Read:

Allows subsequent opening of the file for reading.

should be read as

The subsequent access to the file is restricted only for reading, including the access of already existing locks.

[Update]

I haven't parsed through the code, but it seems that these two links could shed some light over the internal functioning of the constructor:

The internal FileStream ctor

The internal FileStream Init method

Answer 3

I think I've found the answer in the documentation for CreateFile.

In the discussion of the dwShareMode parameter, it says:

FILE_SHARE_READ 0x00000001 Enables subsequent open operations on a file or device to request read access. Otherwise, other processes cannot open the file or device if they request read access. If this flag is not specified, but the file or device has been opened for read access, the function fails.

FILE_SHARE_WRITE 0x00000002 Enables subsequent open operations on a file or device to request write access. Otherwise, other processes cannot open the file or device if they request write access. If this flag is not specified, but the file or device has been opened for write access or has a file mapping with write access, the function fails.

That fundamentally changes my understanding of how file sharing works.

Answer 4

Fourth parameter you pass

share
A constant that determines how the file will be shared by processes.

determines in what mode others can open the file. So obviously - when you're trying to open the file with fileshare mode "read" and already have the same file open in Write mode - operation fails.