Robocopy - 记录输出时可能出现问题?

Robocopy - 记录输出时可能出现问题?

我正在评估 Robocopy 是否适合我的备份脚本,该脚本将仅将较新的文件从 C 盘(NTFS)备份到 Pendrive(exFAT)。

我正在运行这个命令。它可以完成工作,但当目标是可移动 USB 笔式驱动器且也是 exFAT 格式时,似乎会出现错误的记录。如果目标是 FAT 或 NTFS,则不会发生此问题。

robocopy C:\Temp\F1 D:\F1 /XO /E /FFT /LOG:C:\Temp\robo.txt /NP  /NDL /R:1 /W:3

在上面的命令中,D: 是 pendrive 字母,并且命令或 .BAT 文件始终在 Windows 7 Ultimate 64 上以管理员身份运行。

该问题出现在案例 2 中,如下所述。

案例 1 - 查看日志截图。这似乎是正确的。所有复制的文件名都已记录,复制统计信息正确。已复制 3 个文件。

在此处输入图片描述

案例 2 - 我在源中添加了一个文件。现在它只复制了这个新文件,但日志和统计信息中显示的所有文件都是错误的。它显示已复制 4 个文件。

在此处输入图片描述

仅当目标是 exFAT 格式的 U 盘时,才会发生这种不一致的日志记录。FAT 或 NTFS 不会出现问题。

操作系统 - Windows 7 Ultimate 64。

问题。

  1. 当目标是 exFAT 笔式驱动器时,这是 Robocopy 日志记录中的一些问题或错误吗?
  2. 如果没有,我是否缺少命令中可以解决此问题的任何选项?

将不胜感激对此有进一步的澄清。


编辑

情况 3 - 没有变化,它仍然在日志文件中列出所有 4 个文件。

在此处输入图片描述

/FFT 或其缺失不会改变日志数据。

我使用免费文件同步进行了检查,两个目录的文件大小、时间戳和实际内容均同步。我认为它不是在复制,但仍在记录。

在此处输入图片描述


编辑2

我在源中放置了 2 个大文件,总共 312 MB。将它们复制到 USB 2 闪存盘目标需要 42 秒。日志很好。

在此处输入图片描述

现在我再次运行该命令。它在 0 秒内完成,但仍记录了 2 个文件,统计数据显示已复制 2 个文件。我确信在 USB 2.0 闪存盘上有 312MB 数据的情况下这是不可能的。

在此处输入图片描述

答案1

我的 Windows 7 上的 Robocopy 版本是6.1.7601.23403

该版本的 Robocopy 是 2009 年发布的。它已经过时 10 年了。

我尝试将 Robocopy 从 Windows 10 (64) PC 复制到我的 Windows 7 (64),但当命令输入 .BAT 时,它会出错,指出它不是有效的 Win32 应用程序

不幸的是,Windows 7缺乏某些先决条件当前 Robocopy 可执行文件所必需的,因此最新的可执行文件不能简单地从 Windows 10 系统复制过来:

即使从 Windows 8 复制也行不通,因为底层组件必须支持它。

Robocopy 只是一个调用底层文件系统组件的实用程序。

在此处输入图片描述

我无法在具有最新版本的 Robocopy 的 Windows 10 1903 系统上重现此问题。

毫无疑问,问题出在日志上,而不是复制过程本身。Robocopy 实际上这正是它应该在这里做的,它只是错误地报告了它。

我们在这里看到的即时复制是不可能的。如果第一次将文件从一个卷复制到另一个卷需要 42 秒,那么同样的过程不能第二次只需0秒!

无论什么瓶颈限制了初始文件复制的速度,都会以完全相同的方式影响后续复制(即 USB 带宽和闪存驱动器写入速度)。

执行包含相对较大文件的复制作业并观察其耗时,然后从目标驱动器删除大文件并重新运行同一作业,即可轻松证明这一点。随后跨两个不同的大约需要相同的时间。

记录差异:

  • 绿色 = 真。

  • 红色 = 假。

在此处输入图片描述

为了澄清第一个绿色框中显示的内容:我添加了“没有 100% 新文件“行来显示日志中正确显示空白的地方。有这些文件副本真的发生后,每个成功复制的文件旁边都会显示“100%”和“新文件”。

这些文件复制从未发生过。原帖者可以将 20 GB 的数据放入其中,而 Robocopy 仍会报告即时传输!

结论:

由于 Windows 7 不能使用 2009 版以上的任何版本,因此 OP 将无法升级他的 Robocopy 版本。

他的直接选择是使用 XCOPY 或其他文件复制实用程序。

当 OP 最终升级到较新版本的 Windows(例如 Windows 10)时,他将拥有最新版本的 Robocopy,其中这个旧错误已被修补,并且这个日志记录故障将不再出现。

答案2

众所周知,Robocopy 在不同文件系统之间传输文件时会导致问题,例如由于 NTFS 是 64 位时间戳,ex fat 使用 3 个单独的字段来存储时间戳,其中一个字节表示 UTC 时间的时区。

并且有几个示例,其中摘要没有显示正确的信息例如这里。我猜想摘要计算(笼统地说)没有直接集成到复制过程中,因此存在某种错误。但我没有找到任何“官方”文件来验证这一点。您可能还想验证哪一个是正确的,日志还是摘要。

相关内容