总是复制和删除而不是移动会更好吗？

一般来说，当我意识到如果取消文件移动可能会导致目标或源不完整时，我会感到恐慌。此问题适用于Windows和基于Unix的平台。我永远都不记得在任何一种情况下，移动命令的工作原理。例如，如果您要移动目录；它会复制整个目录，然后再删除它，还是先复制然后再删除每个文件？

在输入类似的内容后mv verybigdir dest，我总是意识到我可能应该键入cp -R verybigdir dest  &&  rm -R verybigdir（&&操作员只有在第一个命令成功的情况下才继续执行下一个命令），或者这没有意义吗？确切地说，当我半按Ctrl+ 时会发生什么C？同样，当我按下“取消”按钮时，在Windows上会发生什么？

我无法计算移动某些东西的时间（上次是使用svn），并且有两个目录，目录内容是分开的。我猜答案很难，因为并非所有应用程序都以相同的方式移动文件组。

在Windows上，移动到相同的驱动器和分区将像Unix的mv命令一样操作，并重命名文件夹或更改其父文件夹。但是，如果要将其移动到另一个驱动程序或分区，它将逐个文件复制和删除文件，因此，为什么使用tar文件或zip文件而不进行压缩会更有效地在分区和硬盘驱动器之间更快地移动文件。如果要取消它，它只会停在原处。我相信对于Unix同样如此，但是我没有做足够的实验来确保100％肯定。只需更改索引节点即可，但是如果它位于另一个分区或驱动器上，则需要将其复制到该分区或驱动器上的扇区。如果您要在传输过程中取消它，它已经已经移动了一些文件，正在传输的文件将看到它。

更新：如果您要取消移动并想恢复移动，只需重新发出移动命令即可。它可能会警告您目标文件夹已经存在，但是文件不会被覆盖（除非它们在原始移动之前就已存在，或者在两个移动指令之间添加了），因为一旦它们被转移，它们就会从源（如果在其他分区或驱动器上）。

即使在完美稳定的计算机上也不会失败：如果您关心时间戳记，那mv总比简单地做得更好cp。

（cp -a将为您保留时间戳，并且我假设Windows上存在类似的东西）。

没有。

说明：

mv verybigdir dest

重命名verybigdir为dest。这是一个原子操作，即不能中途失败。

如果dest在另一台设备上，则mv将首先复制，然后删除旧版本。这不是原子操作。如果失败，则您在dest中可能只包含verybigdir的部分副本，但是verybigdir仍将是完整的。

是的，其他应用程序可能会以不同方式移动文件。

在Windows上，我总是复制和删除而不是移动。我曾经移动文件，而这是我第一次注意到记忆棒不足的地方。移动文件时，它停在了两者之间，并且出现错误，所以我检查了源文件夹，文件消失了，然后检查了目的地，并且文件损坏了。发生这种情况时，文件大小较大的文件更常见，其中大多数都是下载，花费了几个小时，因此id建议先复制然后删除。从一开始就节省时间，最后会有所回报。

在Unix上，在不跨越文件系统边界的移动中，mv不会复制数据：它只是更新各个目录中的inode数据库。这是很多快于cp大型文件。

此外，mv跨文件系统边界的使用只是默默地调用复制和删除机制。

所以我认为你应该更喜欢mv。

至少在Windows中，移动只是一种更加自动化的复制和删除。我相信mv会分别移动每个文件，这意味着^ c-ing不会丢失任何文件，您最终只会将文件分割在两个位置上-与Windows资源管理器不同，Windows资源管理器会在取消时取消移动所有内容。

我对此的解决方案是：除非我确定要移动它，否则请不要移动。

如果在源文件系统上而不是在目标文件系统上使用ACL，则Linux上的mv将复制源文件，然后-由于无法在目标文件上设置ACL-停止。因此，您最终都在两面都有文件。mv中的no开关不会阻止这种行为，因此在这种情况下，cp && rm是可取的。