FileSystemWatcher + Multiple Events

[Michael Stanbrook]

I'm using the FileSystemWatch er to looks for new files
arriving in a directory. Files are coming in via FTP and
tend to be larger is size (> 1MB at least).

I would like to fire an event once the file is completely
written. I understand there is nothing "exactly" like
that due to how the OS filesystem works, so I am looking
for a workaround.

I am currently attempting to open the "new" file in
exclusing mode to "test" if the file is complete from
within the OnCreate and OnChange event handlers. If the
exclusive open is not successful, I sleep the thread, and
try again. Works like a charm, except I get multiple
Change events thrown, which causes my "test" to be
executed multiple times for each file.

Does anyone have a workaround for this? Perhaps a way to
block/ignore the change events after the first for a
given file?

TIA.

[David Sworder]

Re: FileSystemWatch er + Multiple Events

I'm in the same situation. That FileSystemWatch er is a real pain, isn't it?

The approach I take is similar to yours. I wait for the FileSystemWatch er to
fire an event when the FTP upload begins. I then turn OFF the
FileSystemWatch er and start firing a timer every 10 seconds to see when the
file is completely uploaded. I use the same technique that you do -- try to
open it in exclusive mode. Once the file is completely uploaded, I move the
file to a processing directory, kill the timer, and finally reactivate the
FileSystemWatch er.

David

"Michael Stanbrook" <mstanbrook@yah oo.com> wrote in message
news:00d801c388 91$1fcd9cb0$a00 1280a@phx.gbl.. .[color=blue]
> I'm using the FileSystemWatch er to looks for new files
> arriving in a directory. Files are coming in via FTP and
> tend to be larger is size (> 1MB at least).
>
> I would like to fire an event once the file is completely
> written. I understand there is nothing "exactly" like
> that due to how the OS filesystem works, so I am looking
> for a workaround.
>
> I am currently attempting to open the "new" file in
> exclusing mode to "test" if the file is complete from
> within the OnCreate and OnChange event handlers. If the
> exclusive open is not successful, I sleep the thread, and
> try again. Works like a charm, except I get multiple
> Change events thrown, which causes my "test" to be
> executed multiple times for each file.
>
> Does anyone have a workaround for this? Perhaps a way to
> block/ignore the change events after the first for a
> given file?
>
> TIA.
>
>[/color]

[Mike Stanbrook]

Re: FileSystemWatch er + Multiple Events

David,

Whew, I thought I was the only one!

Are you actually using a timer? One of the other posts I
found on this topic suggested using a Thread.Sleep(xx x)
instead, and I'm wondering if there is much diference
betwen the two...

Thanks for your input..happy to hear I'm at least on the
right track.

Mike

[color=blue]
>-----Original Message-----
>I'm in the same situation. That FileSystemWatch er is a[/color]
real pain, isn't it?[color=blue]
>
>The approach I take is similar to yours. I wait for the[/color]
FileSystemWatch er to[color=blue]
>fire an event when the FTP upload begins. I then turn OFF[/color]
the[color=blue]
>FileSystemWatc her and start firing a timer every 10[/color]
seconds to see when the[color=blue]
>file is completely uploaded. I use the same technique[/color]
that you do -- try to[color=blue]
>open it in exclusive mode. Once the file is completely[/color]
uploaded, I move the[color=blue]
>file to a processing directory, kill the timer, and[/color]
finally reactivate the[color=blue]
>FileSystemWatc her.
>
>David
>
>"Michael Stanbrook" <mstanbrook@yah oo.com> wrote in[/color]
message[color=blue]
>news:00d801c38 891$1fcd9cb0$a0 01280a@phx.gbl. ..[color=green]
>> I'm using the FileSystemWatch er to looks for new files
>> arriving in a directory. Files are coming in via FTP and
>> tend to be larger is size (> 1MB at least).
>>
>> I would like to fire an event once the file is[/color][/color]
completely[color=blue][color=green]
>> written. I understand there is nothing "exactly" like
>> that due to how the OS filesystem works, so I am looking
>> for a workaround.
>>
>> I am currently attempting to open the "new" file in
>> exclusing mode to "test" if the file is complete from
>> within the OnCreate and OnChange event handlers. If the
>> exclusive open is not successful, I sleep the thread,[/color][/color]
and[color=blue][color=green]
>> try again. Works like a charm, except I get multiple
>> Change events thrown, which causes my "test" to be
>> executed multiple times for each file.
>>
>> Does anyone have a workaround for this? Perhaps a way to
>> block/ignore the change events after the first for a
>> given file?
>>
>> TIA.
>>
>>[/color]
>
>
>.
>[/color]

[David Sworder]

Re: FileSystemWatch er + Multiple Events

> Whew, I thought I was the only one![color=blue]
>
> Are you actually using a timer? One of the other posts I
> found on this topic suggested using a Thread.Sleep(xx x)
> instead, and I'm wondering if there is much diference
> betwen the two...[/color]

The vast majority of the time, Thread.Sleep() will work just as well as
a timer and Sleep() is easier to use and makes your code a bit easier to
follow too. The thing is, Sleep() blocks the calling thread. That's what
it's designed to do. In 99% of the cases this is no problem, but in a really
busy server process that is servicing tens of thousands of requests, it's
desirable to minimize the number of blocked threads. You see, the
FileWatcher ultimately fires its event from a "thread pool" thread. These
threads are a very valuable resource. There are only 25 of them per CPU. In
a situation where you have thousands of requests coming into your service
process, you don't want to waste one of your thread pool threads by blocking
(sleeping). Instead, it's better to set the timer and let that "thread pool"
thread return back to the pool so that it can service another request while
you're waiting for the timer to fire.

Unless your designing a high-load server app though, it usually makes
more sense to use Sleep() as you are doing.

David