如何查找其inode未被任何目录引用的文件

Question

好的，前段时间我发现了 nautilus 中的一个 bug。

/tmp$ mkdir test/
/tmp$ mkdir test2/
/tmp$ echo "very important stuff" > test/important-file.txt
/tmp$ ln -s /tmp/test/ test2/test

如果您尝试mv test2/test .bash 足够聪明来回答：

mv: «test2/test» and «./test» identify the same file

我在另一个位置创建了一个符号链接来测试（一个包含文件的目录），然后我将符号链接移动到目录所在的位置

但是，鹦鹉螺进入游戏：

Nautilus 知道符号链接是一个目录，它好心地让我合并它们：

现在，我合并了它们（我显然认为这是两个不同的目录）。结果……

tmp$ ls -la
lrwxrwxrwx  1 cool-user  best-group-ever      9 août  26 23:51 test -> /tmp/test

好的。所以我丢失了我的目录（这是正常的，因为我覆盖了它）并最终得到了一个无用的循环符号链接，但是......我的important-file.txt? 它有一个 inode，它不再被我系统中的任何目录引用。

显然，我没有在便利贴中写那个 inode ......那么，它在哪里？。有没有办法找到每个文件都没有被任何目录引用的inode？

作为一个额外的问题：这是鹦鹉螺的预期行为，还是一个错误？

为什么以及如何发生在我身上是一个很长的故事，但我的目录中有一些非常重要（和机密）的文件，我想取回

Answer 1

不确定这是否可能。毕竟，您的所有可用空间都是索引节点列表。

不过请参阅ext4 的孤立文件功能。

Answer 2

我将发布我的答案，但我不接受它，因为它似乎在任何意义上都不是一个好的答案（至少在效率或完整性方面）。

这需要一个程序（我用 C 语言编写）来递归地遍历整个目录树，将每个引用的 inode 注册到有序列表中（避免重复），然后将其与实际的 inode 列表进行比较。

区别在于缺少文件

检查取消链接系统调用手册页（man 2 unlink）。不管怎样——找到了问题的根源。冲突对话框将源视为文件夹并显示合并选项，但负责执行复制/移动的代码将其视为文件。也合并内部=覆盖。因此，通过单击合并，目标文件夹将被递归删除（使用remove_target_recursively），并且新文件将取代它。对于文件夹的每个链接都是这种情况。即每个名为“test”的文件夹的链接都会覆盖任何名为“test”的文件夹。 (2认同)