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 hasn't been opened in-between you checking and then opening it.

[MTSkull]

In this case I can be more then reasonably assured that it won't 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 isn't 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 it's 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 :rolleyes:

 

[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.