Too many FileSystemWatcher 's ?

[Chris Murphy]

I am attempting to monitor a very large filesystem setup
as a set of window's shares. Basically, the remote
machine has a set of drives (three in fact) that each
contain folders labeled A, B, C, D .. Z split across the
drives. There is, for instance, D:\A, E:\M, and F:\Z.
These are all being shared as 'A', 'B', 'C', etc.

I am trying to monitor these for changes. I am creating
26 FileSystemWatchers and pushing them all onto a stack
(as a convenient place to keep them). What happens is
that they all work at some point or another, but sometime
after the final FileSystemWatcher (Z) is created, some of
the other watchers seem to disappear. In the currently
running instance, the C and S watchers seem to stop
sending events. When run on another computer, the R
watcher stops. It is not buffer overflows, I am catching
those and have at times seen them get thrown. This seems
to be a seperate problem. I am wondering whether I
cannot have 26 seperate watchers open due to limitations
in SMB or something, or whether there is something else
going on internally that I am missing?

Any help is appreciated...

 

[Alvin Bruney [MVP]]

if you watch the C drive for example, i would expect a stack exception to be
thrown because the file changes are just too large to be of any good. why
not narrow it down to a specific directory so you can have less events being
thrown. Also, the filesystemwatcher class is heavily dependent on the
underlying architecture with the result that it is not consistent against
OS's

 

[Chris Murphy]

Hi Alvin,
I am only throwing the FSW's onto a stack, not the
actual changes. As for just monitoring specific changes,
that defeats the purpose of this particular application.
This particular application is designed to monitor a
large file tree for all changes. What I'm trying to find
out is whether the .NET Framework is robust enough to
handle a very large tree like I have - I am also puzzled
that no exceptions are being thrown besides an occasional
buffer overrun (which is independent in all ways from the
drives that cannot be monitored). As for the OS issues,
I am running it on a WinXP box against a WinXP box - I
really don't think that's the issue, since it is working
fine (as we speak) for A-Z minus C and S.

Chris

-----Original Message-----
if you watch the C drive for example, i would expect a stack exception to be
thrown because the file changes are just too large to be of any good. why
not narrow it down to a specific directory so you can have less events being
thrown. Also, the filesystemwatcher class is heavily dependent on the
underlying architecture with the result that it is not consistent against
OS's

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok

I am attempting to monitor a very large filesystem setup
as a set of window's shares. Basically, the remote
machine has a set of drives (three in fact) that each
contain folders labeled A, B, C, D .. Z split across the
drives. There is, for instance, D:\A, E:\M, and F:\Z.
These are all being shared as 'A', 'B', 'C', etc.

I am trying to monitor these for changes. I am creating
26 FileSystemWatchers and pushing them all onto a stack
(as a convenient place to keep them). What happens is
that they all work at some point or another, but sometime
after the final FileSystemWatcher (Z) is created, some of
the other watchers seem to disappear. In the currently
running instance, the C and S watchers seem to stop
sending events. When run on another computer, the R
watcher stops. It is not buffer overflows, I am catching
those and have at times seen them get thrown. This seems
to be a seperate problem. I am wondering whether I
cannot have 26 seperate watchers open due to limitations
in SMB or something, or whether there is something else
going on internally that I am missing?

Any help is appreciated...

.