Question

I have about 5-6 Server Manager programs that write their own configuration file out to a particualr folder, such as C:\ACME. The config files all end with a *ServerConfig.cfg” where * = Program name that created it.

I have a Windows service that has a FileSystemWatcher setup that I want to FTP the configuration files each time the program updates. I’ve gotten everything to work, but I’m noticing that the different Server Manager programs are behaving differently.

When saving a configuration file, the FileSystemWatcher is picking up two “change” events. This is causing my program to FTP the configuration file twice where I only need it once.

In other instances I’m seeing where it may create 4, 5, or 6 “change” events when saving a configuration file.

What is the best way to handle processing/FTPing these files when they are really done saving only one time.

I really dont want o set something up to poll the directory for filechanges every so often… and like the idea that each time a configuration is saved, I get a duplicate copy along with a date/timestamp appended to the filename copied elsewhere.

I have seen lots of suggestions Googling around and even here on Stackoverflow, but nothing that seems to be all-in-one for me.

I suppose I could put the filename in a queue when a “change” event occurred if it didn’t already exist in the queue. Not sure if this is the best approx.

Here is my sample code:

Startup-code:

private DateTime _lastTimeFileWatcherEventRaised = DateTime.Now;

_watcherCFGFiles = new FileSystemWatcher();
_watcherCFGFiles.Path = @"C:\ACME";
_watcherCFGFiles.IncludeSubdirectories = true;
_watcherCFGFiles.Filter = "*ServerConfig.cfg";

_watcherCFGFiles.NotifyFilter = NotifyFilters.Size;
//_watcherCFGFiles.NotifyFilter = NotifyFilters.LastAccess | NotifyFilters.FileName;

_watcherCFGFiles.Changed += new FileSystemEventHandler(LogFileSystemChanges);
_watcherCFGFiles.Created += new FileSystemEventHandler(LogFileSystemChanges);
_watcherCFGFiles.Deleted += new FileSystemEventHandler(LogFileSystemChanges);
_watcherCFGFiles.Renamed += new RenamedEventHandler(LogFileSystemRenaming);
_watcherCFGFiles.Error += new ErrorEventHandler(LogBufferError);
_watcherCFGFiles.EnableRaisingEvents = true;  

Here is that actual handler for the “change” event. I’m skipping the first “change” event if the second is within 700ms. But this doesn’t account for the files that make 3-4 change events…

    void LogFileSystemChanges(object sender, FileSystemEventArgs e)
    {
        string log = string.Format("{0} | {1}", e.FullPath, e.ChangeType);

        if( e.ChangeType == WatcherChangeTypes.Changed ) 
        { 
            if(DateTime.Now.Subtract(_lastTimeFileWatcherEventRaised).TotalMilliseconds < 700) 
            { 
                return; 
            }  

           _lastTimeFileWatcherEventRaised = DateTime.Now;

           LogEvent(log);

           // Process file
           FTPConfigFileUpdate(e.FullPath);   
       }
     }

Answer 1

I had the exact same issue. I used a HashMap that mapped filenames to times of writes, I then used this as a lookup table for files to check and see if the changed event had been applied very quickly. I defined some epsilon (for me it was about 2 seconds to make sure events were flushed). If the time found in the map was older than that I would put it on a queue to be processed. Essentially all I had to do was keep the HashMap up to date with events and changes and this worked out (although you may want to change your epsilon value depending on your application).