Windows 共享上文件的可重现文件损坏

Windows 共享上文件的可重现文件损坏

我们的内联网中有大约 40 个文件服务器用于分发软件包。这些服务器的名称为 example01、example02 等。每个名称解析为单个 IP 地址(A 记录),而 IP 解析回每个服务器的名称(PTR)。

问题是,对于某个文件(mypackage.cab),我会根据使用情况获得不同的结果:

\\192.0.2.01\fs\pkg\X12345678

或者

\\example01.foo\fs\pkg\X12345678

在一种情况下文件是正确的,而在另一种情况下文件的大小完全正确,但全为零。对于某种客户端和服务器组合,我可以可靠地重现这种情况。无论我在 Windows 资源管理器中下载、通过 robocopy 下载,还是使用 smbclient 从 Linux 下载,都没有关系。总是一样,一个文件损坏,另一个正常。

这种情况只发生在某些客户端和服务器组合上,而不会发生在其他组合上。例如:

client01 example01.foo -> OK (192.0.2.01 is also OK)
client01 example02.foo -> broken (but 192.0.2.02 is OK)

client02 example01.foo -> broken (but 192.0.2.01 is OK)
client02 example02.foo -> OK (192.0.2.02 is also OK)

client03 example06.foo -> OK (but 192.0.2.06 is broken)
client03 example07.foo -> OK (192.0.2.07 is also OK)
etc...

在某些情况下,当我使用 IP 地址时,我会得到损坏的文件;在其他情况下,当我使用名称时,我会得到损坏的文件。对于每个客户端,大多数服务器都没有问题,但是从我测试的每个客户端中,我都至少有 4 个文件损坏的情况。所有这些只发生在 mypackage.cab(大小约为 5k)上,同一目录中的任何其他文件从未发生过这种情况。

困惑吗?我当然困惑了。如果您知道是什么原因导致的,或者您知道该如何解决,欢迎提出。

客户端是 Windows XP。服务器是 NetApp 文件服务器,我无法访问。我可以(并且会)再次联系文件服务器团队,但首先我必须知道发生了什么。

答案1

找到了这种奇怪行为的解释。 example01.foo,,example02.foo等等。DFS服务器。真正的文件服务器位于其后面。其中一个文件服务器的 版本已损坏mypackage.cab

我仍然不知道某个客户端与 DFS 服务器名称或 IP 地址的组合如何始终访问同一个文件服务器。考虑到这些服务器遍布世界各地,这至少听起来是合理的行为。

文件管理员目前正在修复损坏的文件,这将有所帮助......

编辑:这解决了这个问题。

相关内容