ファイル名とファイルパス名

ディレクトリにはファイル名 ⇒ inode マッピングのリストが含まれています。あなたのディレクトリには、（例えば）inodeを指す/home/timファイル名を持つエントリが含まれています。tim.pdf1234

このディレクトリにどのように行きますか？まあ、ディレクトリは実際にこれらのエントリを含む特別なファイルです。親ファイルを見ると、他のファイルと同じように見つけることができます。ディレクトリinodeを指す/homeファイル名を持つエントリがあります。tim順番に、私たちは/homeその親を調べることでそれを見つけることができます/。

/根なのにちょっと特別ですね。システムは親がないので、直接アクセスする方法を知っています。

これ名前ファイルのローカル名はそのディレクトリのローカル名ですtim.pdf。道ファイルの説明では、ルートディレクトリからファイルにアクセスする方法について説明します。/home/tim/tim.pdf必要に応じて、これを一連のガイドラインとして考えることができます。まず探し/、homeその中を探しtim、最後にtim.pdf欲しいものを探します。

すべてのパスを解析することは、実際に次の疑似コードを使用する再帰アルゴリズムです。

inode find_file(inode where_i_am, string[] remaining_path):
    if remaining_path is empty:
         # Nothing more to look at - we've found the file!
         return where_i_am
    current_item = remaining_path[0]
    rest_of_path = remaining_path[1..]
    for entry in directory_entries(where_i_am):
        if entry.filename == current_item:
            return find_file(entry.inode, rest_of_path)
    return file not found

以下からあなたのファイルを見つけることができます：

find_file(inode_of_root, ["home", "tim", "tim.pdf"])

---

場合によっては、状況がより複雑になり、疑似コードはそのような場合に対処しません。そのうちの1つはマウントです。別のパーティションをマウントすると、/homeシステムはそのパーティションが入ったときに/home別のパーティションに移動する必要があることを覚えておいて、timそのファイルシステムのルートで検索を開始します。新しいファイルシステムには独自のinodeセットがあるため、実際にファイルデータにアクセスするにはinodeとデバイスを知る必要があります。実際の構造は、実際には両方で構成されます。

シンボリックリンクは、システムに別のルートを探し、その新しい場所で検索を続行するように指示します。

もう一つのケースはハードリンク（古い友人）です。通常のファイルinodeには、必要な数のハードリンクがある可能性があります。ln tim.pdf pdf.tim同じ内容を持ち、ディスク上の同じ場所にあるリンク設定を使用できます。pdf.tim同じinodeを指すエントリを持つ別のディレクトリエントリがあります。私たちのアルゴリズムはこの場合非常にうまく機能します。ファイルへのハードリンクは元のファイルとまったく同じであり、いかなる方法でもそれらを区別する必要はありません。実際、ハードリンクはinodeの別の名前にすぎないため、ファイルシステム全体にハードリンクを作成することはできません。1234tim.pdf

もう一つは特別な項目.と..。これは（通常はファイルシステムによって異なります）実際のディレクトリエントリです。これは本質的にディレクトリ自体と親ディレクトリへのハードリンクです。私たちのアルゴリズムもこの問題を処理します。マウントについて興味深い点があります。デフォルトのファイルシステムはマウントする場所がわからないため、正しい..エントリを持つことはできません。この問題を解決するために、システムは..マウントされたファイルシステムのルートエントリの代わりに親デバイスのディレクトリエントリをだまして表示します。

---

したがって、inodeの観点から見ると、次のようになります。

• ㅏファイル名特定のディレクトリ内で呼び出される特定のインデックスノードの名前。
• ㅏ道既知のポイントからインデックスノードに到達する方法については、いくつかのガイドラインがあります。

存在するPOSIX 用語、ㅏファイル名ディレクトリエントリの名前です。 null または null を除いて空でないバイトシーケンスで構成されます/。 「パス名コンポーネント」という用語は、「ファイル名」と同義語です。 ㅏパス名null以外のバイトを含めることができ、ファイルを見つける方法を指定する文字列。パス名は一連のファイル名で構成され、最後の名前を除くすべての名前はディレクトリを表します。パス名の確認パス名でファイルを検索するプロセスです。

たとえば、/home/tim/tim.pdfパス名です。パス名の最後のコンポーネントtim.pdfはファイル名です。これは、パス名と呼ばれるディレクトリ内のエントリの名前です/home/tim。ファイル名tim自体は、pathnameというディレクトリにあるエントリの名前です/home。ファイルはディレクトリです。tim.pdfまた、パス名：すべてのファイル名は単一のコンポーネントを持つパス名であり、現在のディレクトリにその名前を持つファイルを指定します。

/ルートディレクトリのパス名を示します。.すべてのディレクトリに存在し、ディレクトリ自体を参照するファイル名。.正確に単一のコンポーネントを含み、現在のディレクトリを参照するパス名。

ファイル名は、そのディレクトリ内のファイルであるinodeへのディレクトリへのポインタと考えることができます。パス名は inode を探す場所を指定します。パス名の各コンポーネントは、これまでに到達したディレクトリ（ファイルが存在する場合）のインデックスノードを指すファイル名です。パス名はルートディレクトリから始まります。絶対パス名、）で始まる、または/現在のディレクトリにある場合相対パス名、）で始まらない/。

多くのテキストでは、「ファイル名」（または「ファイル名」）という用語は、POSIXがパス名と呼ばれることを意味するために使用されます。

一般的に言えば、pathnameとfilenamesは同じです。まず、filenamesPOSIXのドキュメントでいくつかのルールを読んでください。

4.6 ファイル名

IEEE Std 1003.1-2001に準拠する実装間でファイル名を移植できるようにするには、移植可能なファイル名文字セットに定義されている移植可能なファイル名文字のみを含める必要があります。

移植可能なファイル名の最初の文字としてハイフンを使用することはできません。大文字と小文字は、一貫した実装間で一意のIDを維持する必要があります。移植可能なパス名の場合、スラッシュ文字も使用できます。

filenameこのセクションでは、これら2つが使用され交換可能であることがわかりますpathname。

それらの間には次の違いもありますPathname Resolution。

4.11 パス名の決定

ファイル階層内の特定のファイルのパス名を解決するプロセスに対して、パス名解決が実行されます。同じファイルを解決するパス名が複数ある場合があります。

パス名の各ファイル名は、前のファイルで指定したディレクトリにあります。たとえば、パス名フラグメントa / bでは、ファイルbはディレクトリaにあります。これができない場合、パス名の解決は失敗します。パス名がスラッシュで始まる場合、パス名の最初のファイル名の先頭はプロセスのルートディレクトリとして扱われます（これらのパス名は「絶対パス名」です）。パス名がスラッシュで始まらない場合、パス名の最初のファイル名の先頭はプロセスの現在の作業ディレクトリとして扱われます（これらのパス名は「相対パス名」です）。

pathname以前のファイルが指定したディレクトリに名前があるファイルとして解釈されます。

ノート

• POSIX パス名の解決
• Linuxパスの確認