打开文件句柄后删除的文件会发生什么情况？
自从发现可以在MPlayer中播放视频文件并将其一直播放到最后时，我一直在想这个问题。它从哪里提取数据？它仍然来自硬盘吗？删除文件后，文件是否已复制到RAM？
如果它仍在硬盘驱动器上，那么当程序运行时从本质上未分配的空间读取内容时，如果我填满文件系统会发生什么情况？如果将其缓冲在RAM中，则刷新缓冲区会怎样？
如果该文件位于NFS共享上，该怎么办–它存储在服务器上吗？（这不是安全隐患吗？DoS通过大量打开的远程文件句柄进行DoS吗？）
做一个lsof -n |grep '(deleted)'有时产生有趣的结果; 如果我要升级换出共享库文件的程序包，则运行已在使用这些库的程序仍然可以使用它们，就好像什么都没有改变一样。
额外的问题：在这种情况下，有什么方法可以使数据从死角中恢复过来吗？
Answers:
尽管不再存在与索引节点的硬链接，但索引节点仍保留在磁盘上。关闭文件描述符后，它们将被删除。在此之前，可以按常规修改文件，禁止需要文件名/硬链接的操作。
debugfs 可以使用类似的工具来恢复索引节点的内容。
/proc是特定于Linux的（和一样debugfs）。
/proc。硬链接仅在相同的文件系统上起作用，而不能在整个文件系统上起作用，并且由于/proc是单独的不可写文件系统，因此您不能在其上创建硬链接。您可以将文件复制掉/proc。
内核会根据对索引节点的引用进行引用计数。请参阅我的答案，当我关闭文件描述符时会发生什么？。
删除打开的文件可能不会比仅打开文件更有效的DOS机制。在ulimit上打开的文件提供了对这个DOS尝试一些保护。它适用于所有打开的文件（是否已删除）。
仅在对文件的所有引用消失后，才会在文件系统上擦除该文件。名称和打开句柄均视为引用。只要在程序中打开该文件，就不会删除该文件，尽管大多数系统不允许您为其重新创建名称。
数据仍在驱动器上，但是该文件被标记为链接计数为0。如果系统崩溃，则下次重新启动时fsck知道必须删除数据。与未删除的文件相比，这不会导致拒绝服务。
据我所知，您无法在现有的Linux系统上重新创建文件的链接（短于使用debugfs或类似方法绕过文件系统驱动程序），但是您可以轻松地恢复内容：cat /proc/12345/fd/42其中12345是打开文件的进程ID 42是文件描述符号。
通过NFS，当您删除仍在某些客户端中打开的文件时，NFS服务器会在服务器上重命名该文件，但是直到所有客户端都释放该文件后，它才会删除。以我的经验，新名称是.nfs…，尽管我不知道该名称在所有NFS实现中是否都相同。