自己リンクと親リンク（。および..）をディレクトリエントリに保存する理由

階層型ディレクトリ構造にファイルを保存する以外の機能を持たない一部の組み込みデバイスを対象としたファイルシステムについて考えてみます。このファイルシステムには、UNIXやWindowsなどのシステムで使用できる多くの操作がありません（たとえば、アクセス許可は完全に異なり、ディレクトリに格納されているメタデータに関連付けられていません）。このファイルシステムでは、ハードリンクやソフトリンクの種類を許可しないため、すべてのファイルには厳密なツリー構造で一意の名前が付けられます。

ディレクトリ自体とその親へのリンクを、ディレクトリを表すディスク上のデータ構造に格納することにはメリットがありますか？

ほとんどのunixファイルシステムは.、..ディスク上にエントリを持っています。なぜVFS（汎用ファイルシステムドライバー）レイヤーでそれらを処理しないのでしょうか。これは歴史的な遺物ですか？正当な理由はありますか？そうであれば、正確に、それが私の組み込みシステムに関連しているかどうかを判断できますか？

親ディレクトリへのリンクがあることは、私には理にかなっています。ディレクトリがない場合は、常にディレクトリのリスト全体を操作する必要があります。したがって、たとえば、/home/svick/Documents/として表現する必要があります{ /, /home/, /home/svick/, /home/svick/Documents }。そうしないと、親ディレクトリをまったく見つけることができません（または、非常に高価になります）。これは非効率的であるだけでなく、危険でもあります。重複するそのようなリストが2つある場合、ディレクトリを移動すると、簡単に同期が外れる可能性があります。

一方、親ディレクトリへの参照がある場合は、より効率的で安全です。

現在のディレクトリへのリンクを実際に設定する理由はありません。あるディレクトリを表す構造があり、そのディレクトリにアクセスしたい場合、使用.は常に完全に不要です。そのため、.リンクは実際にはファイルシステム構造に存在せず、仮想のみであると想定します。

特別なケースが少なくなります。多くの状況で、VFSは他のディレクトリ名を処理するため、「..」を処理する場合があります。

私が想像できる唯一の理由は、次のシナリオです。

1. ファイルシステムの元の実装は同じディレクトリ形式で存在していましたが、ファイルパスとサブディレクトリの概念は当時考慮されていませんでした（PDP-7 Unixファイルシステムを参照）。

2. 次に、パスの解決とサブディレクトリが役立つと人々は考えました！

3. 古い実装とのある程度の下位互換性を維持するために、.および..は、他のディレクトリと同じようにディスクに格納されることが決定されました。

では、40年前のソフトウェアとの下位互換性のためだけに、それらの役に立たないアーティファクトが残っているのではないでしょうか。信頼できるシナリオ？

注：また、本当の親ディレクトリのiノード番号をどこかに保存する必要があるため（これらのエントリはディレクトリへのハードリンクがこの時点で許可されていたことを思い出してください）、独自のiノード番号は、適切な健全性チェックになる場合があります。

私が実装する理由は見当たらない.と..のレベルではなく、他のいずれかにします。ただし、組み込みシステムを対象とする場合、節約できるレイヤーは何ドルにもなる可能性があるため、すべてを可能な限り低く実装することは理にかなっています。

.およびの一般的な必要性について、..それらなしで相対パスをどのように表現しますか？少なくとも..、現在のサブツリーを離れるパスには不可欠です。このようなパスが必要ない場合（おそらくツリーはアクセス権限をエンコードするための原始的な方法ですか？）は必要ありません..。