FileSystemWatcher does not report changes in a locked file

Question

I'm monitoring a folder using a FileSystemWatcher like this:

watcher = new FileSystemWatcher(folder);
watcher.NotifyFilter = NotifyFilters.Size;
watcher.Changed += changedCallback;

When I open a new file in notepad in that folder and save it, I get a notification. If I keep writing and then I save, I get a notification. If I close the file with saving it, I get a notification. Exactly what I wanted.

However, it turns out that if I create a file in that folder and I set its sharing mode to FileShare.Read, and then I write to it, I will not get any notifications until the file is closed. Another workaround is to open the file (e.g. in Notepad), which apparently causes its state to be updated, and then my monitoring application gets the notification. Yet another workaround is a refresh I can do in Windows Explorer, which again causes the file state to be updated.

Interestingly, if I look at Windows Explorer while I make the changes, I notice that:

1. If the file is shared for reading & writing, its size will be updated immediately in Windows Explorer as soon as I save it.
2. If the file is shared for reading only, its size will NOT be update immediately in Windows Explorer, unless I manually refresh the window.

So it seems that my monitoring application shares the same behavior as Windows Explorer. I was thinking about running a thread that will just scan the files in the folder, but I'm wondering if there's anything more elegant to be done in this case.

BTW, I'm using Win7 and I'm not sure that this problem happens on other Windows versions as well.

Thanks!

EDIT: Using ReadDirectoryChanges in C++ got me the same exact results. Implementing the thread I was talking about earlier didn't help as well. I'm wondering what is F5 in Windows Explorer actually doing, because it does cause the change to be reported.

Answer 1

The solution to the problem is not to open the files, but to actually READ from them. It's enough to read even one byte, and the Windows cache mechanism will write the contents of the file to the disk, thus allowing you to read them.

I ended up implementing a thread that went over all the files, opened them and read a byte from them. This caused them to change, and triggered the event in the FileSystemWatcher object.

The reason that Windows Explorer F5 works as well, is that Windows actually reads the contents of the file in order to show some extended contents (e.g., thumbnails). Once the file is being read, the cache first writes to the disk, triggering the event in the FSW.

Answer 2

Yes, Explorer uses the exact same API as FileSystemWatcher uses. There's just one, ReadDirectoryChangesW() as you found out.

What you found strongly suggest that Win7 is optimizing the disk write that would be needed to update the directory entry for the file. Delaying it until the last possible moment, when the file is closed. There's an interesting correlation between this observation and a critical bug that a user discovered in the RTM version of Win7. The update sometimes doesn't happen at all. The bug strikes randomly but infrequently, I've seen this myself just once on my machine. Knowingly anyway.

The details are in this thread (beware of very slow server). This still fails today with all Win7 updates applied.

Well, interesting tidbit but not really germane to your question. You do need to alter your code to accommodate the OS works.

Answer 3

I ran into this same FileSystemWatcher issue while writing a Windows Service. The service was written in .NET and used a FileSystemWatcher to monitor log files generated by a third party product. During testing I performed actions within this third party product that I knew forced log entries to be written but my service's breakpoints never fired until I opened my target log file in notepad or refreshed my view in Windows Explorer.

My solution was to create a FileInfo instance (we'll call that fileInfoInstance) at the same time as I created my FileSystemWatcher. Any time I start or stop my FileSystemWatcher I also start or stop a System.Threading.Timer whose callback invokes fileInfoInstance.Refresh() every N milliseconds. It appears that fileInfoInstance.Refresh() flushes the buffers/write caching and allows FileSystemWatcher events to raise in the same manner that hitting F5 does within Explorer.

Interestingly (and sadly) enough fileInfoInstance.Directory.Refresh() didn't accomplish the same result, so if you're watching multiple files, even if they're all in the same directory and being watched by the same watcher, you'll need a FileInfo instance for each file you're watching and your timer callback should refresh them all with each "tick"...

Happy coding.

Brian

Answer 4

Looks like the file data is cached and not actually written. When you write something to the file, the data is first placed to cache using certain file system IRP (driver request). Now when the data is actually written to the disk, another IRP is sent. It can be (this is a guess) that FileSystemWatcher catches only second IRP type.

The solution (if possible) is to call Flush on the file you are writing. If you are tracking changes made by other applications, things can become more complicated, of course.

Answer 5

You indeed need a thread that would open all files and read a byte from them, my program stopped working after I ran it on Windows 7 instead of XP, I used the following code

private void SingleByteReadThread(object notUsed)
    {
       while (true)
      {
         foreach (FileInfo fi in new DirectoryEnumerator(folderPath))
                  {
                      using (FileStream fs = new FileStream(fi.FullName, FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
                          fs.ReadByte();    
                  }

          Thread.Sleep(TimeSpan.FromSeconds(2));
      }
  }

DirectoryEnumerator is my own class

Answer 6

You have to call FileStream Flush() method to write file changes.