我们使用以下脚本将文件夹（相当大 - 大约 400GB）备份到具有 EXT4 文件系统的 NAS：
robocopy "Source_Directory" "\\NAS\Destination\Directory" /MIR /FFT /COPYALL /W:5 /r:10 /log:"C:\RoboTest\robotest.log"
研究表明，需要使用 /FFT 开关来弥补时间差异；然而问题仍然存在，所有文件都被标记为已修改。
任何帮助都将不胜感激。
答案1
经过多次反复尝试后，我想我找到了原因：Archive 属性。
当 Robocopy 遇到设置了存档属性的文件时，它会系统地在其日志中将文件显示为“已修改”，并将文件大小计入复制到目标的总数据量（已复制列）。然而，这是误导性的，因为除非文件确实被修改（例如，时间戳较新），否则 Robocopy 不会真正复制该文件，而是跳过它。
尝试使用一个大文件。将一个大文件添加到源树中，该文件需要一些时间才能传输到目标服务器。第一次运行 Robocopy：它应该在日志中将文件标记为“新文件”，并需要一些时间来完成传输。接下来，确保使用命令在该文件上设置了存档位attrib +a <filename>。再次启动 Robocopy。您应该会发现它将被列为“已修改”，但请注意第二次运行要快得多：Robocopy 实际上并没有通过网络再次传输文件。然后，最后，删除存档位attrib -a <filename>并最后一次运行 Robocopy。它将按预期跳过该文件。
不幸的是，我找不到任何地方记录这种行为，甚至在微软自己的文档页面上也是如此。（如果有人找到，请告诉我们！）
解决方案是忽略日志中标记为“已修改”的文件，或者attrib -a /s在运行 Robocopy 之前在源文件上运行。
答案2
您可以添加/a-:a到 robocopy 命令行以在过程中删除存档位。