*nix 文件系统中的文件几乎总是有一个关联的 inode 号。在大多数情况下，用户似乎不太关心这些索引节点号，因为他们使用文件名（即分层路径名-文件名结构）与文件交互。因此重命名文件名是经常发生的
mv oldname newname
从一个索引节点号重命名（重新分配）到另一个索引节点号是如何工作的？
背景是我想从我的文件系统备份（即恢复/编录）文件。在恢复时，我很高兴看到以前的 inode #7 再次成为幸运的 inode #7。
知道内核的文件系统处理可能会抽象 inode 的处理，我假设有时另一个文件在我想要分配给它的文件之前被赋予#7。简而言之，我预计当 #7 已经被占用时，“亲爱的内核将 inode #12345 更改为 #7”的决定会遇到麻烦。尽管与文件名相比，文件名也是唯一的，当想要将文件重命名为已使用的文件名时，我会这样做：
mv newname othername
mv oldname newname
通过上面的内容，我能够将文件oldfile重命名为 ，newname除了必须处理以前的情况外，还将以前的文件重命名newname为othername.
因此，我相信可能存在一种改变/影响 inode 编号的方法。在这种情况下，这将完美地回答这个问题。如果它在某种程度上依赖于文件系统，我最想知道 ext4 的情况。
更新
我的疏忽让我忽略了https://stackoverflow.com/questions/5752822/how-do-i-create-a-file-with-a-specific-inode-number这解决了大部分相同的问题。作为SO而不是Unix&Linux，我不确定将这个问题留在这里或删除它是否足够。但已经有一个答案了吗？
答案1
35年后，这个选项已不复存在。任何像样的文件系统都不会让你控制 inode 数量。
您可以做的是从 ufsrestore 解析恢复符号，但它是无文档的和二进制的。
Star 使用相同的基本算法来跟踪重命名并将数据库放入星型符号表中。该文件是一个文本文件，有程序 star_sym 将其转换为人类可读的形式。
因此，您可以获得的最好结果是从旧索引节点号到新索引节点号的转换表。
答案2
对于 ext4，debugfs可以以这种方式使用该工具
（应采取足够的预防措施，因为 debugfs 可能会损坏您的文件系统）
目标是在 inode 处创建一个77名为 的文件/lucky77。我们假设 inode77尚未使用/空闲/可用，文件名也是如此/lucky77。此外，我们在未安装的文件系统上离线工作。
debugfs -w /dev/ext4fsblockdev
debugfs 1.42 (29-Nov-2011)
debugfs: seti <77>
debugfs: sif <77> mode 0x81B6
debugfs: ln <77> luck77
debugfs: sif <77> links_count 1
debugfs: quit
如果索引节点已被使用，则需要执行额外的步骤来首先更改索引节点。在简单的情况下，制作文件的副本然后删除原始文件将释放文件名，因为副本使用了新的索引节点。无论如何，会发生更复杂的情况，例如目录的硬链接或索引节点或其他情况。在这些情况下，需要的不仅仅是简单的处理来释放所需的索引节点。
答案3
AFAIK，如果不复制文件的数据，就无法将一个索引节点复制到另一个索引节点。
也没有用于请求新文件具有特定索引节点号的 API。
因此，您所能做的就是cp -a old new && rm old为该文件获取一个新的索引节点，但您无法选择它是什么。当然，这会复制整个数据，因此速度很慢。
某些文件系统的 FS 特定转储/恢复工具可能会保留 inode 编号，但大多数不会。此类工具直接读取/写入块设备，而不是通过文件系统 API。 XFS：（xfsdump/xfsrestore有时）不保留 inode 编号。 （注意dumpe2fs仅打印信息；Linux ext2 dump 命令被称为dump.IDK 是否保留 inode 编号。）
保留/控制索引节点号通常不是一件有用的事情。没有系统调用来通过 inum 打开文件，甚至查找引用给定 inum 的文件名（除了遍历整个树）。 （FS 调试工具当然xfs_db可以通过 inum 读取块设备来获取文件。）
在某些情况下，inode 编号会在直接拥有它们的文件系统之外使用： NFS 使用作为文件句柄的索引节点号客户端和服务器之间。 XFS数据迁移使用它们将迁移到磁带的数据与 FS 上的文件进行匹配。显然，这就是您可能关心xfsdump/xfsrestore保留索引节点号的原因。