開いているファイルハンドルは、死んだときにどこに行きますか？

ファイルハンドルを開いている間に削除されたファイルはどうなりますか？

MPlayerでの再生中にビデオファイルを削除でき、最後まで再生されることがわかったので、これを不思議に思っていました。データの取得元はどこですか？それはまだハードドライブから来ていますか？ファイルを削除すると、RAMにコピーされましたか？

まだハードドライブ上にある場合、プログラムが基本的に未割り当ての領域から読み取りを実行しているときにファイルシステムをいっぱいにするとどうなりますか？RAMにバッファされている場合、バッファをフラッシュするとどうなりますか？

ファイルがNFS共有にあった場合はどうなりますか？サーバーに保存されていますか？（それはセキュリティリスクではありません。大量のリモートファイルハンドルによるDoSですか？）

やってlsof -n |grep '(deleted)'時々興味深い結果が得られます。共有ライブラリファイルをスワップアウトするパッケージをアップグレードする場合、それらのライブラリを使用していたプログラムを実行しても、何も変更されていないかのように使用できます。

ボーナスの質問：この状況でデータを死者から取り戻す方法はありますか？

iノードへのハードリンクはもう存在しませんが、iノードはディスク上に残ります。ファイル記述子が閉じられると、それらは削除されます。それまでは、ファイル名/ハードリンクを必要とする操作を除いて、ファイルを通常どおり変更できます。

debugfs 同様のツールを使用して、iノードの内容を回復できます。

カーネルは、iノードへの参照を参照して参照します。私の答えを参照するときに近いI（）ファイルディスクリプタどうなりますか？。

開いているファイルを削除することは、単にファイルを開くことよりもDOSメカニズムとして効果的ではないでしょう。ulimit開いているファイルには、このDOSの試みに対するいくつかの保護を提供します。削除されているかどうかに関係なく、開いているすべてのファイルに適用されます。

ファイルは、ファイルシステムへのすべての参照が消えると、ファイルシステム上でのみ消去されます。名前と開いているハンドルの両方が参照としてカウントされます。ほとんどのシステムではファイルの名前を再作成することはできませんが、ファイルがプログラムで開いている限り削除されません。

データはまだドライブにありますが、ファイルにはリンクカウントが0としてマークされます。システムがクラッシュした場合、次の再起動時にfsckはデータを削除する必要があることを認識します。これは、削除されていないファイルよりもサービス拒否につながることはありません。

私が知っている限り、ストックLinuxシステム上のファイルへのリンクを再作成することはできません（ファイルシステムドライバーをバイパスする、debugfsまたは同様の方法を除く）が、内容を簡単に回復できます：cat /proc/12345/fd/4212345はファイルを開いているプロセスIDです42はファイル記述子番号です。

NFSで、クライアントでまだ開いているファイルを削除すると、NFSサーバーはサーバー上のファイルの名前を変更しますが、すべてのクライアントがファイルを解放するまで削除しません。私の経験では、新しい名前はですが.nfs…、すべてのNFS実装で同じ名前であるかどうかはわかりません。