移动大量文件（〜100000）

13

我使用包含许多文件的文件夹，例如每个文件夹100 000甚至1 000 000个文件。当我尝试将一个文件夹的内容移动到另一个文件夹时，我的计算机总是卡住。即使该过程似乎完成了，我也看不到任何文件夹的内容，因为nautilus似乎完全冻结了，因此我不得不强制计算机重新启动。我注意到当我尝试移动10 000个文件时也会发生这种情况。

这是我的计算机出现问题还是使用这些号码正常吗？

有执行此文件传输的明智方法吗？

nautilus transfer batch

— 海波龙
source

3

如何使用终端（cp -R SRC/ DEST/）

— UniversallyUniqueID

2

@BharadwajRaju：取决于文件cp -a可能更好，因为它保留了所有者，时间戳和权限。我还建议使用rsync，因为它可以验证传输并仅复制尚不存在的文件。

— 迈克尔

更新：（gvfs-copy从gvfs-bin程序包中）可以比更快cp。

— UniversallyUniqueID

您在这里有两个问题，而不是一个。请检查“ 如何询问”页面以获取指示。

— 路易斯·德索萨

19

或许可以考虑使用纯命令行方式来传输非常大量的文件，你肯定会发现的过程实质上比使用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打开有很多可能性，尤其是在移动如此大量文件时。很多很多的可能性...

潜在问题：

多亏以下评论者的这些想法，至少有两个潜在的陷阱值得思考：

您的目标目录可能已损坏，在随后无法访问的位置，键入错误等，mv仍会将文件移到那里！这里要小心...
如果缺少-t选项（--target-directory）并且目标文件夹实际上是一个文件，则您将移动一个文件，而其余文件则失败。mv有2个用途：将源重命名为目标或将源移至目录。再次小心...

— 安德鲁46
source

2

不会只是find . -maxdepth 1 -type f -exec mv -t test {} +做吗？

— muru

@muru：谢谢，我已经修剪到无关紧要的-name...部分，但我留xargs在原地。

— andrew.46 46

2

我不知道...尽管该命令显然是正确的，但我认为完整的动作太容易出错了。（如果你，比如，忘了包括-t标志？我想所有的文件将被“搬”到所谓的一个单一的文件test，造成除此之外的所有文件的损失）。我想我会喜欢的rsync，然后，如果一切顺利，请输入 rm。但是，我可以想象无法自动执行这种检查的情况。

— 乔斯

@Jos：谢谢，我添加了一个页脚注释，描述了这种可能性。很高兴看到一个rsync 示例写成答案？

— andrew.46

Linux支持极长的参数列表，因此您可以做到mv dir1/* dir2，并且仅find -exec在出现问题或需要避免将文件夹与glob匹配时才使用。（尽管取决于您的命名约定，通常*.*会匹配大多数文件，但不匹配大多数目录，因为通常有一个.extensionon文件，而没有一个.in目录名是常见的）

— Peter Cordes

4

我以前也有类似的经验，处理大量文件是正常的。我收集了大量的PDF数据表（电子零件）。

GUI工具会检查一些文件详细信息和元数据（图标/缩略图，大小等），在这种情况下将非常重要。即使在“ 图标视图”中且没有缩略图，它们也会冻结，因为其中大多数不是针对这种极端情况而设计的。GUI工具尝试为目录中的所有文件/文件夹加载演示文稿图标，即使那些项在当前屏幕部分中对用户不可见。排序也是问题的一部分，无法避免。

我最终根据品牌/型号（少于10000个）在单独的文件夹中拆分文件。也许您可以使用日期（就像大多数人一样使用照片/扫描件）或首字母（例如在Ubuntu软件包存储库中）
使用CLI工具会更容易，因为它们仅显示您的要求。您可以locate代替进行快速搜索find。
对于移动操作，请mv在终端中使用（GUI工具很慢，因为它们尝试定期更新视图）。

如果在同一分区中，该命令将仅更改文件系统索引中的指针。如果没有，那么它将是双重操作（复制和删除）。那将是昂贵的。

只有一种情况可以提供帮助：如果您要多次复制这些文件，并且它们不会更新。就像我与朋友分享收藏时一样，每次尝试复制都需要十年。（这仅对小文件更有用）

创建一个包或几个包，例如无/低压缩的zip。当您复制它时，它会更快，所以让DMA来完成它的工作。

— 用户名
source

3

如果您正在寻找一种解决方案，该解决方案可以兼顾GUI的感觉和灵活性，为您提供命令行操作的优势，那么我建议您使用mc（Midnight commander）。

它是一个基于ncurses的可视文件管理器-您可以在文件上看到两个窗格，并可以使用菜单。甚至可以通过ssh使用鼠标。您可以浏览fs，使用文件查看器检查文件，根据条件即时进行过滤，并在命令行上执行复制或移动操作。

它是DOS程序Norton Commander的克隆，后者在80年代中期很流行。每当GUI开始变得对我不可靠时，它都能很好地工作，并且非常适合您的目的。

— emk2203
source

0

我遇到了类似的问题-我正在测试我的RAID设置，并且在进行大量传输（例如一次性传输100,000+个文件和1-2 TB数据）时，传输似乎开始非常快-可以说〜200MB / sec，然后很快将速度减慢到大约90-120MB /秒的稳定水平（可能是在驱动器上消耗了一些闪存存储后）。然后，在20-30分钟后，操作逐渐开始下降到更低的水平，约30-40MB /秒，在处理小文件时情况更糟-将4-5小时的操作接近15小时。

我花了一些时间尝试诊断-例如可能的驱动器故障。尽管尝试使用其他工具（命令行，鹦鹉螺），但对于非常大的复制操作，我还是无法保持良好的吞吐量。

对我而言，最有效的方法是使用午夜指挥官，并且每当复制速度变慢时，我都会暂停操作，直到冲洗掉所有待处理的操作后硬盘驱动器指示灯熄灭为止（通常是一分钟左右），然后再次取消暂停MC，然后它会恢复正常的速度再持续20-30分钟。虽然有点烦人。

— 西尔
source