26

With the following file reading code:

using (FileStream fileStream = new FileStream(fileName, FileMode.Open, FileAccess.Read, FileShare.None))
{
    using (TextReader tr = new StreamReader(fileStream))
    {
        string fileContents = tr.ReadToEnd();
    }
}

And the following file write code:

using (TextWriter tw = new StreamWriter(fileName))
{
    tw.Write(fileContents);
    tw.Close();
}

The following exception details are seen:

The process cannot access the file 'c:\temp\myfile.txt' because it is being used by another process.

What is the best way of avoiding this? Does the reader need to retry upon receipt of the exception or is there some better way?

Note that the reader process is using a FileSystemWatcher to know when the file has changed.

Also note that, in this instance, I'm not looking for alternatives ways of sharing strings between the 2 processes.

Jeff Yates
  • 61,417
  • 20
  • 137
  • 189
Iain
  • 10,433
  • 16
  • 56
  • 62

8 Answers8

39

You can open a file for writing and only lock write access, thereby allowing others to still read the file.

For example,

using (FileStream stream = new FileStream(@"C:\Myfile.txt", FileMode.Open, FileAccess.ReadWrite, FileShare.Read))
{
   // Do your writing here.
}

Other file access just opens the file for reading and not writing, and allows readwrite sharing.

using (FileStream stream = new FileStream(@"C:\Myfile.txt", FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
{
   // Does reading  here.
}

If you want to ensure that readers will always read an up-to-date file, you will either need to use a locking file that indicates someone is writing to the file (though you may get a race condition if not carefully implemented) or make sure you block write-sharing when opening to read and handle the exception so you can try again until you get exclusive access.

Jeff Yates
  • 61,417
  • 20
  • 137
  • 189
  • But in this case, if I understand the workings correctly, you could read an incomplete file? – Mitchel Sellers Oct 21 '08 at 14:46
  • 3
    That is true, yes. That's always going to be the case if you allow more than one consumer to access the file. The only way to achieve this and synchronize is to either use a lock file, or to catch the access exception and try again until you get exclusive access. – Jeff Yates Oct 21 '08 at 14:56
  • I'm a little confused because this seems to contradict the accepted answer to this question: http://stackoverflow.com/questions/25097773/system-io-filestream-fileaccess-vs-fileshare because it states that for FileAcces.ReadWrite you must use FileShare.None. – user2481095 Aug 16 '16 at 22:35
  • "But in this case, if I understand the workings correctly, you could read an incomplete file?" That is why I created a wait mechanism /// /// /// /// Key type. public class ThreadAccessSynchronizer – Hrvoje Batrnek Apr 29 '20 at 01:05
7

If you create a named Mutex you can define the mutex in the writing application, and have the reading application wait until the mutex is released.

So in the notification process that is currently working with the FileSystemWatcher, simply check to see if you need to wait for the mutex, if you do, it will wait, then process.

Here is a VB example of a Mutex like this that I found, it should be easy enough to convert to C#.

Mitchel Sellers
  • 62,228
  • 14
  • 110
  • 173
3

Get your process to check the status of the file if it is being written to. You can do this by the presence of a lock file (i.e. the presence of this other file, which can be empty, prevents writing to the main file).

Even this is not failsafe however, as the two processes may create the lock file at the same time - but you can check for this before you commit the write.

If your process encounters a lock file then get it to simply sleep/wait and try again at a predefined interval in the future.

Anthony
  • 1,306
  • 4
  • 13
  • 23
3

Is there any particular reason for opening the file with FileShare.None? That'll prevent the file from being opened by any other process.

FileShare.Write or FileShare.ReadWrite should allow the other process (subject to permissions) to open and write to the file while you are reading it, however you'll have to watch for the file changing underneath you while you read it - simply buffering the contents upon opening may help here.

All of these answers, however, are equally valid - the best solution depends on exactly what you're trying to do with the file: if it's important to read it while guaranteeing it doesn't change, then lock it and handle the subsequent exception in your writing code; if it's important to read and write to it at the same time, then change the FileShare constant.

symonc
  • 31
  • 2
2

You can use a Mutex object for this.

leppie
  • 115,091
  • 17
  • 196
  • 297
  • Thanks for the quick answer. What if the processes are on different systems and the file is being shared over the network? – Iain Oct 21 '08 at 14:33
  • Hehe, that wont work then. Use a zero-byte 'lock' file like Linux services does then :) – leppie Oct 21 '08 at 14:38
  • Or better still write a service, and use it to control access to the file with a Mutex, This should be expanded with a sample and a global mutex cause the "popular" answer to this question at the moment is really risky code. – Sam Saffron Oct 23 '08 at 12:06
2

The reader and writer both need retry mechanisms. Also FileShare should be set to FileShare.read for the readers and FileShare.none for the writer. This should ensure that the readers don't read the file while writing is in progress.

The reader (excluding retry) becomes

using (FileStream fileStream = new FileStream(fileName, FileMode.Open, FileAccess.Read, FileShare.Read))
{
    using (TextReader tr = new StreamReader(fileStream))
    {
        string fileContents = tr.ReadToEnd();
    }
}

The writer (excluding retry) becomes:

FileStream fileStream = new FileStream(fileName, FileMode.Create, FileAccess.Write, FileShare.None);
using (TextWriter tw = new StreamWriter(fileStream))
{
    tw.Write(fileContents);
    tw.Close();
}
Iain
  • 10,433
  • 16
  • 56
  • 62
1

The best thing to do, is to put an application protocol on top of a file transfer/ownership transfer mechanism. The "lock-file" mechanism is an old UNIX hack that has been around for ages. The best thing to do, is to just "hand" the file over to the reader. There are lots of ways to do this. You can create the file with a random file name, and then "give" that name to the reader. That would allow the writer to asynchronously write another file. Think of how the "web page" works. A web page has a "link" to more information in it, for images, scripts, external content etc. The server hands you that page, because it's a coherent view of the "resource" you want. Your browser then goes and gets the appropriate content, based on what the page description (the HTML file or other returned content), and then transfers what it needs.

This is the most resilient type of "sharing" mechanism to use. Write the file, share the name, move to the next file. The "sharing the name" part, is the atomic hand off that makes sure that both parties (the reader and the writer) agree that the content is "complete."

grwww
  • 3,881
  • 1
  • 13
  • 2
1

Write to a temp file, when finished writing rename/move the file to the location and/or name that the reader is looking for.

KristoferA
  • 12,287
  • 1
  • 40
  • 62