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.Cha         


        

Answer 1

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 2

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 3

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 4

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

Answer 5

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 6

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.