Check If a file is open...

[MTSkull]

Can you check if a file is open and/or locked without the try/catch/finally statement?
I saw this asked in another thread but the topic turned to exception handling and the original question never seemed to be answered.

Thanks
MTS

 

[PlausiblyDamp]

Not reliably - even if you check before attempting to open the file there is no guarantee that the file hasnt been opened in-between you checking and then opening it.

 

[MTSkull]

In this case I can be more then reasonably assured that it wont be opened after I check it.

We have a server process which I flag when I am done writing. It then extracts info it needs for database processing. Occasionally it hangs and holds files open, or is lazy in how it closes and releases the files. I need a way to test to see that I am not colliding with this process. It is a relatively rare occurrence but I would like to handle it better then Try/Catch/Finally which is slow and I plan on hitting it several times before throwing an error. If this is even possible.

I tried exploring FileAccess, FileAtributes and AccessControl.FileSecurity, but did not see anything in there that looked promising.

Thanks
MT

 

[PlausiblyDamp]

Try ... Catch isnt really that slow if you measure it - it does get an awful lot of bad press...

as a fairly non-scientific test I just tried running

Dim t As Date = Date.Now

For i As Integer = 0 To 1000
    Try
        Dim fs As New IO.FileStream("c:\pagefile.sys", IO.FileMode.Open, IO.FileAccess.Write, IO.FileShare.Delete)
    Catch ex As Exception

    End Try
Next

Dim ts As TimeSpan = Date.Now.Subtract(t)

MessageBox.Show(ts.TotalMilliseconds.ToString("#,##0.00"))

as it will deliberately cause an awful lot (i.e. 1001) of IOExceptions to be thrown and caught and in a Debug build it still came to just under 6 seconds (5,944 milliseconds) on its first run and only 4.7 seconds on a second run once JIT compilation was removed from the equation. Under a release build the first run was only 244 milliseconds and remarkably similar on subsequent runs - not much of a performance hit in any real terms.

 

[MTSkull]

I modifed your code slightly

[CS]

StreamWriter Results = new StreamWriter("C:\\TimeResults.txt");

this.Text = "Starting...";

DateTime Start = DateTime.Now;
DateTime TryStart = DateTime.Now;
TimeSpan Difference;
for (int x = 0; x < 1000; x++)
{
try
{
TryStart = DateTime.Now;
Application.DoEvents();
StreamReader Test = new StreamReader("r:\\birthcrt\\999\\9995\\9995000M.txt");
Test.Close();
Test.Dispose();
}
catch
{
Difference = DateTime.Now.Subtract(TryStart);
Results.WriteLine(x.ToString().PadRight(6, (char)32) + Difference.TotalMilliseconds.ToString());
}

}

Difference = DateTime.Now.Subtract(Start);
Results.WriteLine("DONE " + Difference.TotalMilliseconds.ToString());

Results.Close();
Results.Dispose();

this.Text = "Finished...";
[/CS]
The mods allow me to see the time it took for each individual try when trying to open a file on the network drive.

I wanted to simulate stuff actually going on with the system while it was tring to run. So while it was running the simulation I was opening and closing stuff on the desktop.

Quickest was 0mSecs and slowest was ~47mSecs with an average of 6.4mSecs for the 1000 samples. Total time was ~6 seconds. So not slow enough that it would not be noticed. Especially since I will be introducing a wait time between each pass.

Thanks
Brian

 

[snarfblam]

Just for the record, the only time that try/catch/finally will ever really slow things down is when errors are thrown, and even then you have to throw massive quantities of exceptions before it becomes a concern.