Check for file in use

[Brian Simmons]

Is there an easy way to check to see if a file is in use?

I want to open a CSV file from my .NET2 program, and write to it. However,
the file could be in use by another program. If that is the case, I don't
want to attempt to write to it, just abort.

Thanks,
Brian

[Nicholas Paldino [.NET/C# MVP]]

Brian,

You could use the FileStream class and try to open the file with the
sharing/read/write options you need, and then catch the IOException (I
believe) that is thrown. However, an exception of this type can be thrown
for other conditions (like a disk error) and it's not clear (aside from the
message, which you can't reliably code against) from that exception what the
IO condition is.

Instead, what you can do is call the CreateFile API function through the
P/Invoke layer. If it returns a value of INVALID_HANDLE_ VALUE, then you can
call the static GetLastWin32Err or on the Marshal class and get the value
from GetLastError. This should correspond specifically to a value in
winerror.h which indicates that the file is currently in use.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Brian Simmons" <ce******@newsg roup.nospamwrot e in message
news:%2******** ********@TK2MSF TNGP05.phx.gbl. ..

Is there an easy way to check to see if a file is in use?

I want to open a CSV file from my .NET2 program, and write to it.
However, the file could be in use by another program. If that is the
case, I don't want to attempt to write to it, just abort.

Thanks,
Brian

[Vadym Stetsiak]

Hello, Brian!

Put the code that opens the file into try/catch(IOExcepti on) block. In the
catch
handle assume that file is in use. You can also check IOExceptio:HRes ult
property as it may contain
Win32 error number that corresponds to "File is in use by another process"

Also have a look at http://www.thescripts.com/forum/thread251072.html
You wrote on Wed, 15 Aug 2007 10:59:28 -0400:

BSI want to open a CSV file from my .NET2 program, and write to it.
BSHowever, the file could be in use by another program. If that is the
BScase, I don't want to attempt to write to it, just abort.
With best regards, Vadym Stetsiak.
Blog: http://vadmyst.blogspot.com

[Nicholas Paldino [.NET/C# MVP]]

The OP can't check the HResult property because it is protected. The OP
would have to use reflection, which is a little bit too much overhead, IMO.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Vadym Stetsiak" <va*****@gmail. comwrote in message
news:u3******** ******@TK2MSFTN GP04.phx.gbl...

Hello, Brian!

Put the code that opens the file into try/catch(IOExcepti on) block. In the
catch
handle assume that file is in use. You can also check IOExceptio:HRes ult
property as it may contain
Win32 error number that corresponds to "File is in use by another process"

Also have a look at http://www.thescripts.com/forum/thread251072.html
You wrote on Wed, 15 Aug 2007 10:59:28 -0400:

BSI want to open a CSV file from my .NET2 program, and write to it.
BSHowever, the file could be in use by another program. If that is the
BScase, I don't want to attempt to write to it, just abort.
With best regards, Vadym Stetsiak.
Blog: http://vadmyst.blogspot.com

[=?Utf-8?B?WWFyb24gS2Fybmk=?=]

Nicolas, good answer, when i look on this quiz, i think lets try to delete
it, in case of exception so, the file is being used.

A JOKE.
--
Sincerely
Yaron Karni
http://dotnetbible.blogspot.com/
"Nicholas Paldino [.NET/C# MVP]" wrote:

Brian,

You could use the FileStream class and try to open the file with the
sharing/read/write options you need, and then catch the IOException (I
believe) that is thrown. However, an exception of this type can be thrown
for other conditions (like a disk error) and it's not clear (aside from the
message, which you can't reliably code against) from that exception what the
IO condition is.

Instead, what you can do is call the CreateFile API function through the
P/Invoke layer. If it returns a value of INVALID_HANDLE_ VALUE, then you can
call the static GetLastWin32Err or on the Marshal class and get the value
from GetLastError. This should correspond specifically to a value in
winerror.h which indicates that the file is currently in use.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Brian Simmons" <ce******@newsg roup.nospamwrot e in message
news:%2******** ********@TK2MSF TNGP05.phx.gbl. ..

Is there an easy way to check to see if a file is in use?

I want to open a CSV file from my .NET2 program, and write to it.
However, the file could be in use by another program. If that is the
case, I don't want to attempt to write to it, just abort.

Thanks,
Brian

[Peter Duniho]

Nicholas Paldino [.NET/C# MVP] wrote:

The OP can't check the HResult property because it is protected. The OP
would have to use reflection, which is a little bit too much overhead, IMO.

And using p/invoke to call CreateFile directly isn't?

IMHO, the real answer is to just catch the exception and report it to
the user if it occurs. Yes, other exceptions could occur. But they
will have unique Message properties that can be displayed to the user,
and any exception needs to be dealt with, not just the one involving a
file that's already in use.

Yes, it's difficult for the code to do something conditionally based on
the exact error, but IMHO it's not necessary for the code to do that.
Any error that prevents the file from being opened is a problem.

Pete

[Nicholas Paldino [.NET/C# MVP]]

"Peter Duniho" <Np*********@Nn OwSlPiAnMk.comw rote in message
news:13******** *****@corp.supe rnews.com...

Nicholas Paldino [.NET/C# MVP] wrote:

> The OP can't check the HResult property because it is protected. The
OP would have to use reflection, which is a little bit too much overhead,
IMO.

And using p/invoke to call CreateFile directly isn't?

Obviously, IMO, it's not.

IMHO, the real answer is to just catch the exception and report it to the
user if it occurs. Yes, other exceptions could occur. But they will have
unique Message properties that can be displayed to the user, and any
exception needs to be dealt with, not just the one involving a file that's
already in use.

I disagree here. The OP explicitly stated that they wanted to abort the
operation. Whether or not the OP wants it to abort silently, or not
silently was not specified.

If the OP wants the program to abort silently, then I would say just let
the exception fly and then wrap all the code in a try/catch statement, doing
nothing in the catch statement.

If the OP wants the program to not abort silently, then I whether or not
to propogate the exception would depend on how user-friendly the OP wants to
make his program. If the OP doesn't want something that is completely
user-friendly, then just let the exceptions fly.

However, if the does want something more user friendly message based on
a specific condition that can be checked for (in this case, is the file in
use), then working with IOException is not viable here, as it doesn't expose
the information in a way that can be easily ascertained.

The OP ^could^ use the suggestion to use the HResult property, but it
would require reflection, and at that point, you are basing the logic on an
implementation detail, which I think we would agree is a bad thing.

That leaves checking for the condition before trying to access the file,
which leaves the call to CreateFile.

Yes, it's difficult for the code to do something conditionally based on
the exact error, but IMHO it's not necessary for the code to do that. Any
error that prevents the file from being opened is a problem.

Well, whether or not it's a problem, that's for the OP (and the users of
his program) to decide, really. If he could clarify it more, that would
help.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

[Larry Smith]

There's always the remote possibility that the file won't be shared the
moment he checks it but will then be shared the moment he tries to open it
for (exclusive) writing. He therefore has to deal with the exception anyway.
Why waste the effort up front. I would personally consider a (reusable)
wrapper function that opens the file, catches the "IOExceptio n" and then
checks if it's really a sharing violation (which might also be gone by this
point so you can't entirely escape the problem - a "NumberOfRetrie s"
mechanism would usually solve thits however). If a sharing violation is
detected then simply throw a (custom) "SharingViolati onException" with the
original "IOExceptio n" as its inner exception.

[Nicholas Paldino [.NET/C# MVP]]

Larry,

That's the thing, how do you detect that the IOException actually occurs
as the result of the file being open? The two options are to use reflection
to get the HResult property which is protected and then check the error
code, or to parse the Message text, which is fragile at best (because of the
possibility of the Message property changing due to updates in the framework
and because of localization issues as well, as the Message property is more
than likely going to be localized). Neither is particularly stable, as they
both depend on implementation details.

Looking at the Marshal class, I realize that you could call the static
GetHRForExcepti on method to get the HRESULT code of the exception. This
HRESULT is the result of calling the HRESULT_FROM_WI N32 macro on the error
code ERROR_SHARING_V IOLATION (which has a value of 32):

http://msdn2.microsoft.com/en-us/library/ms680746.aspx

Looking in the code by calling the GetHRForExcepti on method, you can see
that the value 32 is definitely there (you have to convert to an unsigned
integer). Unfortunately, there is no definite way to map an HRESULT back to
a Win32 error code, as described here:

http://blogs.msdn.com/oldnewthing/ar...03/942851.aspx

I would say checking the IOException instance in this way is slightly
better, as you are still depending on an implementation detail (in the
conversion from the HRESULT to the Win32 error code). Granted, it's highly
unlikely that you are going to get an IOException which has an error code in
the HRESULT which is from a different facility or of a different severity,
so in the end, it's up to you what your poison is.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Larry Smith" <no_spam@_nospa m.comwrote in message
news:%2******** **********@TK2M SFTNGP06.phx.gb l...

There's always the remote possibility that the file won't be shared the
moment he checks it but will then be shared the moment he tries to open it
for (exclusive) writing. He therefore has to deal with the exception
anyway. Why waste the effort up front. I would personally consider a
(reusable) wrapper function that opens the file, catches the "IOExceptio n"
and then checks if it's really a sharing violation (which might also be
gone by this point so you can't entirely escape the problem - a
"NumberOfRetrie s" mechanism would usually solve thits however). If a
sharing violation is detected then simply throw a (custom)
"SharingViolati onException" with the original "IOExceptio n" as its inner
exception.

[Larry Smith]

That's the thing, how do you detect that the IOException actually

occurs as the result of the file being open? The two options are to use
reflection to get the HResult property which is protected and then check
the error code, or to parse the Message text, which is fragile at best
(because of the possibility of the Message property changing due to
updates in the framework and because of localization issues as well, as
the Message property is more than likely going to be localized). Neither
is particularly stable, as they both depend on implementation details.

Looking at the Marshal class, I realize that you could call the static
GetHRForExcepti on method to get the HRESULT code of the exception. This
HRESULT is the result of calling the HRESULT_FROM_WI N32 macro on the error
code ERROR_SHARING_V IOLATION (which has a value of 32):

http://msdn2.microsoft.com/en-us/library/ms680746.aspx

Looking in the code by calling the GetHRForExcepti on method, you can
see that the value 32 is definitely there (you have to convert to an
unsigned integer). Unfortunately, there is no definite way to map an
HRESULT back to a Win32 error code, as described here:

http://blogs.msdn.com/oldnewthing/ar...03/942851.aspx

I would say checking the IOException instance in this way is slightly
better, as you are still depending on an implementation detail (in the
conversion from the HRESULT to the Win32 error code). Granted, it's
highly unlikely that you are going to get an IOException which has an
error code in the HRESULT which is from a different facility or of a
different severity, so in the end, it's up to you what your poison is.

In practice the situation doesn't normally require this level of precision.
If an "IOExceptio n" occurs and the equivalent Win32 function then indicates
a sharing violation only milliseconds later, you're pretty much guaranteed
that's what the problem is. The odds of the "IOExceptio n" being something
else are incredibly remote. Let's say it is however. Well there's still a
sharing violation at the Win32 level so reporting that is still accurate.
It's really (almost) as if you relied on Win32 directly in the first place
(for all intents and purposes). Since the course of action at this point for
most programs is to inform the user and/or log the error, you can simply
report something like:

Unable to open file "YourFile" due to a sharing violation. See application
event log for further details.

You can then clarify the situation in the log by dumping the original
"IOExceptio n" in addition to the sharing violation itself. While not a
perfect course of action theoretically, in reality it will work just fine.
In any case, I do agree with your HRESULT assessment. Not only is it an
implementation detail that you shouldn't rely on (since there's no guarantee
that ERROR_SHARING_V IOLATION will be propagated back), it seems implausible
to me that MSFT would ever recommend using "GetHRForExcept ion()" for this
purpose (mapping a standard .NET exception to a corresponding Win32 error -
in theory .NET has nothing to do with Win32).