当两个文件完全相同时,RoboCopy 会将其视为已更改

当两个文件完全相同时,RoboCopy 会将其视为已更改

使用 RoboCopy,我在存储设备之间复制大量文件,并注意到一些奇怪的行为:在很多情况下,当源文件和目标文件相同时,RoboCopy 会认为文件已更改并再次复制。我已验证文件的大小和日期相同。我正在使用以下命令。正在使用的 RoboCopy 版本来自 Vista/Windows 2008。

robocopy "W:\SourceFolder" "Q:\Destination Folder" /E /R:2 /W:5 /NP /LOG+:%1 /tee /fft /purge 

这里使用的 /FFT 开关通常可以解决这个问题 - 但在这里不行 - (因为这些页面解决了同样的问题:Robocopy 错误地将文件标记为较新本身指的是在不同文件系统之间复制时,Robocopy 错误地将文件检测为较新的文件

答案1

观察到的行为可能是 Robocopy 中的报告问题导致的。

我可以使用 Windows 10 版 Robocopy 重现以下情况:我使用开关在两个几乎相同的目录上运行 robocopy ,即不进行任何更改,仅记录实际执行作业时将发生的操作(如指定)。我比较了以下开关组合(详细日志,列出跳过的文件)和(跳过标记为已更改的文件)以及其他默认行为/L在日志中报告的文件列表和跳过的文件数量:/V/XC

  1. /L /V- 列出了大量已更改(但实际上相同)的文件,根据日志摘要,跳过了 2309 个文件。
  2. /L /V /XC- 没有列出更改的文件,根据日志摘要,跳过了 2309 个文件。
  3. /L /XC- 没有列出更改的文件,根据日志摘要,跳过了 2309 个文件。
  4. /L- 没有列出更改的文件,根据日志摘要,跳过了 2309 个文件。

无论使用哪种开关,在所有 4 次运行中跳过的文件数量都是完全相同的/XC。如果分类为已更改在运行 1 的详细日志中实际上要复制它们,那么我希望看到它们列在运行 4 的日志中,并且我希望在运行 2 和 3 中报告大量跳过的文件(实际上)更改的文件被跳过,而运行 1 和 4 中则没有。

我的结论是,由于某种原因,在详细日志中,robocopy 将具有相同大小和时间戳的文件标记为已更改但实际上并不这样对待它们,特别是不复制它们。

当然,这仍然不能解释为什么这些文件被标记为已更改首先。

相关内容