有时人们会删除不该删除的文件，而长时间运行的进程仍会打开该文件，通过 catting 恢复数据/proc/<pid>/fd/N还不够好。如果您可以通过运行 ln 的某个神奇选项来“撤消”删除，让您重新链接到 inode 编号（通过 lsof 恢复），那就太棒了。
我找不到任何 Linux 工具来执行此操作，至少通过粗略的 Google 搜索找不到。
您遇到了什么问题？服务器故障？
EDIT1：cat 文件/proc/<pid>/fd/N不够好的原因是因为仍然打开该文件的进程仍在写入它。删除会从文件系统命名空间中删除对 inode 的引用。我想要的是一种重新创建引用的方法。
EDIT2：“debugfs ln”有效，但风险太高，因为它会破坏原始文件系统数据。恢复的文件也非常不一致。链接数为零，我无法向其添加链接。这种方式更糟糕，因为我只能使用它来/proc/<pid>/fd/N访问数据而不会破坏我的文件系统。
答案1
如果您可以通过运行 ln 的某些神奇选项来“撤消”删除，这将使您重新链接到 inode 编号（通过 lsof 恢复），那就太棒了。
这种令人敬畏的东西被ln引入8.0版（GNU/coreutils）带有-L|--logical导致ln取消引用/proc/<pid>/fd/<handle>第一个的选项。因此，一个简单的
ln -L /proc/<pid>/fd/<handle> /path/to/deleted/file
足以重新链接已删除的文件。
答案2
听起来你已经理解了很多，所以我就不多说了。有几种方法可以找到 inode，通常你可以 cat 并重定向 STDOUT。你可以使用debugfs. 在以下位置运行此命令：
ln <$INODE> FILENAME
确保你有文件系统的备份。之后你可能需要运行 fsck。我成功地测试了这一点，一个 inode 仍在被写入，它确实可以创建一个指向取消引用的 inode 的新硬链接。
如果文件与 ext3 中未打开的文件解除链接，数据就会丢失。我不确定这是否始终正确，但我的大部分数据恢复经验都是在 ext2 上进行的。摘自 ext3 FAQ：
问：我如何从我的 ext3 分区恢复（取消删除）已删除的文件？实际上，你不能！这是开发人员之一 Andreas Dilger 对此的说法：
为了确保 ext3 能够在崩溃后安全地恢复取消链接，它实际上将 inode 中的块指针清零，而 ext2 只是在块位图中将这些块标记为未使用，并将 inode 标记为“已删除”，并保留块指针。
您唯一的希望就是“grep”出已被删除的文件部分并希望获得最好的结果。
这个问题里也有相关信息：
答案3
正如您所看到的，debugfs 方式实际上不起作用，最好的情况是您的档案会在重新启动后自动被删除（由于日志），最坏的情况是您可能会破坏您的文件系统，导致“重新启动死亡循环”。正确的解决方案 (TM) 是在 VFS 级别执行取消删除（这还具有与几乎所有当前 Linux 文件系统配合使用的额外好处）。系统调用方式 (flink) 每次出现在 LKML 中时都会被击落，因此最好的方法是通过模块 + ioctl。
实现这种方法并且代码相当小巧干净的项目是 fdlink (https://github.com/pkt/fdlink.git针对使用 ubuntu maverick 内核测试的版本）。有了它，在您插入模块（sudo insmod flink_dev.ko）后，您只需执行“./flinkapp /proc//fd/X /my/link/path”，它就会执行您想要的操作。
您还可以使用 vfs-undelete.sourceforge.net 的前向移植版本，它也可以工作（并且也可以自动重新链接到原始名称），但是 fdlink 的代码更简单并且工作得同样好，所以它是我的首选。
答案4
我不知道如何做你到底想做的事，但我会做的是：
- 从另一个进程打开文件 RO
- 等待原进程退出
- 将数据从打开的 FD 复制到文件
显然，这不是理想的选择，但有可能。另一种选择是尝试使用 debugfs（使用命令link），但这在生产机器上有点可怕！