The original version used a Timer object to trigger verification of the folder's existence. The article was written in VB.Net, so I had to convert it to C#, and I also made the following modification. The reasons are laid out in his article, but I'll summarize his description by saying that if the watched directory somehow becomes inaccessible (maybe it's on a remote machine, maybe it was deleted), the FileSystemWatcher object doesn't recover - at all. In that article, George created an extension of the FileSystemWatcher class that allows it to monitor the folder being watched to make sure it's available. While I was researching for this article, I stumbled across a CodeProject article by George Oakes, called Advanced FileSystemWatcher. Something Borrowed - The FileSystemWatcherEx Class You should now be able to pick and choose which events to handle, and when. Gone (I hope) are the days of multiple events that are fired when programs like Notepad create a file. The technique presented in this article is in the form of a wrapper class than manages these individual FileSystemWatcher objects and provides a handy interface and event mechanism that can be used to cherry-pick the filters you want to use. You can pretty much guess that trying to manage that many FileSystemWatcher objects in a form would be excruciatingly painful. I came to the realization that you would need up to NINE FileSystemWatcher objects to pull this off - one to handle all of the other ChangeTypes, and one for each of the eight NotifyFilter enumerators. The ChangeType property in the FileSystemEventArgs parameter for the event merely indicated whether the item in question was changed, deleted, created, or renamed, and there is no property indicating the applicable filter in the case of the Changed event. You could use one or more of these filters, but upon receiving the Changed event, there is no way to see whatįilter actually triggered the event. I found this particularly irritating since they provided eight notification filters to make the FileSystemWatcher send the Changed event. My primary issue is that the FileSystemWatcher allows you to be notified that a file in a folder has changed, but not precisely what change was made. It was then, that the thought occurred to me that these FileSystemWatcher problems have never really be addressed (that I could find). A day or so ago, someone posted a question regarding a similar task, and I immediately suggested the same route I had taken. I became immediately aware of the shortcomings of the FileSystemWatcher class, and those shortcomings have always kind stuck to my brain. One of my first official tasks as a DotNet programmer was to write a Windows Service which monitored a folder on a server for new files, processed those files, and then transferred them to another server (via FTP).
0 Comments
Leave a Reply. |