I have a VB.NET application that watches a directory for files to consume. Another, off the shelf, application drops files into this directory to be consumed by my application. Sometimes the provider app does not let go of the file before my app trys to use it and I get a "can't access myfile.txt because it is being used by another process" error. I am currently handling this with an api call to sleep(time in ms) but would prefer a more robust solution.

Is there a way to test a file to see if it is locked by another process? I have searched high and low and haven't found anything. I beleive there must be a way to test for such a common and simple thing but I have obviously missed it.

Thanks,
Rick

hi there...

if you are receiving that error.. why not just trap it???? you are trying to open it, so you can know if it is being use...

HTH

Gonzalo

Thanks for the quick reply gbianchi.

Yes, that's what it looks like i'll have to do but I hate it. :(
I would rather test for the condition but it looks like there is no way.

I tend to be a little obssesive over stuff like this. My problem, right? :D

Thanks again for your time,
Rick

I agree that the most elegant way to handle your situation is to trap the "error" condition. Error trapping is in fact testing for a condition a Try...Catch (with appropriate Case statements) is a very acceptable way to test and handle exception conditions that are outside the bounds of "mainline processes". They are not always errors but exceptions to mainline processing. This is why they are now correctly label as Exceptions not Errors. Elegant and well-developed exception handling logic is just as logically valid as the mainline logic of an application. (Just wanted to insert my two cents.)

Thanks for the reply redbudval.

Exactly! I was looking or a more elegant/graceful manner in which to handle this.

Your point is well taken:
"Elegant and well-developed exception handling logic is just as logically valid as the mainline logic of an application."

Thanks,
Rick

redbudval-

While I agree with most of what you say, consider this:

Exception catching is an expensive process. IMO, exception catching should be left for truly exceptional conditions. In Rick's case, he's fully expecting a file to have a lock on it so he could test for this expected condition within a standard branching structure.

To make things more readable—if a little more spaghetti-like—you could 'test' the file in a function, hiding the multiple lines of code that are involved in that way.
    Then write a function that tries to access the file, returning True if that succeeds, False if not.