我对 DFS 文件系统知之甚少，但在我们的部署之一中遇到了问题。
我们的应用程序将文件写入指定位置，关闭它们，然后将记录写入数据库。应用程序的另一部分获取这些 DB 记录并读取之前写入的文件。
在某些情况下，阅读器会收到“未找到文件”并且失败。在不接触任何其他东西的情况下重新启动它，它正确地找到了文件，一切都很好。
我相信我已经排除了我们的应用程序的问题，因为在创建数据库记录之前文件肯定被刷新/关闭。
因此，我相信操作系统或文件系统在内部延迟了文件写入，因此它不是立即可用的。
有问题的文件系统是 Windows 2003 SP2 DFS。这个 DFS 可能会出现这种情况吗？如果是这样，是否可以将其切换为某种直写/无缓存策略以确保及时写入文件？
DFS 是分布式文件系统，顾名思义：跨多个服务器分布和复制的“虚拟”文件共享。每次您的应用程序写入数据时，它实际上是在访问属于它的其中一台服务器上的一个副本，如果另一个应用程序随后尝试读取相同的数据，它很可能正在访问另一台服务器，而该服务器并没有这样做。尚未收到更新的数据。
使用 DFS，您永远无法绝对确定写入其中的数据在后续读取中可用：始终可能存在复制延迟；您也没有任何方法告诉您的应用程序与特定的 DFS 服务器“对话”：它可以自由地连接到运行它的任何一台服务器。
如果您希望此应用程序实时工作，您应该使用标准文件共享，而不是 DFS。