为何FileSystemWatcher无法监测打开的BDE/Paradox数据库文件变更？

这问题我之前帮朋友排查过类似的，核心原因是Borland Paradox和BDE的文件操作逻辑跟普通文本文件完全不一样，FileSystemWatcher的常规监测方式对它不适用，具体来说有这几个关键点：

1. BDE的内存缓存延迟写入机制 #

Borland Database Engine（BDE）会把数据库操作先缓存在内存里，不会实时同步到磁盘上的.db文件。只有当缓存达到阈值、应用执行了显式的事务提交，或者应用退出时，才会把缓存的数据刷到磁盘。这就导致你触发硬件事件后，数据先存在内存里，FileSystemWatcher盯着磁盘文件自然看不到变更——直到BDE真正执行写入操作的那一刻。

2. Paradox的临时文件操作模式 #

Paradox数据库在处理写入时，很少直接修改主.db文件，而是先操作一系列辅助临时文件（比如.lck锁文件、.mb备忘录文件、.val有效性文件、.px索引文件等）。很多时候它会先把变更写入临时文件，最后通过重命名临时文件替换主.db的方式完成更新。如果你的监测程序只盯着主.db文件，要么会错过这个替换过程，要么只能捕捉到一次重命名事件，很容易被忽略。

3. 64位Windows的文件重定向坑 #

你的运行环境是64位Windows 7，而老旧的Delphi原生应用几乎肯定是32位程序。Windows的文件系统重定向机制会把32位程序对C:\Program Files\目录的写入请求，自动重定向到C:\Program Files (x86)\或者%LOCALAPPDATA%\VirtualStore\对应的文件夹下。如果你的监测程序是64位编译的，盯着原来的C:\Program Files\Company Name\路径，根本看不到实际被修改的文件！

对应的解决方案 #

方案1：调整BDE缓存配置（如果可行） #

如果你还能找到BDE的管理工具bdeadmin.exe，可以尝试修改BDE的缓存设置：

• 减小缓存大小，让BDE更频繁地刷盘
• 开启“立即写入磁盘”的选项（具体选项名可能叫Write Through之类的）
  不过要注意，这会降低原应用的性能，一定要先在测试环境验证。

方案2：监测目录下所有Paradox相关文件 #

不要只盯着.db文件，把监测范围扩大到目录下所有Paradox相关的文件后缀：

watcher.Filter = "*.db;*.lck;*.mb;*.px;*.val";

当你看到这些辅助文件发生变更时，就可以去检查主.db文件的数据是否已经更新了。

方案3：确认实际写入路径 #

用Process Monitor（Sysinternals的免费工具）追踪原应用的文件操作，看它实际写入的路径到底是哪里。如果是重定向到了VirtualStore或者Program Files (x86)，就把FileSystemWatcher的监测路径改成这个实际路径。另外，也可以把你的监测程序改成32位编译（在Visual Studio的项目属性里设置平台目标为x86），这样就能绕过文件重定向问题。

方案4：替换FileSystemWatcher为Process Monitor #

如果FileSystemWatcher的方式实在不好用，直接用Process Monitor更靠谱：它能实时追踪应用对文件的所有操作（打开、写入、关闭、重命名等），甚至能看到具体的操作细节，完全不会错过任何数据库文件的变更。

你的代码小优化 #

另外，你的代码里用while (true) { watcher.WaitForChanged(WatcherChangeTypes.All); }会阻塞主线程，可能导致事件处理不及时。可以改成用控制台输入来保持程序运行，比如：

Console.WriteLine("Starting the watch...");
Console.WriteLine("Folder: " + watcher.Path);
Console.WriteLine("File: " + watcher.Filter);
Console.WriteLine("Press 'q' to quit...");

while (Console.ReadKey().Key != ConsoleKey.Q)
{
    // 保持程序运行
}

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