filesystem watcher duplicates events

Hello,

I wrote a simple watcher that monitors a folder for events (files being changed - they are overwritten via ftp) and when this happens displays a message on the console and runs a matlab script.

this is part of the code:


private static void OnChanged(object source, FileSystemEventArgs e)
{
Console.WriteLine("File: " + e.Name + " " + e.ChangeType);
var process = new Process
{
StartInfo = new ProcessStartInfo
{
FileName = "C:\\Program Files\\MATLAB\\R2011a\\bin\\matlab.bat",
Arguments = "-r \"prova=1;file\" ";
}
};
process.Start();
process.WaitForExit();
}




public static void Run()
{
string pathToWatch = "C:\\Documents and Settings\\aa";
string[] args = System.Environment.GetCommandLineArgs();
.
FileSystemWatcher watcher = new FileSystemWatcher();
watcher.Path = pathToWatch;
watcher.NotifyFilter = NotifyFilters.LastWrite | NotifyFilters.FileName | NotifyFilters.DirectoryName;

watcher.Changed += new FileSystemEventHandler(OnChanged);

// Begin watching.
watcher.EnableRaisingEvents = true;

}



It works all fine besides the fact that every time a file is changed, it displays it twice on the console and runs matlab twice. There are ways to avoid this, of course, but I was wondering why this happens?

Seems to be a known issue, see: http://bytes.com/topic/c-sharp/answe...esystemwatcher

Possible workaround: http://spin.atomicobject.com/2010/07...atcher-events/

Also, please use [code] and [/code] tags around your code; it will preserve formatting and make it more readable.

Hope that helps!

More likely is the WaitForExit causes the OnChanged handler to block which in tern causes the change evevts to queue up.

Quote:

---

Originally Posted by Arjay

More likely is the WaitForExit causes the OnChanged handler to block which in tern causes the change evevts to queue up.

---

Hrm... I am not sure about this. It oughtn't to trigger multiple events for any single file change, so the amount of time it takes to process doesn't seem like it should matter. The articles I referenced seemed to suggest that the duplicate events for the same file where due to FileSystemWatcher monitoring underlying filesystem events which were (for whatever reason) duplicated.

No?

Quote:

---

Originally Posted by BioPhysEngr

Hrm... I am not sure about this. It oughtn't to trigger multiple events for any single file change, so the amount of time it takes to process doesn't seem like it should matter. The articles I referenced seemed to suggest that the duplicate events for the same file where due to FileSystemWatcher monitoring underlying filesystem events which were (for whatever reason) duplicated.

No?

---

I not saying this is definitely the problem, but if the watcher throws an event and the OnChanged event doesn't immediately return, it's possible that another event will occur while the OnChange event is blocked.

One way to verify my suggestion is to write some debug output strings inside the OnChange handler (and temporarily remove the blocking process.WaitForExit() call).

Another possibility is the OnChange handler might be used for multiple change events. If I recall correctly, there is a filter that specifies what types of events that are thrown (i.e. new, changed, renamed, etc. events). If these are wired up to the same handler, you can get what appear as duplicates if the same handler is used.

Check out the ChangeType property for the FileSystemEventArgs to help narrow down the cause of the change.

I can't say for sure but am thinking that perhaps the reason it fires twice when a file is overwritten could be that it sees the existing file removed then created. I did some work with this object a while back and in some instances it was firing twice. I ended up coding around it so I could get the program out to the end user on time.