Click here to Skip to main content
15,867,453 members
Articles / Programming Languages / C#

FileSystemWatcher - Pure Chaos (Part 2 of 2)

Rate me:
Please Sign up or sign in to vote.
4.91/5 (77 votes)
17 Dec 2010CPOL4 min read 155K   161   57
Use the demo application (from Part 1) to observe events posted when creating files in the watched folder

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.

Image 1

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.

part2_image_02.jpg

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

part2_image_03.jpg

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:

part2_image_04.jpg

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:

part2_image_05.jpg

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...

part2_image_06.jpg

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.

part2_image_07.jpg

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.

part2_image_08.jpg

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

part2_image_09.jpg

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.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Software Developer (Senior) Paddedwall Software
United States United States
I've been paid as a programmer since 1982 with experience in Pascal, and C++ (both self-taught), and began writing Windows programs in 1991 using Visual C++ and MFC. In the 2nd half of 2007, I started writing C# Windows Forms and ASP.Net applications, and have since done WPF, Silverlight, WCF, web services, and Windows services.

My weakest point is that my moments of clarity are too brief to hold a meaningful conversation that requires more than 30 seconds to complete. Thankfully, grunts of agreement are all that is required to conduct most discussions without committing to any particular belief system.

Comments and Discussions

 
GeneralHighly informative Article Pin
Yogi Yang14-Feb-10 19:19
Yogi Yang14-Feb-10 19:19 
GeneralNice Pin
Pandey Vijay Kumar S.14-Feb-10 16:48
Pandey Vijay Kumar S.14-Feb-10 16:48 
GeneralNice article Pin
Abhinav S14-Feb-10 10:42
Abhinav S14-Feb-10 10:42 
GeneralRe: Nice article Pin
#realJSOP14-Feb-10 11:18
mve#realJSOP14-Feb-10 11:18 
GeneralGreat Pin
Luc Pattyn14-Feb-10 10:07
sitebuilderLuc Pattyn14-Feb-10 10:07 
GeneralRe: Great Pin
#realJSOP14-Feb-10 10:18
mve#realJSOP14-Feb-10 10:18 
GeneralRe: Great Pin
Luc Pattyn14-Feb-10 10:24
sitebuilderLuc Pattyn14-Feb-10 10:24 
GeneralRe: Great Pin
jberke16-Feb-10 4:54
jberke16-Feb-10 4:54 
You would think the system could tell you when a file was done being processed but this assumes that the manipulating application uses the file in a proper appropriate manner. What happens for example if a file is being copied (FTP'ed) and fails halfway? I sure hope the app releases the file handles and unlocks it, yet the file may not be done.

I worked on a project that monitored a users computer looking for a collection of 1-15 files to be written. The files were being written out by various applications outside of our control. What we saw was each application shows different behaviors, but one common thread was the Create - Delete - Create.


The best methods we have ever come up with (And by no means am I implying these are the best methods out there just the best we came up with), are to use some of type of marker or done file to indicate the file is completed. Or in cases where we couldn't was to use a settling algorithm, where we would detect the events on the file then start to monitor it and wait a certain amount of time, then check it again and see if the file changed.
AnswerRe: Great Pin
Luc Pattyn16-Feb-10 5:00
sitebuilderLuc Pattyn16-Feb-10 5:00 
GeneralRe: Great Pin
jberke16-Feb-10 5:06
jberke16-Feb-10 5:06 
GeneralRe: Great Pin
#realJSOP16-Feb-10 7:11
mve#realJSOP16-Feb-10 7:11 
GeneralRe: Great Pin
pedro-gon27-Feb-14 0:32
pedro-gon27-Feb-14 0:32 
GeneralRe: Great Pin
dchrno22-Feb-10 11:16
dchrno22-Feb-10 11:16 
GeneralRe: Great Pin
Rose Epinglee23-Sep-10 15:46
Rose Epinglee23-Sep-10 15:46 
GeneralRe: Great Pin
Luc Pattyn14-Feb-10 10:33
sitebuilderLuc Pattyn14-Feb-10 10:33 
GeneralRe: Great Pin
#realJSOP14-Feb-10 11:20
mve#realJSOP14-Feb-10 11:20 
GeneralRe: Great Pin
#realJSOP14-Feb-10 11:22
mve#realJSOP14-Feb-10 11:22 
GeneralRe: Great Pin
Luc Pattyn14-Feb-10 11:38
sitebuilderLuc Pattyn14-Feb-10 11:38 
GeneralRe: Great Pin
NguyenTrucMinh23-Sep-10 15:44
NguyenTrucMinh23-Sep-10 15:44 
GeneralExcellent Pin
sam.hill14-Feb-10 9:38
sam.hill14-Feb-10 9:38 
GeneraluseFULL Pin
Dan Mos14-Feb-10 8:30
Dan Mos14-Feb-10 8:30 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.