哪些 api 可用于创建指向 ext2/3 上现有 inode 的硬链接答案

【问题标题】：what api can be used to create a hard link to an existing inode on ext2/3哪些 api 可用于创建指向 ext2/3 上现有 inode 的硬链接
【发布时间】：2010-09-17 18:03:59
【问题描述】：

我做了一个很糟糕的事情，但文件仍然打开并正在使用中。

关注 (Link to a specific inode), 从/proc/###/fd/### 复制到新文件没有用，因为：

文件正在更改
文件大小为 40G，磁盘已满（150MB 可用）

我正在尝试将它重新链接到文件系统（取消删除它）。

    COMMAND    PID    USER   FD      TYPE             DEVICE        SIZE       NODE NAME
vmware-vm 4281    root  126u      REG              253,0 40020664320   10928132 /var/mnt/partial.img

我用“wc /proc/4281/fd/126”打开文件，然后暂停它。

我使用 debugfs（灵感来自 dag wieers）在文件系统上创建了一个链接，然后编辑了目录条目以将删除时间设置为 0，更新链接计数。重启并运行 fsck 一切正常。

This is a kernel mod to do it，我还没测试。

【问题讨论】：

释放一些空间以便您可以复制它。
为什么会这样？这是 ServerFault 的理想选择 - 管理员可能知道更多技巧。
我完成了使用 debugfs 将其重新链接到文件系统的任务。
内容再次发生变化，副本将过期。

标签： c linux filesystems

【解决方案1】：

我知道的最好方法是使用gdb 并附加到仍然打开文件的进程，然后从gdb 内部手动调用库函数来打开一个新文件并将文件内容复制到新文件中.

【讨论】：

【解决方案2】：

花了一点时间才弄清楚你在问什么。

据我所知，没有用户区 API 可以执行此操作。能够创建一个带有打开文件描述符的链接会很好，当然，如果文件描述符不在磁盘上，或者如果新路径与该文件不在同一个磁盘上，这将失败，但我不知道这样的事情。

造成这种情况的部分原因是，实际上文件不再需要实际位于磁盘上。它可以完全（或部分）存在于文件系统的缓存中。操作系统可以决定不将该文件的更改刷新到磁盘，因为它可能认为这样做无关紧要（除非它需要释放一些 RAM）。

【讨论】：

我不相信第 3 段，但我同意“无用户区 API”部分。
@Jonathan Leffler：你说得对，这实际上可能不是没有系统调用的原因（现在我想它可能实际上是相反的）我确实认为除非在休眠的情况下，否则不将未链接的文件刷新到磁盘对于操作系统来说是合理的行为。
我同意数据可能不会被刷新到磁盘（并且系统可能会尽量避免这样做） - 但是如果缓冲池需要空间，系统仍然可以将其写入磁盘。 inode 的存在是为了存储相关信息，并且会在将块添加到文件等时准确维护。只是没有引用 inode 的目录条目。
inode(s) 只是文件的另一块，并且最有可能不会在磁盘上更新。在这种情况下，它实际上没有对它的磁盘引用（除非文件增长并且添加了新块并且索引节点的磁盘版本没有更新以反映这一点）。
一个用户态API在Linux世界中被提出过几次；理由是与安全相关的，而不是与文件系统磁盘格式相关的。 lkml.org/lkml/1998/3/8/1 lkml.org/lkml/2002/1/19/16 lkml.org/lkml/2003/4/6/112等。

【解决方案3】：

您想要的系统调用，想法 - 将文件描述符链接到新名称 - 由于安全原因，过去曾多次提出并拒绝（LKML 上一次又一次弹出讨论）：如果文件被删除，那么它已删除，期间。（请参阅下面的编辑 1。）

许多面向安全的应用程序依赖于他们删除的文件但他们保持文件描述符打开的行为，不能再次重新打开。要做到这一点，一方面是对/proc/*/fd/* 链接的权限过于严格（只有所有者只能读取），另一方面是缺少系统调用。

我正在尝试取消删除它。
1.文件在变化
2. 40G，磁盘已满

你运气不好。您不能为已删除（尚未打开）的文件指定新名称。学习使用rm -i（我讨厌 RedHat 的 root shell 默认别名，但最终学会了喜欢它们）。

Edit1 在这里评论@ephemient 的另一个回复，拉出我自己懒得查的参考：

在 Linux 世界中，一个用户级 API 曾被提出并被击落数次；理由是与安全相关的，而不是与文件系统磁盘格式相关的。 lkml.org/lkml/1998/3/8/1 lkml.org/lkml/2002/1/19/16 lkml.org/lkml/2003/4/6/112 等。

【讨论】：

安全方面，如果 root 可以运行 debugfs 和/或安装内核模块，那么限制为 root 的用户空间选项还会有什么安全问题？
@Jason：在 Linux 中，“root”本身不再存在。它只是启用每个capability 的用户。使用内核选项可以禁用可加载模块（我听说这是增强安全性安装的常用做法） - 但不是文件系统实现的系统调用。很快，潜在的安全问题就超过了系统调用带来的好处。

【解决方案4】：

它不是基本内核的一部分，但有一个模块http://fdlink.svn.sourceforge.net/viewvc/fdlink/trunk/flink/ 应该可以做到这一点。我认为使用 debugfs 更容易，但内核模块可能更干净。

【讨论】：