DirectoryWatcher watches a chosen directory and its subdirectory for changes. When a change is detected it sets its Icon in the system tray to , plays a sound, logs the change, and sets its state to “dirty”. If a file or directory is deleted, it logs the change, sets the state to be not “dirty” and sets the icon in the system Tray to . If a change is detected and the state is already dirty, no sound is played.
When you use the right mouse button on the tray icon, a context menu is displayed. By choosing “Properties” or double-clicking the tray icon, you go to the main window, where you see the log, make your settings, and reset the “dirty”-state.
The log shows the result of copying the file 02_step01_int.jpg in and deleting the file yoda.bmp. As you see, three change events are logged for a single file that gets moved/copied in. This is because the current version doesn’t filter and aggregate the events, which come from the underlying Framework-class
FileSystemWatcher, which reports changes in a directory. More about the generated and used events can be found in the Technical section. The tool does its work to report changes in a chosen directory, while generating very little load on the system. It is written with the Visual Studio 2005 Beta 2 using Visual Basic .NET. You need the .NET Framework 2.0 to run this application.
In this sample, you see the use of a lot of Framework-classes and usage of the new and handy
Subscribing for the wanted events of the
HotSpotFileSystemWatcher.NotifyFilter = _
(NotifyFilters.LastAccess Or NotifyFilters.LastWrite Or _
NotifyFilters.FileName Or NotifyFilters.DirectoryName Or _
WatcherChangeTypes.All in the changed event of the
FileSystemWatcher are never fired. This is bad since I subscribed to the Attribute change, to reset the dirty flag, when a file gets read. But changes to the file attributes as lastaccesstime doesn’t fire an event in the
FileSystemWatcher class. The creation and renaming of a folder are not distinguishable, both generate a rename, followed by a change event on the new folder. When a file gets copied in the watched folder, usually three change events on the file are logged, followed by one change event for its directory (none if it’s the root folder).
The generation of new empty files only issues a change event on the containing folder. Saving a small text causes two change events on the file and one on the containing folder. The delete of a file fires immediately a single delete event, but it is followed by a delayed change event on the containing folder, for example, when you select the containing folder in the Explorer. A rename of a file issues a rename event on the file followed by a change event on it. This in this application is no problem, since both a rename and change cause the “dirty”-state. But under other circumstances a timer must be used to distinguish between a change and rename event.
You can choose to search at the beginning for changes after the last program termination. The creation-time is only updated when the file is copied in, but not when it’s moved. Currently I check for the file and directory creation date and also the directory write date. This unfortunately fires a directory write, when a files get deleted, a condition on which we want to clear the “dirty state”.
For hiding the main-window at start up a workaround was needed, because
Visible=False has no effect in the
Load event from the form and in the designer the
Visible setting is missing.