Return to Question

replaced http://codereview.stackexchange.com/ with https://codereview.stackexchange.com/

edited Apr 13, 2017 at 12:40

I know I've already asked a similar question I've already asked a similar question, but this feels quite different to me.

The main goal is to wait for a file to be accessible (read: waiting until the file lock releases), since it seems like there's no way to do this built into the .NET framework I've written a quick and dirty function to do this.

The requirements which should be kept in mind with this:

The file shouldn't be locked often. Actually, it should be locked quite rarely (figure how often clients manage to still hit that).
There's no need for a limit, if the file is locked for longer then a second, something is fuc^H^H^Hscrewed up.
It should block the main thread until the file is available.

///<summary>
/// Tries to open the specified file over and over again until it is acessible.
///</summary>
public static FileStream WaitForStream(String filename, FileAccess fileAccess, FileShare, fileShare)
{
 while(true) // Gives me the chills
 {
 try
 {
 return new FileStream(filename, FileMode.OpenOrCreate, fileAccess, fileShare);
 }
 catch (IOException ex)
 {
 Logger.LogError(ex); // Information purposes only
 Threading.Thread.Sleep(250); // Just looks wrong
 }
 }
 return null; // Only to keep the compiler happy.
}

The problems I see myself:

while(true)
Thread.Sleep()
It might loop forever, but as I said, if that happens we need to intervene anyway.

Reimplementing this with a similar solution I already used a similar solution I already used smells like absolute overkill to me, given that this should be built-in functionality anyway. What stuff didn't I think about?

I know I've already asked a similar question, but this feels quite different to me.

The requirements which should be kept in mind with this:

The file shouldn't be locked often. Actually, it should be locked quite rarely (figure how often clients manage to still hit that).
There's no need for a limit, if the file is locked for longer then a second, something is fuc^H^H^Hscrewed up.
It should block the main thread until the file is available.

///<summary>
/// Tries to open the specified file over and over again until it is acessible.
///</summary>
public static FileStream WaitForStream(String filename, FileAccess fileAccess, FileShare, fileShare)
{
 while(true) // Gives me the chills
 {
 try
 {
 return new FileStream(filename, FileMode.OpenOrCreate, fileAccess, fileShare);
 }
 catch (IOException ex)
 {
 Logger.LogError(ex); // Information purposes only
 Threading.Thread.Sleep(250); // Just looks wrong
 }
 }
 return null; // Only to keep the compiler happy.
}

The problems I see myself:

while(true)
Thread.Sleep()
It might loop forever, but as I said, if that happens we need to intervene anyway.

Reimplementing this with a similar solution I already used smells like absolute overkill to me, given that this should be built-in functionality anyway. What stuff didn't I think about?

I know I've already asked a similar question, but this feels quite different to me.

The requirements which should be kept in mind with this:

The file shouldn't be locked often. Actually, it should be locked quite rarely (figure how often clients manage to still hit that).
There's no need for a limit, if the file is locked for longer then a second, something is fuc^H^H^Hscrewed up.
It should block the main thread until the file is available.

///<summary>
/// Tries to open the specified file over and over again until it is acessible.
///</summary>
public static FileStream WaitForStream(String filename, FileAccess fileAccess, FileShare, fileShare)
{
 while(true) // Gives me the chills
 {
 try
 {
 return new FileStream(filename, FileMode.OpenOrCreate, fileAccess, fileShare);
 }
 catch (IOException ex)
 {
 Logger.LogError(ex); // Information purposes only
 Threading.Thread.Sleep(250); // Just looks wrong
 }
 }
 return null; // Only to keep the compiler happy.
}

The problems I see myself:

while(true)
Thread.Sleep()
It might loop forever, but as I said, if that happens we need to intervene anyway.

Reimplementing this with a similar solution I already used smells like absolute overkill to me, given that this should be built-in functionality anyway. What stuff didn't I think about?

Tweeted twitter.com/#!/StackCodeReview/status/152168477828976640

occurred Dec 28, 2011 at 23:26

Source Link

asked Dec 28, 2011 at 10:10

Bobby

asked Dec 28, 2011 at 10:10

Bobby

8.2k
2
35
43

Waiting for a file to be accessible with Thread.Sleep() and exception catching

I know I've already asked a similar question, but this feels quite different to me.

The requirements which should be kept in mind with this:

The file shouldn't be locked often. Actually, it should be locked quite rarely (figure how often clients manage to still hit that).
There's no need for a limit, if the file is locked for longer then a second, something is fuc^H^H^Hscrewed up.
It should block the main thread until the file is available.

///<summary>
/// Tries to open the specified file over and over again until it is acessible.
///</summary>
public static FileStream WaitForStream(String filename, FileAccess fileAccess, FileShare, fileShare)
{
 while(true) // Gives me the chills
 {
 try
 {
 return new FileStream(filename, FileMode.OpenOrCreate, fileAccess, fileShare);
 }
 catch (IOException ex)
 {
 Logger.LogError(ex); // Information purposes only
 Threading.Thread.Sleep(250); // Just looks wrong
 }
 }
 return null; // Only to keep the compiler happy.
}

The problems I see myself:

while(true)
Thread.Sleep()
It might loop forever, but as I said, if that happens we need to intervene anyway.

Reimplementing this with a similar solution I already used smells like absolute overkill to me, given that this should be built-in functionality anyway. What stuff didn't I think about?

lang-cs