我对 DFS 文件系统了解甚少，但在我们的一次部署中遇到了一个问题。
我们的应用程序将文件写入指定位置，关闭它们，然后将记录写入数据库。应用程序的另一部分获取这些数据库记录并读取先前写入的文件。
在某些情况下，阅读器会收到“文件未找到”的提示，并且会失败。重新启动它而不触碰任何其他东西，它会正确找到文件，一切正常。
我相信我已经排除了我们的应用程序的问题，因为该文件肯定在创建数据库记录之前被刷新/关闭了。
因此，我相信操作系统或文件系统正在内部延迟文件写入，因此文件不能立即使用。
有问题的文件系统是 Windows 2003 SP2 DFS。这个 DFS 可能出现这种情况吗？如果是，是否可以将其切换到某种写入/无缓存策略，以确保文件及时写入？
答案1
DFS 是分布式文件系统，顾名思义，它是一种“虚拟”文件共享，分布在多个服务器上并进行复制。每次您的应用程序写入文件时，它实际上访问的是位于其中一台服务器上的副本之一，如果另一个应用程序随后尝试读取相同的数据，则它很可能正在访问另一台尚未收到更新数据的服务器。
使用 DFS，你永远无法绝对确定写入的数据在后续读取时是否可用：可能总是是复制延迟；您也无法通过任何方式告诉您的应用程序与特定的 DFS 服务器“对话”：它可以自由地连接到运行它的任何一台服务器。
如果您希望此应用程序实时工作，则应使用标准文件共享，而不是 DFS。
答案2
您做出了常见但错误的假设，即存在一个通用的“之后”概念，并且如果您在另一件事“之后”做一件事，您一定会看到效果。这完全是一个错误的概念，无论你做什么都不会让它按您期望的方式发挥作用。
类比就是给某人寄一封信，收到回执，打电话给对方，并假设他们必须已读完信。
正如您所提到的，延迟写入会搞砸这件事。许多其他事情也会搞砸它。试图找到所有可能破坏并修复它们的方法简直是疯了。
相反，如果您需要操作之间的排序，请使用专门保证提供所需特定排序的东西。由于文件系统和数据库之间没有保证的排序，所以它不行。
大多数文件系统在通过在同一操作系统实例上运行的进程访问时，确实提供了有关自身及其自身操作的保证排序。因此，在正确设置文件后，您可以在同一文件系统中创建一个“触发器”文件。如果读取器看到触发器文件，那么它就可以知道数据文件是完整且有效的。完成后它可以删除触发器文件。