好的，前段时间我发现了 nautilus 中似乎存在的一个错误。
/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 的文件？
还有一个附加问题：这是 nautilus 的预期行为吗，或者是一个错误？
为什么会发生这种情况，这是一个很长的故事，但我的目录中有一些非常重要（且机密）的文件，我想找回它们
答案1
不确定这是否可行。毕竟，您所有的可用空间都是 inode 列表。
然而看到孤立文件ext4 的特性。
答案2
我会发布我的答案，但我不会接受它，因为它似乎不是一个好的答案（至少在效率或完整性方面）。
这需要一个程序（我用 C 语言编写）递归遍历整个目录树，将每个引用的 inode 注册到有序列表中（避免重复），然后将其与实际的 inode 列表进行比较。
不同之处在于缺少文件