我做了一个很大的哎呀，但文件仍在打开并正在使用中。
关注（Link to a specific inode），
从/proc/###/fd/###复制到新文件是没有用的，因为：
我正在尝试将其重新链接到文件系统（取消删除它）。
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，我还没有测试过。
答案 0 :(得分：2)
我知道的最好方法是使用gdb并附加到仍然打开文件的进程，然后从gdb内部手动调用库函数以打开新文件并复制文件内容到新文件。
答案 1 :(得分：1)
花了一点时间弄清楚你在问什么。
我知道没有用户登陆API来执行此操作。能够创建一个带有打开文件描述符的链接会很好，当然，如果文件描述符不在磁盘上或者新路径与该文件不在同一个磁盘上，那么它会失败，但是我不知道那样的事情。
部分原因是实际上文件不再需要实际存在于磁盘上。它可以完全（或部分）存在于文件系统的缓存中。操作系统可能决定不将对该文件的更改刷新到磁盘，因为它可能认为这样做无关紧要（除非它需要释放一些RAM）。
答案 2 :(得分：1)
由于安全原因，你想要的系统调用 - 想法 - 将文件描述符链接到一个新名称 - 在过去被提出并被拒绝了几次（LKML上的讨论弹出）：如果文件被删除那么它被删除，期间。 （见下面的Edit1。）
许多面向安全的应用程序依赖于他们删除文件的行为，但是文件描述符保持打开状态，不能再次重新打开。为实现这一目标，一方面/proc/*/fd/*链接上的权限过于严格（只有所有者才能阅读），另一方面则缺少系统调用。
我试图取消删除它。
1.文件正在改变
2. 40G和磁盘已满
你运气不好。您不能为已删除（尚未打开）的文件指定新名称。学习使用rm -i（我讨厌默认的RedHat别名用于root shell，但最终学会了爱它们。）
Edit1 通过@ephemient对此处的其他回复进行评论，拉出我懒得自己查看的推荐信息：
用户土地API在Linux世界中被提出过几次并被击落;理由是与安全相关，而不是与文件系统磁盘格式相关。 lkml.org/lkml/1998/3/8/1 lkml.org/lkml/2002/1/19/16 lkml.org/lkml/2003/4/6/112等。
答案 3 :(得分：0)
它不是基本内核的一部分，但是有一个模块http://fdlink.svn.sourceforge.net/viewvc/fdlink/trunk/flink/应该这样做。我认为使用debugfs更容易，但内核mod可能更清晰。