FileSystemWatcher

  • Thread starter Thread starter Pedro C. Valenzuela
  • Start date Start date
P

Pedro C. Valenzuela

Hello,

Does anyone know how a File System Watcher windows control works to detect
file changes accross the network to a remote machine?
I am trying to watch for new files in 30 different folders in a remote
machine that has around 1000 folders.
I dont know if it's wise to put one single watcher for the whole machine, or
30 different watchers because i dont know if the watchers take up bandwidth
or processing power.

If someone knows, I really appreciate it.
 
* "Pedro C. Valenzuela said:
Does anyone know how a File System Watcher windows control works to detect
file changes accross the network to a remote machine?
Click to expand...

<msdn>
Use FileSystemWatcher to watch for changes in a specified directory. You
can watch for changes in files and subdirectories of the specified
directory. The component can watch files on a local computer, a network
drive, or a remote computer.
</msdn>
 
Yes, I read that too and it tells me what it does, but not how it does it.

Im more interested in knowing how it does it to better optimize my code.
Any ideas?
 
Hi Pedro,

I can't give you the gospel on this but I can tell how I'd do it if it
were me. See if it makes sense.

There'd be a single component (process or whatever) within the system that
did <all> the file watching for everyone. It would have a list of who's
watching what. And it would have a single hook into the file system IO. Any
creation/deletion/change to the file system would trigger this global watcher.
This would check the directory in which the change occured against its list.
If there was a match it would check the file too. If there was still a match
then it would send off a signal to the process or processes that are
interested in that particular file or directory.

This, to my, mind would minimise the processing. If there were several
components each doing a single watch, the notification that <something> had
changed would have to go from IO to <each> of the components. Then each would
have to check its list in the same manner as above. The overhead of multiple
callouts and several lists seems needless to me. A single component with a
single list makes the is-it-being-watched check as efficient as possible.

I would expect that Windows does it at least as efficiently as that (they
may have techniques which I don't know) but I'd be very surprised if it were
less efficient.

So, to your question. Whether you have a single watcher for the machine,
or a list of 30 folders, the file system IO is still going to call the Watcher
for each change, so that doesn't matter. Checking a simple list of 30 items as
opposed to a single item is really neither here nor there either -
microseconds, maybe. But sending out a notification to your app for any change
as opposed to only for those changes that matter. Well, that might be
significant, depending on how many irrelevant file system changes there are
and how much bandwidth each takes. Bandwidth over processing, I'd say.

Like I say, this isn't how it <is> done, but I would hope it's a
reasonable simplification. I suspect that there will be a Windows Service or
two involved.

Regards,
Fergus
 
hey Fergus,

What you explained is what I have in my head. However reading over MSDN i
could never find some sort of documentation or article that explained the
inner workins of the file watcher. At the current time the decision is to
have one for all. But like I said, I dont know how they hook to the file
system. Do they work with some sort of hook? Or do they scan each folder
continously? I haven't done a test and the only reason i'm asking here is
because I dont have enough time to test it out, or else I would.

Other than that, yep, I am using a service.
Thanks alot for your comments though!


Regards,
Pedro
 
Hi Pedro,

The directories can't be continuously scanned (think of scanning C:\ and
all subdirectories) - it has to be reactive, hence event driven. There will
therefore be something hooked into the file system IO and I'm fairly certain
that it's a Windows Service, but cannot point to anything in documentation.

In my Win2000 there's a service called Logical Disk Manager Watchdog
Service which sounds like a good candidate. You could try stopping that
service and see if the FileSysWatcher notifications cease. Of course, lol, you
might find that other disk-related activities disappear until you restart the
service!

As well as posting here, you might want to pose it to the languages.csharp
people too, and, on the assumption that this FileSysWatcher is based on
existing technology, in the public.vb.winapi group.

If you do post there and they give you something concrete, it would be
interesting to read your findings if you can post them back here. :-)

Regards,
Fergus
 
I'm not sure how the FileSystemWatcher class in the .NET Framework does the
job, but I wrote a similar service in C++ before .NET was around. I used the
FindFirstChangeNotification, FindNextChangeNotification, and
WaitForMultipleObjects APIs. No polling involved. The
FindXxxxChangeNotification APIs are efficient because they wait on a
notification handle to become signalled. You can specify a particular
folder, or optionally include all subfolders. You can also specify the
conditions that you want to monitor:

FILE_NOTIFY_CHANGE_FILE_NAME,
FILE_NOTIFY_CHANGE_DIR_NAME,
FILE_NOTIFY_CHANGE_ATTRIBUTES,
FILE_NOTIFY_CHANGE_SIZE,
FILE_NOTIFY_CHANGE_LAST_WRITE, or
FILE_NOTIFY_CHANGE_SECURITY.

note that FILE_NOTIFY_CHANGE_FILE_NAME includes creates and deletes.

I suspect that the .NET framework uses these APIs under the hood.

In my case, I had a single call to WaitForMultipleObjects blocking on all
monitored directories (no subdirectories) rather than a seperate call to
WaitForMultipleObjects per directory, but in my case, they were all local
directories. Don't know how this behaves on a remote machine. Hope this
helps.

Good Luck,
Dave
 
Most likely FileSystemWatcher uses the API functions mentioned by David
(FindFirstChangeNotification, FindNextChangeNotification,
WaitForSingleObject(or WaitForMultipleObjects, or WaitWithEvents).

That is why I would advise not to watch more than you need to see. For
example if you watch a "c:\" you will all the time get events and majority
of them will be not of your interest. Thus your process will use a lot of
system resources doing nothing.
See also "Considerations for File Changes on High-Volume Systems" article in
MSDN.

On other hand watching a directory where nothing happens does not cost you
processor. It costs just some memory and some kernel memory (kernel
objects).
This is based on assumption that FileSystemWatcher will register for file
change notifications in some directory, create a thread and run WaitFor...
function in it.

If you were writing in API you could register for notification from several
directories and after that wait for several changes in one thread using
WaitForMultipleObjects.
Thus you might save on additional threads, which, as we suppose, are opened
by instances of FileSystemWatcher.
 
Thank you all for your replies, they have been very helpful. Specially
Fergus!
I have a pretty good idea how this works in local machines now, but I will
do a little bit more research when I can on how it does it remotely. That's
my situation :)


Pedro
 
Back
Top