FilesySystemWatcher EnableRaisingEvents Reverts To False

[Jeff Grundy]

I have a FilesySystemWatcher that is watching a folder on a network share.
After varying periods (sometimes more that a week, sometimes less that a day)
of time the EnableRaisingEvents property becomes False. How can I tell why
this is happening?
--
Jeff

[Dathon]

Is it possible that the share is becoming unmounted? That may cause the
problem since the FileSystemWatcher can't watch folders that don't exist.

"Jeff Grundy" wrote:

I have a FilesySystemWatcher that is watching a folder on a network share.
After varying periods (sometimes more that a week, sometimes less that a day)
of time the EnableRaisingEvents property becomes False. How can I tell why
this is happening?
--
Jeff

[Jeff Grundy]

I am thinking it is a transient network problem. I use dbgclr.exe to attach
to the process and flip EnableRaisingEvents back to true. Then the app works
as planned. I have considered using a timer to look at the
EnableRaisingEvents periodicaly and set it to true if it is false but that
won't really tell me WHY this is happening.

"Dathon" wrote:

Is it possible that the share is becoming unmounted? That may cause the
problem since the FileSystemWatcher can't watch folders that don't exist.

"Jeff Grundy" wrote:

I have a FilesySystemWatcher that is watching a folder on a network share.
After varying periods (sometimes more that a week, sometimes less that a day)
of time the EnableRaisingEvents property becomes False. How can I tell why
this is happening?
--
Jeff

[Kevin Yu [MSFT]]

Hi Jeff,

First of all, I would like to confirm my understanding of your issue. From
your description, I understand that your
FileSystemWatcher.EnableRaisingEvents property becomes false after the app
runs for some time. If there is any misunderstanding, please feel free to
let me know.

I have tried many methods on my machine to reproduce this. The
FileSystemWatcher.EnableRaisingEvents remains to be true however the folder
is changed.

When I disable sharing of the folder and share it again, the
FileSystemWatcher stops responding. However, when I took a look at the
FileSystemWatcher.EnableRaisingEvents property, it remains to be true.

Could you try to check in the code to see if the FileSystemWatcher object
would be re-constructed somewhere?

HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[Jeff Grundy]

There is a timer that checks for changes in a database. If there is a change
to the database then the FileSystemWatcher would be recreated without being
first dropped. This is the same method (LoadWatcher) that initally
instanciates the watcher.

If myWatcher has previously been instanciated, should I set myWatcher to
nothing before I call LoadWatcher ?

Private Sub LoadWatcher()
myWatcher = New FileSystemWatcher
myWatcher.Path = mstrCurrentPath
myWatcher.EnableRaisingEvents = True
End Sub

"Kevin Yu [MSFT]" wrote:

Hi Jeff,

First of all, I would like to confirm my understanding of your issue. From
your description, I understand that your
FileSystemWatcher.EnableRaisingEvents property becomes false after the app
runs for some time. If there is any misunderstanding, please feel free to
let me know.

I have tried many methods on my machine to reproduce this. The
FileSystemWatcher.EnableRaisingEvents remains to be true however the folder
is changed.

When I disable sharing of the folder and share it again, the
FileSystemWatcher stops responding. However, when I took a look at the
FileSystemWatcher.EnableRaisingEvents property, it remains to be true.

Could you try to check in the code to see if the FileSystemWatcher object
would be re-constructed somewhere?

HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[Kevin Yu [MSFT]]

Hi Jeff,

I don't think this matters. When instanciating another watcher, the
reference is pointed to another watcher object. The original one will be
disposed next time GC collects garbage. Could you find out under what
circumstances will this occur definitely?

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[Jeff Grundy]

The was my original question: "How can I tell why this is happening?" and I
still don't know!

One way to recreate the problem is to set the FileSystemWatcher to watch a
remote share then reboot the machine that is hosting the share.

I implimented a timer that looks to see if the FSW.EnableRaisingEvents is
set to false , and if FSW.EnableRaisingEvents is false, the timer sets
FSW.EnableRaisingEvents to true. That's my workaround. I will probably create
a class that inherits the FileSystemWatcher and also has the timer logic
built in because I am having this problem with all my FileSystemWatchers.

"Kevin Yu [MSFT]" wrote:

Hi Jeff,

I don't think this matters. When instanciating another watcher, the
reference is pointed to another watcher object. The original one will be
disposed next time GC collects garbage. Could you find out under what
circumstances will this occur definitely?

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[Kevin Yu [MSFT]]

Hi Jeff,

Thanks for your repro steps. Actually, this behavior of FileSystemWatcher
is by design.

Just as tanagra mentioned, when the server is shutting down, the share is
becoming unmounted. This causes the
problem since the FileSystemWatcher can't watch folders that don't exist.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."