我知道 Windows 复制对话框（在 Windows XP 中）首先将副本存储在内存中，并且在对话框关闭后仍在复制，因此时间不对，但为什么复制所需时间的估计如此不准确，即使已禁用内存复制（在 Vista 和 Windows 7 中）？这似乎太武断了！整个复制过程是如何工作的？为什么 Windows 无法正确估计它？
答案1
简而言之：糟糕的算法和跳跃估计实际上是一个实施弱点。
其他工具如泰拉复制做得更好。我认为没有必要解释为什么他们的实施不好。他们会注意到这一点并会改进。
困难之处：
- 您必须考虑资源波动（主要是 CPU/网络带宽/HDD 速度）
- 您需要通过预测行为（Windows 文件复制现在确实表现不佳）来推断所需的时间。
- 随着时间的推移对您最初的估计进行调整（我的意思是进行小幅调整，而不是像上面有趣的图片那样！）
为此，不仅字节数，而且要创建的文件数量也起着重要作用。如果您有一百万个 1KB 文件或一千个 1MB 文件，情况将大不相同，因为前者需要创建许多文件。根据所使用的文件系统，这可能比实际传输数据花费更多时间。
这个对话也让我抓狂了好几次：
- 在较旧的 WinNT 系统上，如果您要复制大量小文件，它会显示每个文件的名称和漂亮的动画，从而减慢整个过程的速度，甚至无法使用。
现代的 Windows 复制功能也好不到哪里去：
- 为了计算要传输的数据量，它似乎首先进行查找（这就是我认为它所做的），因此如果您选择多个目录，则需要很长时间才能有效地开始执行工作。
- 一些内置超时会阻止复制大文件（在我的系统上大约 60GB）。麻烦的是，它会告诉你，在网络上复制了超过 30GB 的文件后，这会浪费带宽和时间，因为你必须从头开始重新启动！
- 由于某种原因，将文件从一台计算机复制到另一台计算机的速度非常慢。（我的意思是与可用的网络带宽相比，使用其他工具速度更快，所以这不是计算限制。）
答案2
Raymond Chen 曾经写过一篇关于此的非常好的文章。基本上，对话只是猜测 :)。
https://devblogs.microsoft.com/oldnewthing/20040106-00/?p=41193
“因为复制对话只是猜测。它无法预测未来，但不得不尝试。而且在复制的开始阶段，当几乎没有历史可参考时，预测可能会非常糟糕。
打个比方：假设有人告诉你，“我要数到 100，你需要连续估计我什么时候能数完。”他们开始数，“一、二、三……”。你注意到他们每秒数一个数，所以你估计需要 100 秒。哎呀，现在他们数得慢了。“四……五……”现在你必须将估计时间改为 200 秒。现在他们数得快了：“六七八九”你必须再次更新你的估计时间。
现在，那些只听你估计而不听计数的人会认为你疯了。你的估计时间从 100 秒变成了 200 秒，又变成了 50 秒；你有什么问题？你为什么不能给出一个好的估计？
文件复制也是一样。shell 知道要复制多少个文件和多少字节，但它不知道硬盘、网络或互联网的速度有多快，所以它只能猜测。如果复制吞吐量发生变化，则估算值需要更改以将新的传输速率考虑在内。
答案3
我要数到十，1....2....3....4要数到 10 需要多少个点？
5.6.7那现在呢？您是否考虑了数字之间所有过去的点并取平均值，是否只取最后 4 个间隔并使用该平均值，是否只查看最后一个间隔？
您在文件传输方面也遇到了同样的问题。文件传输的速度并不是恒定的，它会根据很多因素而加快或减慢。数字如此跳跃的原因是微软倾向于“仅计算最后一个间隔”这一方面。
频谱的这一侧没有任何问题，它为您提供更准确的“每秒秒数”（实时的一秒使计数器减少一秒）但这会导致计时器的总 ETA 大幅跳跃。
相反的一个很好的例子是7-Zip压缩时。如果压缩速度在处理过程中下降，您可以看到 ETA 不会像文件传输 ETA 那样急剧跳跃，但计时器可能需要 2 到 3 秒才能倒计时一秒（或者甚至可能开始计时）直到它稳定在新的速度。
答案4
为什么复制对话框会给出如此可怕的估计？
因为复制对话只是猜测。它无法预测未来，但不得不尝试。而且在复制的开始阶段，当几乎没有历史可参考时，预测可能会非常糟糕。
打个比方：假设有人告诉你，“我要数到 100，你需要连续估计我什么时候能数完。”他们开始数，“一、二、三……”。你注意到他们每秒数一个数，所以你估计需要 100 秒。哎呀，现在他们数得慢了。“四……五……”现在你必须将估计时间改为 200 秒。现在他们数得快了：“六七八九”。你必须再次更新你的估计时间。
这博客文章上面引用的对这个问题进行了长时间的讨论，并提出了一些有趣的评论。
陈雷蒙德是一位传奇人物，“微软的查克·诺里斯”，我想你不会得到更权威的答案了。我相信他至少看过有问题的代码。