我一直在备份脚本中使用 xcopy，但 xcopy 时常会失败，并显示“内存不足“当路径名潜入超过 254 个字符的备份集时。网络上有很多建议说 xcopy 已被 robocopy 弃用，并建议改用 robocopy。
我改用了 robocopy，它运行良好，但运行速度明显变慢。这些是大型备份集，xcopy 版本运行了 6 个小时，这对于一夜之间来说还算可以。但 robocopy 版本运行了 11 个小时，这意味着它第二天早上还在运行！有没有办法加快 robocopy 的速度，或者有没有办法强制 xcopy 忽略长文件名并继续运行？以下是新旧示例代码：
xcopy S:\SharedFiles E:\NAS\SharedFiles /c /f /i /s /e /k /r /h /y /d /j 1>> C:\utilities\alloutput.txt 2>&1
robocopy S:\SharedFiles E:\NAS\SharedFiles /e /j /np /fp /r:1 /w:1 1>> C:\utilities\alloutput.txt 2>&1
注意：我在 xcopy 中使用了 /C 选项，但这似乎并不能阻止 xcopy 在遇到长路径名时立即结束。
编辑我更新了我的脚本来做/r:1 /w:1。在我的测试运行中，有 78 个错误需要重试。这略有改善，但仍然比 xcopy 版本慢得多。我也尝试过有和没有/J，没有明显的改进。我没有尝试设置线程限制，但据我所知，xcopy 无论如何都是单线程的，而 robocopy 默认为 8。
答案1
通常，Robocopy 是更快的替代方案在多数情况下然而，最显著的区别是 robocopy 有一个重试选项，而 xcopy 不会在发生错误时重试。
为了验证这一点，请使用开关r:0代替r:1（w:0以确保安全，但这不应该有任何区别）。
除此之外，我还知道以下绩效开关：
/COMPRESS : Request SMB network compression during file transfer, if applicable.
/J : Copy using unbuffered I/O (recommended for large files).
/NOOFFLOAD : Copy files without using the Windows Copy Offload mechanism.
/IPG:n : Inter-Packet Gap (ms), to free bandwidth on slow lines.
/MT[:n] : Multithreaded copying, n = no. of threads to use (1-128)
default = 8 threads, not compatible with /IPG and /EFSRAW
Redirecting output using /LOG is recommended for even better performance.
根据您的具体情况，专门关闭/打开它们会有所帮助（在您的情况下 - 使用/j实际上是否有区别？）。
答案2
在思考了我之前的答案之后，我发现在添加 /MT 标志时输出和执行时间的结果有所不同，我开始认为也许你的 robocopy OUTPUT 可能是罪魁祸首。
我测试了这两个 robocopy 命令：
robocopy vbs vbs2 /e /j /np /fp /r:1 /w:1 1>> alloutput2.txt 2>&1
robocopy vbs vbs2 /e /j /np /fp /NC /NS /MT:16 /r:1 /w:1 1>> alloutput.txt 2>&1
第一个命令的执行时间约为 9 秒，用于复制总大小为 660MB 的 12k 文件。第二个命令的执行时间约为 2.7 秒。
输出也有点不同。第一个命令将输出以下内容：
New File 3056 C:\git\vbs\.editorconfig
第二个只会输出文件名：
C:\git\vbs\.editorconfig
我建议您尝试一下，并将 MT 增加到 16，因为您的 CPU 可以使用它。