determine if file is being used by another process

[Gabe Moothart]

Hi,
I'm writing a windows service which interacts with a separate process.
Basically, it calls a process which creates a file, and then my service
reads that file. The problem is, the external process can take a second
or two to finish writing the file. If I try to read the file to soon, I
get an exception that "The process cannot access the file because it is
being used by another process".

I could just set a timer, but the time it takes the external process to
create the file is highly variable, and I'd rather not wait longer than
I have to. What I'd like to do is run a loop that constantly checks the
status of that file (basically a "busy waiting" loop) and only allows
the File.OpenRead() when it can succeed. Right now I'm using this
monstrosity:

-------------------------------8<-------------------------
FileStream fs;
ReadFile:
try
{
fs = File.OpenRead("TestFile.txt");
}
catch(IOException)
{
goto ReadFile;
}
-------------------------------8<-------------------------

But there has to be a better way. Any suggestions?

thanks,
Gabe

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

Gabe,

Instead of doing that, I would recommend declaring the CreateFile API
function so that you can call it through the P/Invoke layer. The CreateFile
function will return an error code if you can not access the file, which is
much cleaner than handling the exception.

Once you have that, if you are able to open the file with the CreateFile
API, then you can pass the handle to the FileStream constructor, which takes
a file handle.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Gabe Moothart" <ga**@imaginesystems.net> wrote in message
news:OJ**************@TK2MSFTNGP09.phx.gbl...

Hi,
I'm writing a windows service which interacts with a separate process.
Basically, it calls a process which creates a file, and then my service
reads that file. The problem is, the external process can take a second or
two to finish writing the file. If I try to read the file to soon, I get
an exception that "The process cannot access the file because it is being
used by another process".

I could just set a timer, but the time it takes the external process to
create the file is highly variable, and I'd rather not wait longer than I
have to. What I'd like to do is run a loop that constantly checks the
status of that file (basically a "busy waiting" loop) and only allows the
File.OpenRead() when it can succeed. Right now I'm using this monstrosity:

-------------------------------8<-------------------------
FileStream fs;
ReadFile:
try
{
fs = File.OpenRead("TestFile.txt");
}
catch(IOException)
{
goto ReadFile;
}
-------------------------------8<-------------------------

But there has to be a better way. Any suggestions?

thanks,
Gabe

[Gabe Moothart]

Nicholas,
Thanks, that's just what I needed.

Gabe

Gabe,

Instead of doing that, I would recommend declaring the CreateFile API
function so that you can call it through the P/Invoke layer. The CreateFile
function will return an error code if you can not access the file, which is
much cleaner than handling the exception.

Once you have that, if you are able to open the file with the CreateFile
API, then you can pass the handle to the FileStream constructor, which takes
a file handle.

Hope this helps.

[Willy Denoyette [MVP]]

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:eB*************@TK2MSFTNGP15.phx.gbl...

Gabe,

Instead of doing that, I would recommend declaring the CreateFile API
function so that you can call it through the P/Invoke layer. The
CreateFile function will return an error code if you can not access the
file, which is much cleaner than handling the exception.

Once you have that, if you are able to open the file with the
CreateFile API, then you can pass the handle to the FileStream
constructor, which takes a file handle.

Hope this helps.

Sorry to ask, but why do you thing it's much cleaner to PInvoke instead of
handling the exception?
You have to test the return value of CreateFile, and only retry the call if
the file is in use, but you have to test for other error conditions too and
take appropriate actions (throw or ..). IMO when all is done (correctly )you
will have coded a great deal of what's been done in File.OpenRead.

Note also that v2's FileStream constructors that accept an IntPtr as handle
are deprecated, so you will have to encapsulate the handle returned in a
SafeHandle before passing to the FileStream ctor.
Willy.

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

Willy,

The OP is trying to handle business logic depending on whether or not
the file is in use. When coding business logic, flow control, IMO, should
never be predicated on exception handling, especially when there is a way to
check the status.

Of course, this is a matter of preference. If other people want to base
their logic on exception handling, they are free to do so, but I think there
is a strong camp that disagrees with this approach.

Also, the OP specifically asked for a solution that did not involve
using exceptions to determine if the file was in use.

