ReadDirectoryChangesW对2GB以上文件停止发通知？求解决方案

一、是否存在固有限制？ #

ReadDirectoryChangesW（包括ReadDirectoryChangesExW）本身无官方明确标注的2GB大小限制，但这是NTFS文件系统结合该API时的已知未公开行为。当文件大小跨越2GB（2^31字节，32位有符号整数上限）时，NTFS在传递变更通知的结构体中，部分与文件大小相关的字段会出现溢出或异常处理逻辑，导致API后续无法正常推送通知，而文件本身的写入不受影响。

另外，若你的应用是32位编译的，会加重该问题：32位程序中用于存储文件大小的DWORD变量无法容纳超过2GB的值，解析FILE_NOTIFY_INFORMATION结构体时会出现溢出错误，直接导致后续通知处理中断。

二、已知规避方法 #

1. 切换为64位程序编译 #

若当前应用是32位，优先改为64位编译。64位环境下，文件大小用64位整数（ULARGE_INTEGER）存储，不会出现32位溢出问题，多数场景下可直接解决2GB以上文件的通知中断问题。

2. 结合主动定期扫描 #

在保持ReadDirectoryChangesW监听的基础上，新增定时任务（比如每隔30秒到1分钟），主动遍历监听文件夹，对比文件的大小、最后修改时间等属性，捕获那些API未推送的变更。这种方法实现简单，适合快速补全监听逻辑的漏洞。

3. 使用USN变更日志（推荐） #

USN（Update Sequence Number）日志是NTFS内置的文件变更跟踪机制，比ReadDirectoryChangesW更可靠，不受文件大小限制。通过DeviceIoControl调用相关控制码读取日志：

• 先调用FSCTL_QUERY_USN_JOURNAL获取当前日志的状态信息；
• 再循环调用FSCTL_READ_USN_JOURNAL读取新的变更记录，这些记录包含文件的所有操作（创建、修改、大小变更等），即使文件超过2GB也能持续捕获。
  注意：使用USN日志需要管理员权限，且要处理日志满后循环覆盖的情况。

4. 拆分大文件（仅适用于可控写入场景） #

若文件写入由你方程序控制，可将大文件拆分为多个小于2GB的分片，写入完成后再合并为完整文件。这种方法能从根源上避免触发2GB阈值的问题，但对外部程序写入的场景不适用。

内容的提问来源于stack exchange，提问作者Bjoern