views:

38

answers:

1

I have a FileSystemWatcher object setup to monitor changes to a log file written by a console app. The notifier filter is set to: watcher.NotifyFilter = NotifyFilters.Size | NotifyFilters.LastWrite | NotifyFilters.LastAccess; Env: OS: Win 2k8 server.

The console app code that dumps to the stdout that is redirected to the file out.log:

void MySet::Dump() { std::cout << this << endl; fflush(stdout); }

After I run the Dump ( in the immediate window of debugger), the file size remains the same. If I run a "type" command the update seems to happen. Any ideas

c:\temp> dir 5/21/2010 11:11 AM 4,159 out.log

After Dump: (No change )

c:\temp> dir 05/21/2010 11:11 AM 4,159 out.log

Run a "type" command ...

c:\temp>type out.log File now has the new size ... c:\temp> dir 05/21/2010 11:11 AM 4,410 out.log

Why is this behaviour ? Am I missing something here? Thanks in advance.

A: 

http://msdn.microsoft.com/en-us/library/ms724290(VS.85).aspx

Timestamps are updated at various times and for various reasons. The only guarantee about a file timestamp is that the file time is correctly reflected when the handle that makes the change is closed.

So if you're only flushing, rather than closing, then anything looking at the last write file time changing is not guaranteed to be triggered.

Pete Kirkham
Thanks for the response. I tried fclose, but that will close the file for subsequent writes- ie., fclose is not an option. What other criteria (other than size) should be used for the notify filter ?
Well, what other than the size is changing? It may be the only option, though again that isn't necessarily going to update until the close either. You might be able to force an update by opening and closing the handle for reading (which is what type is doing), but it's not guaranteed.
Pete Kirkham