検索しましたが、何も見つかりませんでした。 extファイルシステムは、シンボリックリンクのファイル構造（バイト単位）に関する詳細を探しています。
私はシンボリックリンクファイルを作成してからhexdumpそのシンボリックリンクを試してみましたが、ディレクトリ（フォルダを指すリンク）と文句を言ったので、リンク自体ではなくリンクが指すファイル/フォルダをダンプしようとしていたようです。
答え1
詳細は提供されていないので、この説明は現在Linux上の一般的なEXTファイルシステムに焦点を当てています。
たとえば、 が提供するシンボリックリンクの「サイズ」を見ると、ls -lサイズが指すターゲット名と同じくらい長いことがわかります。したがって、「実際の」ファイルにはリンク先へのパスだけがテキストとして含まれており、シンボリックリンクの解釈がファイルタイプメタデータ（特にリンクされたファイルS_IFLINKの inode フィールドにあるフラグ）i_modeに添付されて保存されるので推論できます。許可ビットも保存されます。このカーネルドキュメントリファレンス）。
i_blockパフォーマンスを向上させ、デバイスIOを減らすためにシンボリックリンクが60バイトより短い場合は、inode自体のフィールドに保存されます（参照：ここ）。これは別のブロックアクセスを必要としないので、これらのリンクを「クイックシンボリックリンク」と呼びます。これは、長いパスを指すシンボリックリンクとは異なり、外部データブロックのテキストでリンク先の「従来の」リポジトリに戻ります。 「方法。
答え2
それはすべてファイルシステムによって異なります。
通常、シンボリックリンクターゲットは、小さなディレクトリや小さなファイルなど、inodeブロックの追加スペースにそのまま保存されます。特別なデータ型は必要ありません。ファイルモードビットはすでにシンボリックリンクであると判断し、シンボリックリンクとして扱う必要があります。目標は「実際のコンテンツ」です。readlink -n /path/to | hexdump本当に使いたいのであれば使いますhexdump。
シンボリックリンクでlstat（2）が呼び出されると、ターゲットst.st_sizeの長さが含まれます（終了するNULバイトを除く）。
答え3
シンボリックリンクを使用すると、hexdumpext4ファイルシステムはまったく確認されません。これはアプリケーション指向の抽象化に焦点を当てています。このレベルでは見ることはありません。シンボリックリンクを開くと、パスチェックの意味に従って、そのリンクが参照するコンテンツを開く（no O_NOFOLLOW）または失敗（）を試みます。O_NOFOLLOWこの抽象化レイヤの内容を読み取る方法は、readlinkそれを生成するために渡されたバイトシーケンスを提供することです。symlinkこれは、ディスクにどのように表現されるかについては何も伝えません。
ディスク上の表現を調べるには、ブロックデバイスを開き（または開くツールを使用して）、表示するシンボリックリンクに到達するまでファイルシステム構造を調べる必要があります。私はext4が小さなコンテンツシンボリックリンクをinode構造（ディスクに別々のデータブロックなし）にインラインで保存し、大きなコンテンツをリンクコンテンツを含むファイルのように保存しますが、シンボリックリンクタイプだと思います。