Using FileStream on the network when the network goes down

I am writing some code as part of a framework to open a file. The file is of a custom type and should not be opened by more than one instance of my application. To stop multiple file openings, I use a filter to create a lock file and then save the specified open stream.

This is like preventing another instance of my application from opening (since it won't be able to recreate the lock thread on the open file), but if the file is on a network share and the network crashes, then the original application cannot access the file either.

The code to get the blocking thread looks like this:

Try
        ' We need to keep this stream alive to prevent other applications gaining access to the lock
        mLockStream = New FileStream(mLockPath, FileMode.CreateNew, FileAccess.Write, FileShare.None)
    Catch ex As UnauthorizedAccessException
    Catch ex As DirectoryNotFoundException
        Throw
    Catch ex As IOException
        Throw New ProjectInUseException(My.Resources.LocalizedResources.ProjectInUseExceptionMessage, Nothing)
    End Try

      

In this, I create a blocking thread for the first time, and then if another application tries to create it, it will throw an exception and prevent them from getting further. This kind of needs to work, unfortunately, as I said, if this is done over the network, and for some reason the network connection drops, then I cannot delete the blocking thread because I get an IOException saying that the process cannot access to the file as it is open in another process (which shouldn't happen, I don't think).

Hope this makes sense, I looked around but didn't find anything about this particular scenario, so I thought I'd see if anyone here has a similar experience.

greetings.

+3


source to share


2 answers


So I wasted a lot of time that the problem was some kind of deep, dark scary .Net, when in fact the fix was a little easier than I thought. I changed the source stream creation to use FileShare.Read. Upon closer inspection of the FileShare enumeration, I found that FileShare.None denied public access to the process that created it (

Reduces the sharing of the current file. Any request to open a file (by this process or by another process) will fail until the file is closed.



So, by changing this to FileShare.Read, I could re-lock the lock when the network connection was established and then dispose of it before deleting the actual file.

Hopefully this is not too much gibberish and useful for someone else. As with most of my programming problems, this was the case where the problem was simpler than I expected and threw me out of the way :)

0


source


The answer to this question by Dracanus :


So I wasted a lot of time that the problem was some kind of deep, dark scary .Net, when in fact the fix was a little easier than I thought. I changed the source stream creation to use FileShare.Read. Upon closer inspection of the FileShare enumeration, I found that FileShare.None denied public access to the process that created it (



Reduces the sharing of the current file. Any request to open a file (by this process or by another process) will fail until the file is closed.

So, by changing this to FileShare.Read, I could re-lock the lock when the network connection was established and then dispose of it before deleting the actual file.

Hopefully this is not too much gibberish and useful for someone else. As with most of my programming problems, this was the case where the problem was simpler than I expected and threw me out of the way :)

+2


source







All Articles