Windows 共享上文件的可重現文件損壞
我們的 Intranet 中有大約 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 文件管理器。我可以（並且將）再次聯繫申報者團隊，但首先我必須知道發生了什麼。
找到了這種奇怪行為的解釋。
example01.foo,example02.foo, 等是DFS伺服器。真正的文件伺服器在他們身後。其中一個文件伺服器的mypackage.cab.我仍然不知道某個客戶端與 DFS 伺服器名稱或 IP 地址的組合總是命中同一個文件伺服器是如何工作的。考慮到這些伺服器遍布世界各地，至少這聽起來是合理的行為。
文件管理人員目前正在修復損壞的文件，會看到它有幫助…
編輯：這解決了問題。