sharing of textfile (FileShare method not working)

Hi guys,

I'm working on application with multiple instances running in the same machine. In this application I'm accessing file "test.txt" and the other instances also needs this file. But the first application who will get to open the "test.txt" will have the write access and the other instances will only have read access.

Below is my code snippet:

if (singleInstance)

{FileStream fs = File.Open(@"C:\test.txt", FileMode.Open, FileAccess.ReadWrite, FileShare.Read);}

else

{FileStream fs = File.Open(@"C:\test.txt", FileMode.Open, FileAccess.Read)}

When I tried running my application, I open the test.txt in the notepad and I can open it but can't do any modification so it's functioning just fine. When I tried running multiple application I'm getting an error already saying somebody is already using the file :(. What do you think is my mistake

Bdw, I'm not closing the file until my application is close bec I'm updating it every 30 secs.

Thanks in advance




Answer this question

sharing of textfile (FileShare method not working)

  • Ahmad Shahwan

    You'll either end up with R/W access to a file that you opened with Read sharing. Or you'll end up with Read access to a file that you opened with R/W sharing.

    -- I really intend that the one doing the R/W access will share the file in read mode only. The one reading the file will share file to r/w mode.

    Do all your apps need to read from and write to the file If so, they should all use FileAccess.ReadWrite and FileShare.ReadWrite

    -- The file will be access an app and this app can be in multiple instance. The first app that will be launched will do the R/W access and with "read" share mode, so that the other instances of this app can read the file and at the same time allowing the first app to do some writing that's why I make it as "readwrite" share.

    However, what are you doing to synchronize your processes

    -- I don't need synchronization because even there will be multiple apps the first launch app will be the only one who will do the changes in the text file.

    If process A modified the file, how does process B get to know about that

    -- I will check if the file is exclusive in one process and if not process B will just open the file as read-only so that I can get the details inside the file.

    How are you coordinating your writes - how do you make sure that process A and process B aren't just overwriting each other's changes

    -- The first launch app will be the only one will do the changes in the text file so coordinating is not necessary.



  • danmbuen2

    I got it already.

    Actually the code looks like this

    try

    {

    FileStream fs = File.Open(@"C:\test.txt", FileMode.Open, FileAccess.ReadWrite, FileShare.Read);

    }

    catch

    {

    FileStream fs = File.Open(@"C:\test.txt", FileMode.Open, FileAccess.Read, FileShare.ReadWrite);

    }

    If the first part fail it means some application is already accessing the "text.txt" that's why the file share is in readwrite mode because somebody is already accessing the said file and with some write access.

    Thanks anyway.



  • Gagandeep Singh

    I think you should consider use of Mutexes

    The MicrosoftR .NET Framework Class Library includes a ReaderWriterLock class in the System.Threading namespace that lets you obtain multiple-reader/single-writer semantics.

    Take a look at this article in MSDN : Reader/Writer Locks and the ResourceLock Library

    hope this helps


  • Night_ROamer

    Hi shellShock,

    If I will be doing the

    FileStream fs = File.Open(@"C:\test.txt", FileMode.Open, FileAccess.Read, FileShare.Read);

    in my catch part I will get an error stating that another process is accessing the file.

    As much as I wanted to stay the share mode of the text file as read, but I dont have any idea right now how will it work so what I have right now is just a work around. If you happen to find this out please let me know.

    Thanks



  • .NETPhreak

    You've shown us two different branches of an 'if' construct there. But presumably you're only actually executing one of those in the case that fails. I'm guessing it's probably the 2nd one that's causing you the problem, but please tell me if I guessed wrong.

    The problem with that second one is that you don't specify a FileShare. You're calling the overload of File.Open where you specify a path, how you want to open the file (FileMode), and what access you require. But you're not specifying a FileShare.

    It defaults to FileShare.None in this case.

    In other words, you've implicitly specified exclusive access. (Were you presuming that FileAccess.Read would cause a default of FileShare.Read If so, you presumed incorrectly. As the documentation says, that overload of File.Open returns an unshared FileStream.)

    Change that second branch to:

    FileStream fs = File.Open(@"C:\test.txt", FileMode.Open, FileAccess.Read, FileShare.Read);

    And it should work.


  • creaturita

    Your share modes don't match your access modes.

    You'll either end up with R/W access to a file that you opened with Read sharing. Or you'll end up with Read access to a file that you opened with R/W sharing.

    Do you really mean to do that I can't imagine any scenario in which that would be the right thing to do!

    Is your application the only one using this file If so, this try...catch structure is almost certainly a mistake. You should pick one FileShare and one FileAccess mode that will work property no matter how many of your apps are running.

    Do all your apps need to read from and write to the file If so, they should all use FileAccess.ReadWrite and FileShare.ReadWrite.

    However, what are you doing to synchronize your processes If process A modified the file, how does process B get to know about that How are you coordinating your writes - how do you make sure that process A and process B aren't just overwriting each other's changes


  • jazo ichikawa

    Hi IanG,

    Although I'm still not sure how a reading process can tell the difference between a write-in-progress, and a completed write. There isn't any way of forcing writes to be atomic in .NET. So aren't your readers going to be able to see partial results - nice thoughts.

    So is it now working as you expect with that latest version of the code, or are you still seeing problems

    I'm still seeing problems bec when I launch the 3rd app if I'm going to check the exclusivity of the file, I will now have the rights to write on it since my second app change the share into Fileshare.ReadWrite... I have now a work around but still it will be better if I can see the real code for this.

    If you the answer please let me know.

    Thanks.



  • d0r

    OK - I think I get it now. (Although I'm still not sure how a reading process can tell the difference between a write-in-progress, and a completed write. There isn't any way of forcing writes to be atomic in .NET. So aren't your readers going to be able to see partial results )

    So is it now working as you expect with that latest version of the code, or are you still seeing problems


  • Frank Miller

    AFAIK the file share mode is only checked when the file is opened, therefore the following should also work:



    try
    {
    FileStream fs = File.Open(@"C:\test.txt", FileMode.Open, FileAccess.ReadWrite, FileShare.Read);
    }
    catch
    {
    FileStream fs = File.Open(@"C:\test.txt", FileMode.Open, FileAccess.Read, FileShare.Read);
    }

    This may be preferred as it ensures that the only share mode is Read once the file has been opened for writing.


  • Learning VB

    Just an update,

    I'm still seeing problems bec when I launch the 3rd app if I'm going to check the exclusivity of the file, I will now have the rights to write on it since my second app change the share into Fileshare.ReadWrite

    -- I made a mistake on that part, my mistake was I'm not closing the filestream before checking for the exclusivity.

    In the first app who's doing the read share and readwrite access, it will stay that way eventhough there are already tons of instances you've already launched unless you close the filestream in the first app.



  • sharing of textfile (FileShare method not working)