シンボリックリンクのターゲットが削除されると、それは何も指さず、削除されたターゲットのコンテンツに到達する方法がありません。
/proc/$PID/fd/
内のファイルはシンボリックリンクとして表示されますが、ここで説明するように、削除されたターゲットのコンテンツにアクセスできます。 削除されたLinuxファイルをlsof
。
それはどのように機能しますか?シンボリックリンクとして機能しないのに、なぜシンボリックリンクとして表示されるのですか?ファイルのiノードへの参照を保持するのはprocファイルシステムのシンボリックリンク実装ですか?
ターゲットが削除された場合、ls(1)
またはfile(1)
を使用すると、_/proc/$PID/fd/
_内のエンティティは壊れたシンボリックリンクとして表示されますが、open(2)
。
Debian 9では、strace(1)
を使用して、シンボリックリンクを読み取ろうとするとどうなるかを確認しました。コマンドは_Sudo strace cat "$symlink"
_です。 stderrからの関連行は
どちらかOK
_open("$symlink", O_RDONLY) = 3
_
またはENOENT
_open("$symlink", O_RDONLY) = -1 ENOENT (No such file or directory)
_
(注:これらがすべてopen(2)
の一般的な結果であると言っているわけではありません)。
結果:
_ | regular symlink | /proc/$PID/fd/$N |
---------------+-----------------+------------------+
exists, valid | OK | OK |
exists, broken | ENOENT | OK | <- the difference
doesn't exist | ENOENT | ENOENT |
---------------+-----------------+------------------+
_
また、_file "$symlink"
_を実行すると、lstat(2)
、readlink(2)
、およびstat(2)
が呼び出されることも学びました。これらは、ファイル記述子ではなく、パスに基づくシステムコールです。シンボリックリンクが存在する場合(有効または破損)、open(2)
が呼び出されてシンボリックリンクまたはそのターゲットが開かれることはありません。 stat(2)
のENOENT
は、リンクが壊れていることを示します。
私の結論は次のとおりです。「リンク切れ」は、いくつかのシステムコールの出力から派生したプロパティです。しかし、_/proc/$PID/fd/
_からリンクを開くと、open(2)
はそれをどう処理するかを知っているだけで、他のツールが何を生成するかは気にしません。
_/proc
_全体が「通常の」ファイルシステムのみを偽造していることに注意してください。いくつかの癖:
inotifywait
を試してください)。inotifywait
)。bash
を実行し、数分待ちます。 _ls -l /proc/$$/fd
_を呼び出して、ファイル記述子を確認します。おそらくctimesは「この瞬間」を表示します。ただし、コマンドを数秒ごとに繰り返すと、ctimesが変更されないことがわかります。 (雑学クイズ:最初はこの質問に答えることができましたが ファイルが開いている時間を確認してください with stat
と_/proc/$PID/fd/
_のシンボリックリンクですが、私は間違っていました。理由がわかりました)。あなたが尋ねるこれらのシンボリックリンクが、状況によっては通常のシンボリックリンクのように動作しないのも不思議ではありません。 _/proc
_全体は、動作が多少異なるように設計されています。 open(2)
は意図的にそれを利用する能力を与えられたと思います。