Events, Threads and FileWatcher

Can we see the code?

The created event does not mean the file is finished with the copy, only
that its directory entry was created. I suspect the file is still opened
from the file copy process and your callback is trying to open the file that
is still locked on Write. As there is not a Closed event, one solution is
to use a temp dir for the copy and then Ren after the copy/download is
complete. Then just listen for the Rename event and do your thing.

--
William Stacey [MVP]

"Raj Wall" <me********@nospam.nospam> wrote in message
news:Ol**************@TK2MSFTNGP02.phx.gbl...
|I have threads with event handlers to watch for new files placed in
| directories. The handler has a Using { ... } block to process the file
which
| is then deleted. In testing I can drag/drop FileA into one of the watched
| directories and everything works fine. But when I drop FileB into one of
the
| other directories (or the same one, it doesn't matter), I get a "File in
| Use" error. This seems odd since the second test is with a different file
| and different directory.
|
| Is there something else I need to do in the event handler to release file
| resources other than Using{}? Or is there something else causing this
| problem?
|
| Thanks for your help!
|
| Regards,
| Raj
|
|

William, hi,

Thanks for the idea. However, the first file tested is processed completely,
and then deleted properly.

But after checking manually (with a file explorer window) and reviewing the
output to make sure the first one finished, the second file dropped in a
different directory gets the "in use" error.

That is, my "Created" event comes from a manual drag and drop of a test file
into the target directory.

My code is below.

Thanks for your help!

Regards,
Raj
---
code excerpt:
---
private void OnCreated(object source, FileSystemEventArgs e) // event
handler for new file

{

string fileName = e.FullPath;

using (StreamReader sr = new StreamReader(e.FullPath))

{

CsvReader myCSVReader = new CsvReader(sr, false);

while (myCSVReader.ReadNextRecord())

{. . .}

}

if(File.Exists(fileName))

{

File.Delete(fileName);

}

}

}

-----

"William Stacey [MVP]" <wi************@gmail.com> wrote in message
news:eM**************@TK2MSFTNGP02.phx.gbl...

The created event does not mean the file is finished with the copy, only
that its directory entry was created. I suspect the file is still opened
from the file copy process and your callback is trying to open the file
that
is still locked on Write. As there is not a Closed event, one solution is
to use a temp dir for the copy and then Ren after the copy/download is
complete. Then just listen for the Rename event and do your thing.

--
William Stacey [MVP]

"Raj Wall" <me********@nospam.nospam> wrote in message
news:Ol**************@TK2MSFTNGP02.phx.gbl...
|I have threads with event handlers to watch for new files placed in
| directories. The handler has a Using { ... } block to process the file
which
| is then deleted. In testing I can drag/drop FileA into one of the
watched
| directories and everything works fine. But when I drop FileB into one of
the
| other directories (or the same one, it doesn't matter), I get a "File in
| Use" error. This seems odd since the second test is with a different
file
| and different directory.
|
| Is there something else I need to do in the event handler to release
file
| resources other than Using{}? Or is there something else causing this
| problem?
|
| Thanks for your help!
|
| Regards,
| Raj
|
|

Hi Raj,

Thanks for posting!

I tested your code in my side, and I found the error will not occur every
time, it appears randomly. If it is not the same with you, please just feel
free to tell me.

I think this is just because the copy process (or another file system
process) are not synchronized, when the "created event" occurs, the copying
is still running, so if you try to open the file, the "File in use"
exception will generate. In this circumstance, to workaround it, we can
catch this IOException and re-execute the StreamReader statement. In the
sample code snippet below, I used an opened flag to track if the exception
is generated from StreamReader constructor:

private static void OnChanged(object source, FileSystemEventArgs e)
{
string fileName = e.FullPath;
bool opened=false;//add it
while (!opened){
try
{
using (StreamReader sr = new StreamReader(e.FullPath))
{
opened=true; //add it
string temp=sr.ReadToEnd();
Console.WriteLine(temp);
}
}
catch(IOException ex)
{
System.Threading.Thread.Sleep(100);
}
}
if(File.Exists(fileName))
{
File.Delete(fileName);
}
}
This workaround is far from perfect, however, I hope it will help to
workaround your problem. Hope it helps!

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Jeffrey, hi,

Thanks for the quick reply! I will implement your suggestion. Also, I saw in
another newsthread that the events generated by FileSystemWatcher are not
guaranteed to coincide with actual file closure and release by the file
system. The post suggested what you propose, but added a Sleep(1000) after
entering the handler to give file system a chance to "wrap up". Then try
again (with sleep) if IO error occurs. I'll try both. Thanks!

Regards,
Raj
""Jeffrey Tan[MSFT]"" <je***@online.microsoft.com> wrote in message
news:9M*************@TK2MSFTNGXA01.phx.gbl...

Hi Raj,

Thanks for posting!

I tested your code in my side, and I found the error will not occur every
time, it appears randomly. If it is not the same with you, please just
feel
free to tell me.

I think this is just because the copy process (or another file system
process) are not synchronized, when the "created event" occurs, the
copying
is still running, so if you try to open the file, the "File in use"
exception will generate. In this circumstance, to workaround it, we can
catch this IOException and re-execute the StreamReader statement. In the
sample code snippet below, I used an opened flag to track if the exception
is generated from StreamReader constructor:

private static void OnChanged(object source, FileSystemEventArgs e)
{
string fileName = e.FullPath;
bool opened=false;//add it
while (!opened){
try
{
using (StreamReader sr = new StreamReader(e.FullPath))
{
opened=true; //add it
string temp=sr.ReadToEnd();
Console.WriteLine(temp);
}
}
catch(IOException ex)
{
System.Threading.Thread.Sleep(100);
}
}
if(File.Exists(fileName))
{
File.Delete(fileName);
}
}
This workaround is far from perfect, however, I hope it will help to
workaround your problem. Hope it helps!

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.

| Also, I saw in
| another newsthread that the events generated by FileSystemWatcher are not
| guaranteed to coincide with actual file closure and release by the file
| system.

hmm. Is that not what I said?

| The post suggested what you propose, but added a Sleep(1000) after
| entering the handler to give file system a chance to "wrap up".

Depends on the file size. A large file could take longer. But I guess if
you try in a loop upto some max tries, then that would work. If you did the
rename, however, you would not have to guess and could open the file in the
Rename event and be sure to open it, unless another process happens to beat
you to it.

Ok, if you need further help, please feel free to feedback. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.