"Stephen" <stephen***@hotmail.com> wrote in message
news:%23hp1iITHGHA.1388@TK2MSFTNGP11.phx.gbl...
> Hi,
>
> I have to create a custom app used (FileSystemWatcher) for monitoring
> Server1 say \\Stephen-1\Test and if any change happens to this directory,
> I
> take that info and update Server1 say \\Stephen-2\test it works fine. now
> I
> want to make it vice versa too... so I created another app that does the
> opposite
>
> Problem: I think there is a lock/access issue and I have no idea how to
> solve it.
>
> Please advice,
> Stephen
>
>

"Jim Wooley" <jwool***@bellsouth.net> wrote in message
news:ZPYzf.1047$5O2.823@bignews4.bellsouth.net...
> ----- Original Message -----
> From: "Stephen" <stephen***@hotmail.com>
> > I have to create a custom app used (FileSystemWatcher) for monitoring
> > Server1 say \\Stephen-1\Test and if any change happens to this
directory,
> > I
> > take that info and update Server1 say \\Stephen-2\test it works fine.
now
> > I
> > want to make it vice versa too... so I created another app that does the
> > opposite
> >
> > Problem: I think there is a lock/access issue and I have no idea how to
> > solve it.
>
> This may indeed be a lock issue. When your first FSW notices a change in
> \\Stephen-1\Test, it fires a change action on \\Stephen-2\test. Your
second
> FSW notices the change in \\Stephen-2\Test and tries to fire the change
back
> to \\Stephen-1\Test. At this point, the first FSW may still be processing
> the file and the second event fired from the FSW may not be able to handle
> it, finding that the file is already in use.
>
> Even if you don't run into a lock issue, you will likely find yourself in
an
> infinate loop (potentially resulting in a massive overflow error). From
what
> you have described above, it is hard to identify a solution at this point.
> You need to come up with a way to flag a file as in process and ignore it
> when the second FSW tries to listen.
>
> Jim Wooley
>
>