FileSystemWatcher - Pure Chaos (Part 2 of 2)

Introduction

In Part 1 of this article series, I created a class that sends a separate event for each NotifyFilter item in the DotNet FileSystemWather object.

View Part 1 of this article series. This is where you should go to get the sample application.

In this article, I'll discuss the ramifications of using this class, and some quirks regarding the functionality of the FileSystemWatcher object. This article is more a series of screen shots and relevant discussion rather than an examination of code, so if you're not inclined to read this, don't feel too bad about it. However, I would recommend that you do read this one, because it reveals what I consider to be "good-to-know" info.

We won't be exercising the folder existence code in this article, and instead will be focusing on the standard events that are spewed out by the DotNet FileSystemWatcher object.

Note: I'm using Windows7 Ultimate (64-bit). I don't know if you'll see different results on older (or newer) versions of Windows. I see no reason why you should, but hey, who knows?

Before We Start

First, I assume that you downloaded the source code/ demo application from Part 1. If not, and if you'd like to sing along, please download that code now. Since the release binary is included with the project, you may simply run it (there's no need to fire up the IDE and compile it).

Some Interesting (For Me) Discoveries

When we fire up the demo application, we are greeted with the following form.

The TextBox is automatically populated with a folder that exists on my system. Your first action should be to change this value. You can use the browse button to find an appropriate folder. You may want to change the hard-wired path value to something that reflects your own drive\folder hierarchy so that the default folder is more appropriate for you, but you'll have to change the code (in the form) and recompile if you want to do this. Remember, it's just a demo app and not all of the expected bells and whistles, such as saving/retrieving settings, have been implemented.

Creating a File

There are several ways to create a new file in a folder. As expected, simply right-clicking in the folder and selecting "New Text Document" from the context menu results in a single event.

However, this is what happens when you create a new file from Notepad.

Holy Crap! That's a LOT of events for simply saving a new file from Notepad. I checked the debug trace and that's apparently the order in which the events are really fired. In this case the file was only 7K, so the events appeared to all fire at pretty much the same time. You would think that would explain why the time of the event appears to be the same, but check this out:

This output was generate when I tried to save a 7mb file from Notepad. In real time, it took 14 seconds to get the last event generated by saving such a large file. And if you think Notepad is messed up, check out the results of creating a new file from Microsoft Word 2007:

Man, I never knew there was so much going on behind the scenes in Microsoft Word. Let's check out saving a new file from PaintShop Pro...

Granted, that's a little better, but still, notice the repeated Created event (a common theme). As if that's not weird enough, here's what happens when you copy a file from a folder on the same hard drive into our watched folder.

I don't see any Created events at all, despite the fact that the file was "created" in the folder. Here's what happens when you copy a file from a different hard drive.

Finally, I downloaded a file with FireFox into the watched folder, and got these results.

I don't know about you, but I'm tired. :)

It Boggles The Mind

Personally, I think the FileSystemWatcher object is - for lack of a better term - just plain wacky. The bizarre aspect of this is that it's not really the fault of the object, because it's merely reporting what's happening in the folder.

There's no possible way to predict what someone else's needs will be with regards to using the FileSystemWatcher object. As you can see, results vary from one extreme to the other. I suppose what we've learned here is that how you handle the object's events depends COMPLETELY on how (and by what mechanism/application) you expect the files to be placed in the watched folder. In light of this realization, you could make use of this demo application so that you can investigate your own requirements and design a cohesive plan for handling those events in whatever manner you might choose. The upside is that now you don't have to perform nearly as many reactive changes in the code in order to handle all of your expected file types (and their source applications/mechanisms).

Finally, you can use this sample application to examine your own applications' file handling processes. You might be surprised when you see exactly what is happening in your own applications.

History

12/18/2010 - Fixed some wording and a couple of misspellings.

02/14/2010 - Original version.