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

Question

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

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

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

这样做安全吗？

Answer 1

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

如果是一个挂载点（/data还挺看起来像它可能是一个挂载点给我，看看这个用mount），那么你需要做其他的东西不仅仅是一个简单的mv，因为mv /data /BD_FILES将数据移动到根分区（这可能不是什么你想发生）。

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

换句话说，

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

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

rsync -a /data/ /BD_FILES/

例如，但请参阅rsync手册了解它的作用和不做什么（例如，它不保留硬链接）。

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

人们期望 `mv` 只执行一个 `rename` 系统调用是有风险的，但由于情况人们没有意识到它会复制文件并删除原始文件。如果我需要绝对确定只进行了一个 `rename` 系统调用并且 `mv` 不会在我背后做一些“聪明”的事情，我会打开一个 Python shell 并使用 `os.rename`。 (9认同)
使用相对较新的 Linux 内核，您可以改为移动挂载点：`mkdir /BD_FILES && mount -M /data /BD_FILES && rmdir /data` (3认同)
@MichealJohnson One 显然使用了人们最习惯使用的工具。是的，`rsync -a` 保留了几乎所有元数据，但不保留硬链接、ACL 或扩展属性（为此添加 `-HAX`）。 (3认同)
@Max 不同的发行版具有不同行为的不同“重命名”命令。我认为当你想确定它要做什么时，这就是不使用 `rename` 命令的充分理由。 (3认同)
@MichealJohnson 这可能适用于 Linux 系统，是的。`rsync` 的优点是它可以重新启动。 (2认同)

Answer 2

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

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

Answer 3

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

如果源和目标位于不同的文件系统上，则数据需要通过mv. 文件系统功能的差异，例如最大文件大小、文件名限制等，可能会导致问题。为避免出现问题，请先复制文件 ( cp, rsync, ...)，然后在复制成功完成后，删除原始位置中的文件。

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

Answer 4

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

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

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

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

另一个尚未有人提及的轻微风险是，根据您对该文件夹的备份策略，它可能会导致备份驱动器上的磁盘空间和延迟问题，因为 180GB 的“新”数据突然出现，并且需要被备份。 (4认同)