File.Open for read access denied on executing file in Windows

Question

I have a problem with file permissions on executing files in Windows that seems to be solved after following a forum tip[1], but I cannot understand why. Maybe you guys can help.

I'm checking the banner of a file by executing it (reading the console output) and then opening the same file for reading afterwards using FileStream:

public void fileMD5(string filename) {
  if (!File.Exists(filename)) return NT.Fail("File does not exist: " + filename);

  BinaryReader stream = new BinaryReader(File.Open(filename,
      FileMode.Open, FileAccess.Read, FileShare.ReadWrite));
  int bufferSize = 4096;
  byte[] buffer = new byte[bufferSize];
  int readBytes;
  while ((readBytes = stream.Read(buffer, 0, bufferSize)) > 0) {
    md5Hasher.TransformBlock(buffer, 0, readBytes, buffer, 0);
  }
  stream.Close();
}

fileMD5('sample.exe');

and every once in a while I would get "file is being used by another process". From Wikipedia I know that Windows will set a lock on executing files denying write access[2], but I'm only reading. Also the process should have stopped already when I try to open it.

From the forum post it would seem that adding a FileShare.ReadWrite would help and it seems that It does:

FileStream stream = File.Open('sample.exe', 
    FileMode.Open, FileAccess.Read, FileShare.ReadWrite);

But I don't understand why. Is there a race condition here that I don't see?

Also the File.Open call seems to be much quicker with FileShare.ReadWrite instead of the default (which I guess is FileShare.Read).

[1] http://www.xtremevbtalk.com/archive/index.php/t-192118.html

[2] http://en.wikipedia.org/wiki/File_locking#In_Microsoft_Windows

and have you properly closed any previous handles to the file? please supply more code — mtijn, Aug 10 '11 at 08:15
There are no previous handles to the file, but more code supplied anyway. And I do wait for sample.exe to exit, yes. — Vegar Westerlund, Aug 10 '11 at 08:21

score 12 · Accepted Answer · answered Aug 10 '11 at 08:21

12

When you do not specify a FileShare parameter the default for this option is FileShare.None, in fact the code within the File class simply executes this:

public static FileStream Open(string path, FileMode mode, FileAccess access)
{
    return File.Open(path, mode, access, FileShare.None);
}

With regards to the performance I can only imagine that specifying FileShare.ReadWrite means that Windows does not need to aquire a lock on the file.

As far as the "file is being used by another process" error you are getting does this issue go away if you wrap the usage of the stream variable within a using block so that the Stream gets disposed of as soon as you are done?

using (var stream = File.Open('sample.exe', FileMode.Open, FileAccess.Read))
{
  //do something with the stream here
}

answered Aug 10 '11 at 08:21

lowds

1,085
8
12

The problem goes away if I add FileShare.ReadWrite to the Open call. Disposing the stream quickly doesn't really matter since I cannot create it in the first place. The issues seems to be that even though the execution of the file has stopped the locks are still there (or in the process of being removed) as I open the file for reading. – Vegar Westerlund Aug 10 '11 at 08:36
Ha, the clue to the solution was actually in the question: "which I guess is FileShare.Read". You should never guess in programming and as lowds pointed out the default is actually FileShare.None. For an MD5 check it is okay to allow others to read so I should be specific about that. Correct implementation should be: File.Open('sample.exe', FileMode.Open, FileAccess.Read, FileShare.Read); – Vegar Westerlund Aug 10 '11 at 09:18

score 2 · Answer 2 · answered Aug 10 '11 at 08:17

2

You should close your FileStream and then afterwards open a new FileStream.

FileShare is needed when applications want to share a file not only one application or an application has multiple readers or writers at the same time.

Why? It's get messy when everyone can read and write at the same time. In this case you should better explicitly set it so its clear that its get messy. :)

answered Aug 10 '11 at 08:17

Skomski

4,827
21
30

I have no writers, but I know that Windows will set some permissions as the file is executed. I just don't know how that works. It should allow read access, but somehow that fails 1 out of 50 runs of this check. – Vegar Westerlund Aug 10 '11 at 08:24
@Vegar It will always lock the file when you read or write when you set FileShare.None. – Skomski Aug 10 '11 at 08:36

score 1 · Answer 3 · answered Nov 07 '12 at 15:02

It seems like specifying the wrong FileShare can prohibit you from accessing a file. If you specify FileShare.Read but some other application has currently write access to that file, you cannot access the file, since your FileShare.Read is currently not satisfiable. FileShare.ReadWrite is less restrictive, because its easier satisfiable. Source: http://blogs.msdn.com/b/oldnewthing/archive/2004/05/11/129759.aspx

score 1 · Answer 4 · answered Aug 10 '11 at 08:23

It has to do with the underlying windows API CreateFile flags. See http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx for an overview, http://blogs.msdn.com/b/larryosterman/archive/2004/05/13/131263.aspx for en explanation on how NT (and following) load the execs with FILE_SHARE_DELETE

And especially this

http://blogs.msdn.com/b/oldnewthing/archive/2004/05/11/129759.aspx

For a great explanation on how the share permission and desired access compose together!

File.Open for read access denied on executing file in Windows

4 Answers4