Dave Kreskowiak wrote: That's because the other process has opened the file for write acces with DenyShareAll attributes. :) The other process is samba (I'm dropping the file onto the Windows machine from my Linux machine...yes, I'm one of those annoying Linux people :)

Dave Kreskowiak wrote: StreamReader? I must be missing something here. The file is being written to disk by another process, your code tries to read the file when the FileSystemWatcher event fires (which will happen when the file is CREATED, not when it's completely written!) Your code attempts to read a file that is still being written and hasn't been flushed to disk and closed, correct? Ah...this is a plausible explanation! The first time that the handler gets called I notice that the system appears to load a dll (microsoft.visualbasic.dll). Subsequent iterations of the handler do not result in this dll being loaded. It may well be that the process of loading the dll is sufficient to delay things enough for the file write to complete, and therefore cause the StreamReader constructor to work. From then on the dll is not loaded (it's already there), so the StreamReader constructor is called sooner, and as Dave points out the file may not be completely written yet, therefore causing the symptoms that I'm seeing. Interestingly, trying to use read only handle doesn't solve this problem. Hmm...makes me wonder how to properly use the FileWatcher at all. Anyway, thanks Dave for pointing out the obvious. I'll now scratch my growing stubble and see if I can figure out a way to make this sucker work!

Programmer2k4 wrote: I don't think there is any way to read/write to the file if it is returning a "File is already in use" error in previous tries. This is the crux of the whole issue. The file should not be in use! The StreamReader.Close() method has been called, the method has been exited. There should be no resources associated with the file (at least not with any reasonable operating system!). However clearly the O/S is maintaining some sort of handle to the file and something has to be kicked repeatedly in the butt to get the resources freed. Unfortunately I can't for the life of me figure out what is holding onto the file, how to free it up, and why it eventually fixes itself. Very frustrating.

Programmer2k4 wrote: I have recently had a similar problem with a message box being required to give the process a bit of a "break". Yes, but such tricks are symptomatic of not understanding what's going on under the covers. Adding sleeps/waits is dangerous since you need to determine what is the maximum time that you need in order to ensure success. You can't do that without understanding what's going on...and if you understand what's going on you shouldn't need the sleep in the first place! I actually re-wrote the code to just keep trying to do the "new" and to count how many times it takes before it's successful. I then fired off a process on a machine running a real O/S (not this windows piece of ...oh nevermind), to just keep creating the file. The result is that the "new" always succeeds on the first iteration when the program is initially fired up. After that it may take anywhere from 4 to 25 iterations before being successful (usually around 6 or 7). Clearly there's some sort of asynchronous issue going on here, but I can't figure out what the heck it is!