From a performance standpoint, I think that the seven or so extra
instructions to call API through the P/Invoke layer (which are going to be
called anyways by the constructor if you didn't pass in a file handle) are a
small price to pay as opposed to throwing an exception.

You are right about the constructor being marked as obsolete and passing
a SafeHandle. I didn't mention it because I assume that most people are not
using the beta, but the OP should know that as well.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote
in message news:eB*************@TK2MSFTNGP15.phx.gbl...

Gabe,

Instead of doing that, I would recommend declaring the CreateFile API
function so that you can call it through the P/Invoke layer. The
CreateFile function will return an error code if you can not access the
file, which is much cleaner than handling the exception.

Once you have that, if you are able to open the file with the
CreateFile API, then you can pass the handle to the FileStream
constructor, which takes a file handle.

Hope this helps.

Sorry to ask, but why do you thing it's much cleaner to PInvoke instead of
handling the exception?
You have to test the return value of CreateFile, and only retry the call
if the file is in use, but you have to test for other error conditions too
and take appropriate actions (throw or ..). IMO when all is done
(correctly )you will have coded a great deal of what's been done in
File.OpenRead.

Note also that v2's FileStream constructors that accept an IntPtr as
handle are deprecated, so you will have to encapsulate the handle returned
in a SafeHandle before passing to the FileStream ctor.
Willy.

[Willy Denoyette [MVP]]

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:eQ**************@TK2MSFTNGP10.phx.gbl...

Willy,

The OP is trying to handle business logic depending on whether or not
the file is in use. When coding business logic, flow control, IMO, should
never be predicated on exception handling, especially when there is a way
to check the status.

Of course, this is a matter of preference. If other people want to
base their logic on exception handling, they are free to do so, but I
think there is a strong camp that disagrees with this approach.

Also, the OP specifically asked for a solution that did not involve
using exceptions to determine if the file was in use.

From a performance standpoint, I think that the seven or so extra
instructions to call API through the P/Invoke layer (which are going to be
called anyways by the constructor if you didn't pass in a file handle) are
a small price to pay as opposed to throwing an exception.

You are right about the constructor being marked as obsolete and
passing a SafeHandle. I didn't mention it because I assume that most
people are not using the beta, but the OP should know that as well.

Nicholas,

I'm not talking about the performance differences between both, I'm talking
about the extra lines of code that are needed to make it more robust,
especially in the case of a windows service.
And IMO it's pretty wrong to loop on CreateFile calls [without any sleep in
between (pun intended) - see later] and only terminate the loop when the
status is OK. What if the status is something like "access denied or file
does not exist or wrong open mode" you will have to exit the loop and take
an action don't you think so?
Now whiter you handle exceptions or error codes, you should never call an
API like CreateFile is a closed loop without some sleep in between the
calls.
If you average file creation time is something like 1 sec., put a sleep of
0.5 - 1 sec. in between the calls, handle the exception or the error return
and retry when still busy. That way you will only throw a very few times per
file you process. However, if you keep your closed loop your thread will
consume most if not all CPU resources and disturb the external process in
such a way that it can dramatically increase the file creation time when run
on a single CPU box.

Willy.

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

Willy,

The problem you describe will exist in both cases, and the solution
would be the same in both cases. Basically, the thread should be put to
sleep in between checks. Whether or not the OP uses exceptions to determine
the cause of the error, or the result from CreateFile, the need to put the
thread to sleep in that loop is still needed.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:er*************@TK2MSFTNGP14.phx.gbl...

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote
in message news:eQ**************@TK2MSFTNGP10.phx.gbl...

Willy,

The OP is trying to handle business logic depending on whether or not
the file is in use. When coding business logic, flow control, IMO,
should never be predicated on exception handling, especially when there
is a way to check the status.

Of course, this is a matter of preference. If other people want to
base their logic on exception handling, they are free to do so, but I
think there is a strong camp that disagrees with this approach.

Also, the OP specifically asked for a solution that did not involve
using exceptions to determine if the file was in use.

From a performance standpoint, I think that the seven or so extra
instructions to call API through the P/Invoke layer (which are going to
be called anyways by the constructor if you didn't pass in a file handle)
are a small price to pay as opposed to throwing an exception.

You are right about the constructor being marked as obsolete and
passing a SafeHandle. I didn't mention it because I assume that most
people are not using the beta, but the OP should know that as well.

Nicholas,

I'm not talking about the performance differences between both, I'm
talking about the extra lines of code that are needed to make it more
robust, especially in the case of a windows service.
And IMO it's pretty wrong to loop on CreateFile calls [without any sleep
in between (pun intended) - see later] and only terminate the loop when
the status is OK. What if the status is something like "access denied or
file does not exist or wrong open mode" you will have to exit the loop and
take an action don't you think so?
Now whiter you handle exceptions or error codes, you should never call an
API like CreateFile is a closed loop without some sleep in between the
calls.
If you average file creation time is something like 1 sec., put a sleep of
0.5 - 1 sec. in between the calls, handle the exception or the error
return and retry when still busy. That way you will only throw a very few
times per file you process. However, if you keep your closed loop your
thread will consume most if not all CPU resources and disturb the external
process in such a way that it can dramatically increase the file creation
time when run on a single CPU box.

Willy.

[Willy Denoyette [MVP]]

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:uG**************@tk2msftngp13.phx.gbl...

Willy,

The problem you describe will exist in both cases, and the solution
would be the same in both cases. Basically, the thread should be put to
sleep in between checks. Whether or not the OP uses exceptions to
determine the cause of the error, or the result from CreateFile, the need
to put the thread to sleep in that loop is still needed.
--

Nicholas,

Agreed, and that's exactly why I prefer to use the FCL and handle the
exceptions, I don't need to declare the PInvoke (maintenance issue!!) stuff
and other extra code, it's already there in the framework, the exception
overhead is IMO a non issue.

Willy.

[tkondal]

I agree with Willy. There is just too much overhead for nothing in
using the CreateFile API call. I, personally, think that exception
handling is a better way of doing it.