web-dev-qa-db-ja.com

「ln-L」(-logical)とは何ですか?

私はlnのmanページで読むことができます:

   -L, --logical
          make hard links to symbolic link references

どこかで、ln -Lファイルシステムを使用して、/procを使用して、削除されたがまだ開いているファイルを再リンクできることを読みました。例えば:

ln -L /proc/1234/fd/12 /tmp/my-file

しかし、私はENOENTを取得しています:そのようなファイルやディレクトリはありません。別のファイルシステムを試してみると、代わりに無効なクロスデバイスリンクが表示されます。

削除されたファイルを回復するためにln -Lを使用できない場合、それは何に使用できますか?

4
user36520

GNUユーティリティは、主にinfoページで文書化されています。から GNU ln情報ページ

‘-L’
‘--logical’
    If -s is not in effect, and the source file is a symbolic link,
    create the hard link to the file referred to by the symbolic link,
    rather than the symbolic link itself. 

したがって、これは単にソース引数として指定されたシンボリックリンクを逆参照します。

4
reinierpost

さて、もう少し初心者に優しい答え...

事前にいくつかの基本

UNIX/Linuxシステムでのファイルの保存方法に関する簡単なビューは次のとおりです。ls -lで表示される名前とiノード番号(lsで表示される場合があります)で構成されるディレクトリエントリがあります。 -i)。 iノードには、データがファイルシステムに保存されている実際の情報が含まれています(所有権、アクセス許可、必要に応じてさらに多くのiノードなど)。

(UTF-8を楽しむ時間... ;-))

シンプルなビュー:

┌─────────────────┐    ┌───────┐    ┌─────────────┐
│ directory entry │ ─► │ Inode │ ─► │ data blocks │
└─────────────────┘    └───────┘    └─────────────┘

次に、ハードリンクとシンボリックリンクの違いについて説明します。

ハードリンクは、既存のものと同じiノードを指す単なるディレクトリエントリですが、シンボリックリンクは、別のファイルの名前を含む特別なファイルです(パス名が十分に小さい場合は、iノード内に直接保存されます)。適合する)。これが理由です、理由

  • 同じファイルへのハードリンクは、異なるファイルアクセス許可を持つことはできません(これらはiノード内に保存されているため)
  • ハードリンクは同じファイルシステム内に存在する必要があります

拡大されたシンプルビュー

 ┌─────────────────┐   
 │    hard link    │ ───────┐
 └─────────────────┘        ▼
 ┌─────────────────┐    ┌───────┐    ┌─────────────┐
 │  example_file   │ ─► │ Inode │ ─► │ data blocks │
 └─────────────────┘    └───────┘    └─────────────┘
          ▲
          └───────────────────────┐
                                  │
 ┌─────────────────┐    ┌─────────┴──────────┐
 │  symbolic link  │ ─► │ filename reference │
 └─────────────────┘    └────────────────────┘

ここで、-Lがない-sオプションに戻ります。これにより、シンボリックリンクが指すファイルのハードリンクを作成できます。 (上記の例の「ハードリンク」のように)。

削除されたが、開いているプログラムによってまだ使用されているファイルを回復するのになぜそれが役立つのでしょうか?

これの動作は確かに実装に大きく依存し、マイレージはすべてのUNIX/Linuxプラットフォームで異なる可能性がありますが、どのように機能するかを説明しようと思いますcould

ファイルが削除されると(たとえばrm(1)を介して)、呼び出されるシステムコールは常にnlink(2)です。ディレクトリエントリを削除し、リンクカウンタ(iノード内に保持されている)を1つ減らします。

リンクカウンターがゼロに達した場合は、OSがクリーンアップする時間です(実際には、iノードが指すデータブロックを解放してから、iノード自体を解放します。[〜#〜] but [〜#〜]ファイルがまだ開いていない場合、このタスクは通常、iノードを使用するプログラムが終了するまで延期されます。

現在、ほとんどのUNIXシステムは/procファイルシステム階層を維持しており、開いているファイルへの参照を検索できます。これは(サプライズ!)シンボリックリンクです。正しいエントリが見つかった場合、ln -Lmay iノードへのリンクを再作成し、リンクカウンターを再度増やして、OSがiノードを削除しないようにします(幸運なユーザーが十分に速く、プログラムはまだ実行中です)。

注:これが機能するには、新しいリンクの場所が、元のリンクがあったファイルシステムと同じである必要があります。

最終例

 ┌─────────────────┐   
 │   rescue_link   │ ───────┐
 └─────────────────┘        ▼
 ┌─────────────────┐    ┌───────┐    ┌─────────────┐
 │ *** removed *** │    │ Inode │ ─► │ data blocks │
 └─────────────────┘    └───────┘    └─────────────┘
          ▲
          └───────────────────────┐
                                  │
 ┌─────────────────┐    ┌─────────┴──────────┐
 │ /proc/bla/fd/n  │ ─► │ filename reference │
 └─────────────────┘    └────────────────────┘

最後の言葉

リンクの正しい作成を妨げる可能性のあるものはたくさんあり、シンボリックリンク自体がどのように実装されているかに大きく依存していることを認めなければなりません:多くのUNIXバリアントで機能するかどうかは深刻な疑いがありますが、喜んでボランティアである可能性がありますこれをテストするために時間を費やすには?

6
ktf