Tuesday, August 28, 2007

FileSystemWatcher - My Tiny Contribution

FileSystemWatcher is a .Net class that allows you to watch a folder in the operating system for changes and raise events when files are created, changed or deleted. But after trying to utilize it seriously in a production-level application, I found the class has some limitations:
  1. The class maintains a memory buffer to collect the changes. This buffer is 8kb in size (can be in increased to 32kb at design time only), meaning that if the directory you watch changes often, the buffer would fill up and you'd stop getting those notifications.
  2. When you receive the Changed event, all you get is the file name. Not what changed or who changed it. Meaning, you have to collect that information from all files and run comparisons - clearly inconvenient and beats the point of automation.

The internet is full of people who bitch and moan about these and other shortcomings of this class and other Microsoft products. I've decided to do something. Enter Microsoft Connect that allows you to submit bugs and feature requests to Microsoft, pertaining to all its products and get patches and beta software before the rest of the world does. Log in and register into one of the "connections" - you can use your Live ID (like the one you use in Live Messenger) if you have one already.

And here's my 2 submissions along with the replies I got:

Bug ID 287202: The default size of the FileSystemWatcher's InternalBuffer is 8k. If there is more than one change a second, pretty soon it runs out of memory and rendered useless.
Why do I even have to care or manage the internal memory of a component?
Please have this fixed by having it dynamically allocate the amount of memory needed to handle the events fired.

Microsoft's Reply:

Thanks for the feature request!
Adding internal support for dynamically managing the internal buffer would be useful. We'll consider this for the next release of the .NET Framework after .NET 3.5.
Justin Van Patten
CLR Program Manager

Bug ID 287212: Currently, all I get from FSW is the name of the file and the event type (changed, created, deleted or renamed). I need to know WHAT changed (attribute, last time changed) and also, if possible, the user name of the one who touched it - this is critical.
Right now, it's like saying "something happened!" without elaborating :)

Microsoft's Reply:

Thanks for the feature request!
Adding this additional functionality to FileSystemWatcher would be interesting and useful. We'll consider this for the next release of the .NET Framework after .NET 3.5.
Justin Van Patten
CLR Program Manager

And these are my tiny contributions to .Net 4.0 :)


Anonymous said...

How long did it take for the response to come?

Traveling Tech Guy said...

Hi Shlomo,
Good question. My original bug and feature request were submitted on 7/12 and marked as "resolved" on 8/28, as can be seen below:


Resolved (External)
Access Restriction

Submission Language

8/28/2007 11:52:58 AM

Not too bad, in my humble opinion.

Anonymous said...

It seems to be a bit too slow for an automated answer. Or maybe they have a timer for that?...

Traveling Tech Guy said...

It's not automated - I just didn't post the entire escalation - there are 2 other people involved.

Tanner said...

what about the bug where you are watching a network share, and the network connection drops out?

The watcher just sits and spins, never knowing to reconnect. You never get events, etc unless you restart your app/service.

This was the #1 reason I couldn't use this class. #2 was the buffer constraints. A close runner up in 3rd was the fact that after byte #1 was written on a new file, the created event was raised. This makes things a pain when you have services to pick up those files and open them because you have to block on a thread or you get IO file locked exceptions.