重命名一个巨大的文件夹：有风险吗？

使用该mv命令将文件夹重命名为180GB是否有风险？

我们有一个/data包含180GB 的文件夹。

我们要使用命令将/data文件夹重命名为。/BD_FILESmv

这样安全吗？

如果在同一文件系统中，更改文件夹名称是安全的。

如果它是一个挂载点（/data有点像对我来说可能是一个挂载点，请使用进行检查mount），那么您需要做的不只是简单的事情，mv因为mv /data /BD_FILES会将数据移动到根分区（可能不是这样）你想发生）。

您应该卸载文件系统，重命名现在为空的目录，/etc/fstab使用该文件系统的新位置进行更新，然后在重命名的位置重新安装文件系统。

换一种说法，

1. umount /data
2. mv /data /BD_FILES（假设/BD_FILES尚不存在，在这种情况下，请先将其移开）
3. 更新/etc/fstab，将挂载点从更改/data为/BD_FILES
4. mount /BD_FILES

这并不涉及复制任何文件，它只是更改充当文件系统安装点的目录的名称。

如果目录的重命名涉及将其移动到新的文件系统（例如，/data在一个磁盘上而/BD_FILES另一个磁盘上，则是常见的做法，例如，将内容移动到更大的分区上） ，建议您在保留原始数据的同时复制数据，直到您可以检查复制是否正常为止。你可以这样做

rsync -a /data/ /BD_FILES/

例如，但是请参见rsync手册以了解它的功能（例如，它不保留硬链接）。

重命名文件夹后，还需要确保现有过程（使用该文件夹的程序和用户，备份等）知道名称更改。

您不是要重命名目录中的每个文件，而是要重命名/中的一个文件。那是因为：

1. 目录是文件，并且
2. 文件系统真正关心的是索引节点，而不是实际的文本。

因此，无论目录中有多少文件或多少数据，重命名目录都是微不足道的。

如果仅重命名（同一文件系统中的源和目标），则它只是目录条目的重命名。它要么成功并且目录具有新名称，要么失败，在这种情况下没有任何变化^*。

如果源和目标位于不同的文件系统上，则需要使用复制数据mv。文件系统功能上的差异（例如最大文件大小，文件名限制等）可能会引起问题。为避免出现问题，请首先复制文件（cp，，rsync…），并在复制成功完成后，将文件移至原始位置。

_{*但是，有些极端情况，例如在man 2重命名的BUGS部分中提到的情况}

正如其他人所说，重命名文件夹不会对内容造成固有的风险。但是，您可能需要考虑另一种风险。

通过此更改，可能会破坏引用原始位置的现有过程，脚本，用户定义的快捷方式和配置，例如，如果路径存储在数据库中，则对其进行更新可能是一项艰巨的工作。

您可以做的一件事是为新目录名称建立符号链接，但将旧名称保留一段时间。这将使您有时间评估此更改的影响。您可以暂时删除旧名称，看看是否有问题，如果存在问题，只需重新创建旧名称，以便人们在确定需要更新的内容时继续工作。

像这样的命令应该做到这一点： ln -s /data /BD_FILES

重命名是原子的。唯一合理的风险是，mv由于某种原因决定复制所有内容，并且在整个过程中崩溃。如果您有GNU mv，mv -T将消除这种风险。

mv -T告诉mv它正在移动到非文件夹；mkdir()如果移动文件夹并且由于某种原因决定进行复制，则会导致它拒绝执行操作，进而导致它失败。

mv -T多年前，我参与了硕士论文的研究，摆脱了一些bug 。在很多情况下，它曾经做错了事。

另一方面，根分区上有180GB的用户数据。您可能确实希望将其移出根分区。