I’m just starting out with Windows development and need to track all file system modifications. I want to capture the same kind of data that tools like Process Monitor show, but through programmatic means. Right now I’m thinking about using ReadDirectoryChangesW for each physical drive on the system, but I’m wondering if there are better alternatives available in the Win32 API. Should I stick with this approach or are there other C++ APIs that would be more efficient for comprehensive file monitoring? I need to cover all local drives but exclude network mapped drives. Any suggestions for the best practice here?
I’ve used ReadDirectoryChangesW quite a bit for file system monitoring. It’s pretty standard and works well for tracking file changes, but you’ll need to monitor each directory separately - which gets messy with deep folder structures. You could go with a File System Filter Driver instead, but that’s kernel-mode stuff and usually overkill unless you’re doing something really specialized. For most apps, I’d stick with ReadDirectoryChangesW and pair it with FindFirstChangeNotification to keep things simple. Just make sure you handle your buffers properly and use overlapped I/O - otherwise you’ll miss updates when things get busy.
procmons pretty dope since it uses ETW for monitoring. it gives better perf than ReadDirectoryChangesW. if ur looking for something simpler than ETW but still an upgrade, maybe try the Volume Shadow Copy Service API? it’s mainly for snapshots though, not real-time stuff.
Try WMI with the Win32_VolumeChangeEvent class for broader file system monitoring. It’s really useful when you need to watch multiple drives without spawning separate threads for each one like ReadDirectoryChangesW does. Performance isn’t as good as native APIs, but it handles drive enumeration automatically and filters out network drives by default. Also check out USN Journal through DeviceIoControl with FSCTL_QUERY_USN_JOURNAL. This gives you a transaction log of all file system changes and can be way more efficient for bulk monitoring since it works at volume level instead of directory level. Main downside is USN Journal needs NTFS volumes, but that’s most local drives anyway.