使用FileSystemWatcher如何获取已删除文件的最后写入时间？是否需采样基线？

要不要预存全量基线？ #

不是必须，但FileSystemWatcher本身的Deleted事件里确实拿不到已删除文件的元数据——文件都删了，系统不会再保留这些信息供读取。不过有几种不用提前扫描全量文件的变通办法：

无需全量基线的实现思路 #

• 实时缓存变更文件的元数据：如果你的场景里，文件删除前大多会有修改、重命名操作，那可以在Changed/Renamed事件触发时，把文件的最后写入时间存到一个字典里（用文件路径当key）。等Deleted事件触发时，直接从字典里取对应的值即可。唯一的问题是如果文件被直接删除（之前没触发过任何变更事件），缓存里会没有数据，但很多业务场景里这种情况占比很低。
• 查询系统事件日志（仅Windows）：Windows的事件日志会记录文件删除操作，其中包含文件路径和部分元数据。你可以在Deleted事件触发后，查询对应时间点、对应路径的日志条目，提取最后写入时间。这个方法不用预存基线，但需要程序有读取事件日志的权限，且要考虑日志查询的性能开销。
• 自行封装底层API：FileSystemWatcher本质是封装了Windows的ReadDirectoryChangesW API，如果你自己封装这个API，可以尝试在收到删除通知的瞬间读取文件元数据——不过要注意，此时文件可能已经被标记为删除状态，能否读取到数据全看系统的处理时机，稳定性不如前两种方案。跨平台场景可以考虑用libuv这类库，但实现复杂度会高不少。

是不是用错工具了？ #

FileSystemWatcher是轻量级的变更通知工具，设计初衷是快速告知“文件发生了变更”，而非保留已删除文件的元数据。如果你的业务必须100%获取到每个删除文件的最后写入时间：

• 最可靠的方案是增量构建基线：启动时不用扫描全量文件，而是在文件Created事件触发时记录元数据，后续Changed事件触发时更新数据，这样基线会逐步构建完成，避免启动时的大规模扫描开销。
• 如果连增量构建都不想做，那FileSystemWatcher确实无法满足需求，需要更换更底层的钩子工具，或者结合系统日志来补全数据。

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