我使用的文件夹包含大量文件，例如每个文件夹包含 100 000 个甚至 1 000 000 个文件。当我尝试将一个文件夹的内容移动到另一个文件夹时，我的计算机总是卡住。即使该过程似乎已完成，我也看不到任何文件夹的内容，因为 nautilus 似乎完全冻结了，我不得不强制重新启动计算机。我注意到当我尝试移动 10 000 个文件时也会发生这种情况。
这是我的计算机的问题还是处理这些数字时是正常的？
有没有什么智能的方法可以执行此文件传输？
答案1
也许可以考虑使用纯命令行方法来传输大量文件，你无疑会发现这个过程是大幅比使用 GUI 更快。
有很多不同的方法可以实现这一点，但以下方法在我的系统上快速、安全且有效地运行：
find . -maxdepth 1 -type f -print0 | xargs -0 mv -t <destination>
此命令的一些解释：
- 您的输入目录是“。”字符，对于此特定命令，您需要位于该目录中
- 您的输出目录就是
<destination>我示例中的目录。显然，您可以根据自己的需要进行修改，并省略括号。 - 此语法允许文件名带有空格作为奖励:)
可以进行无限的排列，但这应该会很好，更加高效比 gui 更简单。例如，如果你想移动仅有的您可以运行的 pdf 文件：
find . -iname "*.pdf" -maxdepth 1 -type f -print0 | xargs -0 mv -t <destination>
使用xargs打开了许多可能性，特别是在移动如此大量的文件时。许多，许多可能性……
潜在问题：
至少有 2 个潜在的陷阱值得思考，感谢下面的评论者提出这些想法：
- 您的目标目录可能已损坏、位于无法访问的位置、输入错误等。
mv仍会将文件移动到那里！请小心…… - 如果缺少
-t选项（--target-directory）并且目标文件夹实际上是一个文件，那么您将移动一个文件而其余文件将失败。mv有 2 个用途：改名源到目的地或移动来源目录。再次小心……
答案2
我以前也有过类似的经历，处理大量文件时这很正常。我收集了大量 PDF 数据表（电子零件）。
GUI 工具检查一些文件详细信息和元数据（图标/缩略图、大小……），在这种情况下，这将是一个大问题。即使在图标视图如果没有缩略图，它们会冻结，因为它们中的大多数都不是为这种极端情况而设计的。GUI 工具尝试加载目录中所有文件/文件夹的演示图标，即使这些项目在当前屏幕部分对用户不可见。排序也是问题的一部分，并且没有办法避免。
- 我最终根据品牌/型号将文件拆分到单独的文件夹中，每个文件夹不超过 10000 个。也许您可以使用日期（大多数人处理照片/扫描件时都会这样做）或首字母（例如Ubuntu 软件包存储库）
- 使用 CLI 工具更方便，因为它们只显示您请求的内容。您可以使用
locate而不是 进行快速搜索find。 对于移动操作，请
mv在终端中使用（GUI 工具很慢，因为它们会尝试定期更新视图）。如果在同一个分区中，该命令将仅更改文件系统索引中的指针。如果不是，则将是双重操作（复制和删除）。这将是昂贵的。
我只可以在一种情况下提供帮助，那就是如果你多次复制这些文件，但它们没有更新。就像我与朋友分享我的收藏时一样，每次我尝试复制都要花十年时间。（这仅适用于小尺寸文件）
- 创建单个包或几个包，如不压缩或低压缩的 zip。复制时速度会更快，因此让直接接入做好其本职工作。
答案3
答案4
我遇到过类似的问题 - 我正在测试我的 RAID 设置，当进行大量传输时（例如一次传输 100,000 多个文件和 1-2 TB 数据），传输似乎开始相当快 - 比如说约 200MB/秒，然后迅速减慢到合理的稳定速度约 90-120MB/秒（可能是在驱动器上消耗了一些闪存缓存存储之后）。然后，在 20-30 分钟后，操作逐渐开始下降到更低的稳定速度约 30-40MB/秒，处理小文件时情况更糟 - 将 4-5 小时的操作缩短到接近 15 小时。
我花了一些时间尝试诊断 - 例如可能的驱动器故障。尽管尝试了不同的工具 - 命令行、nautilus，但我无法为非常大的复制操作保持良好的吞吐量。
对我来说最有效的方法是使用午夜指挥官，每当复制速度变慢时，我都会暂停操作，直到硬盘灯在任何待处理操作清除后熄灭 - 通常一分钟左右 - 然后再次取消暂停 MC，它会在接下来的 20-30 分钟内恢复到合适的速度。虽然相当烦人。