JPH10512986A - コンピュータ・システムにおけるファイル・ハンドルからのディレクトリ・パスネームの再構成 - Google Patents

Abstract

(57)【要約】 Ｌｉｎｋ Ｉｄｓは、コンピュータ・オペレーティング・システムにおけるディレクトリ構成のファイル・ハンドル（１０４−１０５）に関連付けられる。Ｌｉｎｋ Ｉｄｓは、ファイル・ハンドルを当該ファイル・ハンドルに関連付けられたファイルに対するパスネームへ固有にマップさせる。一つのインプリメンテーション・リストは、Ｌｉｎｋ Ｉｄに関連付けられたネームに対するディレクトリ構成の高速検索（２０８）を容易にすべく用いられる。リストは、各エントリ・ペアがＬｉｎｋ Ｉｄであるエントリ・ペア及びＬｉｎｋ Ｉｄに関連付けられたネームが見出されうるディレクトリ番号を含む。

Description

【発明の詳細な説明】 コンピュータ・システムにおけるファイル・ハンドルからのディレクトリ・パス ネームの再構成発明の分野 この発明は、一般にコンピュータ・オペレーティング・システムにおけるファ イルの識別に関し、特に、オペレーティング・システムによって保守されるファ イル・ハンドルからのパスネームの再構成に関する。発明の背景 従来のコンピュータ・オペレーティング・システムは、コンピュータ内に記憶 されたファイルを編成しかつ管理するために種々の方法を用いる。ファイルを編 成するための一つの一般的な方法は、ファイルまたはディレクトリを他のディレ クトリ内に存在させるディレクトリ構成によるものである。ディレクトリが別の ディレクトリ内に存在する場合、存在しているディレクトリは、“sub-director y（サブ・ディレクトリ）”と呼ばれる。ファイルは、その結果として“parent （ペアレント（親））”ディレクトリに存在する。ファイルのペアレント・ディ レクトリは、次いで、ペアレント・ディレクトリを有しうる、等であり、それゆ えに、ディレクトリの階層構造を生成する。それぞれがファイル及び更なるディ レクトリを含みうる、このディレクトリの階層構造は、図１Ａに示すようなディ レクトリ・ツリー構造を結果として生ずる。特定のファイルをアクセスするため に、開始からのチェーンにおけるペアレント・ディレクトリのそれぞれ、または “root（ルート）”ディレクトリは、ファイルの名前と一緒に、ストリングで命 名される。合成ストリングは、“パスネーム”と呼ばれる。 図１Ａは、“file1（ファイル１）”、“file2（ファイル２）”、“file3（ ファイル３）”及び“file4（ファイル４）”のようなファイルを含む、ルート ・ディレクトリ、“directory1（ディレクトリ１）”を含んでいる従来技術のデ ィレクトリ構成を示す。directory1（ディレクトリ１）は、また、ディレクト リー directory2（ディレクトリ２）及びdirectory3（ディレクトリ３）も含む 。directory2（ディレクトリ２）は、次いで、ファイル file5（ファイル５） 及びfile6（ファイル６）を含む。directory3（ディレクトリ３）は、ファイルf ile7（ファイル７）及びfile8（ファイル８）を含みかつまた、ディレクトリー directory4（ディレクトリ４）及びdirectory5（ディレクトリ５）も含む。dire ctory4は、ファイル file9（ファイル９）及びfile10（ファイル１０）を含む 。実際には、ディレクトリは、あらゆる数のファイルまたはディレクトリを含む ことができる。 オペレーティング・システムは、コンピュータ・システムのユーザに、図１Ａ に示すディレクトリ構成のようなディレクトリ構成内のファイル及びディレクト リーを生成させ、アクセスさせ、かつ処理させる。例えば、ユーザは、ファイル を生成しかつファイルが特定のディレクトリに配置されるということを特定する ことができる。ユーザは、ファイルを削除または移動することもできる。同様に 、ディレクトリに対して、ユーザは、ディレクトリが生成されるかまたは削除さ れるということを特定することができる。Ｕｎｉｘオペレーティング・システム に基づくオペレーティング・システム（即ち、Ｕｎｉｘライクなオペレーティン グ・システム）のような、あるオペレーティング・システムは、ユーザに、ファ イルが二つ以上の名前によってアクセスすることができるようにファイル間に“ リンク”を生成させる。 図１Ａでは、ファイル７は、テキスト・ストリング“/directory1/directory3 /file7”によって参照される。ディレクトリ、directory1、は、“root（ルート ）”ディレクトリと呼ばれかつパスネームがファイルへの絶対パスを特定すると ころのパスネームにおいて開始ディレクトリとして常に与えられる。絶対パスネ ームは、更なる情報を必要としないで所与のファイル・システム内のあらゆるフ ァイルを独自に識別する。パスネームの別の形式は、相対的パスを用いてファイ ル及び“curren（現行）”ディレクトリのような基準点または開始点を識別する 、相対的パスネームである。 例えば、相対的パスでは、現行ディレクトリがdirectory3であると想定すると 、file7は、“file7”としてファイルの名前を与えることによってだけ参照され うる。相対的パスの別の例は、現行ディレクトリがdirectory1であると想定する と、file7をアクセスすべくパス“directory3/file7”を用いることである。説 明の容易性のために、このアプリケーションは、絶対パスネームにより本発明を 記述する。ここに示された概念が相対的パスネームにも同様に適用可能であると いうことは、明らかであろう。Ｕｎｉｘディレクトリ構成及びパスネーム上の一 般情報は、例えば、ＩＳＯ／ＩＥＣ ９９４５−１，ＩＥＥＥ １００３．１− １９９０を調べる。 パスネームは、ディレクトリ及びファイルを特定するために人間ユーザに対し て便利な方法であると同時に、オペレーティング・システムは、“file handle （ファイル・ハンドル）”と呼ばれるパスネームのより計算的に上便利な内部表 現を用いる。一般的に、ファイル・ハンドルは、固有の数字または数字群であり かつコンピュータ・システム内に存在しているディレクトリまたはファイルのよ うな項目を独自に識別する他の情報も含みうる。 Ｕｎｉｘライク・オペレーティング・システムではファイル・ハンドルは、“ inode（アイノード）”number（ナンバー）と呼ばれる数字を含む。固有のinode numberは、ディレクトリ構成または“file system（ファイル・システム）”内 の各ファイル及びディレクトリに割り当てられる。ファイルまたはディレクトリ は、そのネームまたはファイル・ハンドルによって同等に参照されうる。本発明 を説明する目的に対し、inode number（アイノード・ナンバー）は、Ｕｎｉｘオ ペレーティング・システムのファイル・システムにおける所与のファイルに対し てファイル・ハンドルと同等であると考えられる。 図１Ｂは、Ｕｎｉｘライク・オペレーティング・システムにおけるディレクト リ・ツリー構造の例である。例えば、“directory1”、“file1”等の記述的ネ ームを用いるよりも、Ｕｎｉｘライク・システムにおいて出会うようなより一般 的なネームが用いられる。例えば、ルート・ディレクトリは、ラベル“／”が与 えられ、図１Ｂに示される二つのディレクトリは、“usr”及び“usr1”とラベ ル付けされる。また、図１Ｂにおいて、ディレクトリ及びファイル（例えば、フ ァイル“ｘ”、“ｙ”、及び“ｚ”）に対するネームは、ディレクトリ構成のグ ラフの縁（エッジ）に隣接して配置されるということにも注目する。図１Ａにお けるようなディレクトリ・グラフのノードにおけるファイル及びディレクトリ・ ネームの代わりに、図１Ｂに示したinode numbers は、ノードに配置される。こ れは、ファイル及びディレクトリがファイル・ハンドル（即ち、inode numbers ）によって表されるオペレーティング・システムの見地を示す。inode numbers は、括弧の中の数値として示される。inode numbers は、各ファイルまたディレ クトリに対する“meta data（メタ・データ）”を保持するデータ構造に関連付 けられる。meta-data は、サイズ、生成日、アクセス権利、等のような関連ファ イルまたはディレクトリについての情報を含む。 inode numbers（即ち、ファイル・ハンドル）にパスネームを翻訳、または“r esolve（分解）”するために、グラフにおいてエッジに隣接するネームは、ルー ト・ディレクトリから発して所望のファイルまで組み合わされる。例えば、ファ イル“ｙ”は、６のinode number（または単に、“inode 6”）で示される。ino de 6 に対するパスネームは、“/usr1/y ”である。図１Ｂでは、ルート・ディ レクトリは、inode number 2を有し、ディレクトリusr は、inode number 3 を 有する、等。パスネーム内で、個別のファイル及びディレクトリ・ネームは、ス ラッシュ（“／”）文字を用いて分離されるということに注目する。例えば、in ode number 7に対するパスネームは、“/usr1/z ”である。 各ファイルは、ファイル・システムが一つ以上のディスク・ドライブを表すよ うなfile system（ファイル・システム）に存在する。ルート・ディレクトリを 含んでいるファイル・システムは、root file system（ルート・ファイル・シス テム）と呼ばれる。各ファイル・システムは、ルート・ディレクトリが先頭に付 けられたそれ自身のファイル階層構造を有する。ルート・ディレクトリに対する inode numberは、常に、慣習により、番号２である。Inode numbers は、ファイ ル・システム内で固有である。ファイル・システムは、mountingと呼ばれる処理 によりルート・ファイル・システムにグラフト（接ぎ木）される。例えば、ファ イル５（“/ usr/x ”）がディレクトリであれば、図２に示すように第２のファ イル・システムをそのディレクトリにmounted（取付けることが）できる。 図１Ｃでは、File System（ファイル・システム）２は、図１Ａのinode numbe r ５（“directory5”）を有するディレクトリにおけるFile System（ファ イル・システム）1 に取り付けられている。取付け後に、File System 2 のルー ト・ディレクトリは、ファイル階層構造においてFile System 1 のdirectory5を 有効に置換したということに注目する。Directory5は、File System 2 が取り外 されるまで可視ではない。一度取付けが行われたならば、File System 2 のファ イルへのアクセスは、“/usr/x”で始まっているパスネームでなされる。例えば 、File System 2 のファイル６をアクセスするために、パスネーム“/usr/x/q/s ”が用いられるであろう。 パスネームを用いてファイルを捜し出す処理は、pathname resolution（パス ネーム・レゾルーション）と呼ばれる。パスネーム・レゾルーションのプロダク トは、file handle（ファイル・ハンドル）である。ファイル・ハンドルは、再 びファイルのネームを分解することなくファイルを参照するために内部的にオペ レーティング・システムによって用いられる。戻されたファイル・ハンドルは、 一般的にファイル・システム番号（device number（デバイス番号）と通常呼ば れる）とアイノード番号(inode number)の組合せである。この明細書内では、フ ァイル・ハンドルは、括弧で囲まれた一対の整数（例えば、（２，６））を用い て表される。 ファイル・システムにわたるファイルをリネーム（改名）することは、許され ない（例えば、図１Ｄでは“/usr1/y”を“/usr/x/p/f”にリネームすることは 、不法である）。 Ｕｎｉｘシステムの有用な特徴は、ほとんどのインプリメンテーションがディ レクトリに単一のネームだけを持たせるけれども、ファイルは、二つ以上のネー ムを有することができるということである。link()システム呼出しは、既存のフ ァイルに対する新しいネームを加えるために用いられる。例えば、呼出しlink( “/usr/x/q/r”,“/usr/x/p/f”)が図１Ｃのディレクトリ構成を含んでいるオペ レーティング・システムにおいてなされたならば、結果は、図１Ｄに示すようで あろう。いま、パスネーム“/usr/x/q/r”または“/usr/x/p/f”のいずれかは、 ファイル（２，５）をアクセスするために用いることができる。これは、一つの ネームが主要ネームであり他のものがエイリアス(alias)であるという情況では ないということに注目する−−両方のネームは、同様に用いることができかつオ リジナル・ネームは、新しいネームに影響を及ぼさないで除去することができる 。 改名を伴うの場合のように、link()システム呼出しは、一般的にファイル・シ ステム間のリンクを許容しない。ファイル・ハンドルを与えて、ファイル・ハン ドルによって表されたファイルに分解する二つ以上のパスネームが存在しうると いう、問題がファイル編成で存在する。これは、ファイル・ハンドルに基づきパ スネームを再発生することを困難にする。例えば、ファイル（２，５）を与える と、上記したリンク呼出しにより、ファイルへの二つの可能なパスネームが存在 するであろう。アイノード番号によって供給された限定付き情報だけで、どのパ スネームがファイル・ハンドル、即ちアイノード番号(inode number)を生成する ために最初に用いられたかということを告げることは、不可能である。発明の目的および概要 従って、同じファイルに対する複数のファイル・ハンドルの一つであるファイ ル・ハンドルがファイル・ハンドルを生成すべく最初に分解されたパスネームを 再発生するために用いることができるようなシステムを有することが望ましい。 そのようなシステムは、例えば、ファイルが複数のファイル・ハンドル及びパス ネームを有する場合にファイルをオープンするために用いられるパスネームを発 生するために有用である。 所与のファイル・ハンドルにパスネームを独自にマップするために、本発明の システムは、ファイル・システム・アイノード・ナンバー(inode numbers)、ま たはファイル・ハンドルに関連付けられたさらなる情報を用いる。特に、システ ムは、“link Id ”と呼ばれる番号及びペアレント・ディレクトリのアイノード ・ナンバー(inode number)を用いる。Link Id は、ファイルに対するリンクを固 有に識別する番号である。 本発明の一実施例では、オペレーティング・システムにおけるファイル・ハン ドルにパスネームを分解する方法が用いられる。方法は、予め既存のペアレント ・ファイルからの新しいファイルに対するリンクを生成しかつ記憶し；新しいフ ァイルに対するノード番号を生成しかつ記憶し；新しいファイルに対する固有の リンクＩｄ番号を記憶するサブステップを実行することによって新しいファイル ににリンクＩｄ番号を割り当て、リンクＩｄ番号は、ターゲット・ファイルに対 する全てのリンクの中で固有でありかつ、先の段階に続いて、新しいファイルの ノード番号及びリンクＩｄを用いて新しいファイルに対するパスネームを分解す ることを含む。図面の簡単な説明 図１Ａは、ディレクトリ構成の例を示す； 図１Ｂは、Ｕｎｉｘライク・オペレーティング・システムにおけるディレクト リ・ツリー構成の例を示す； 図１Ｃは、別のものに取付けられた一つのファイル・システムを示す； 図１Ｄは、図１Ｃのディレクトリ構成に対するリンク・コマンドの実行の結果 を示す； 図２は、本発明に使用するために適する一般的なコンピュータ・システムにお ける基本サブシステムの説明図である； 図３は、ターゲット・アイノードに新しいネームをリンクすべくリンク・コマ ンドガ実行されるときに呼び出されるルーチンに対するフローチャートを示す； かつ 図４は、ファイル・ハンドルにパスネームを関連付けるためにファイル・シス テムにおけるＬｉｎｋ Ｉｄｓ及びペアレント・リストを用いるルーチンに対す るフローチャートを示す。実施例 図２は、本発明に用いるのに適する一般的なコンピュータ・システムにおける 基本サブシステムの説明図である。図２では、サブシステムは、中央プロセッサ １０、システム・メモリ１１、ディスプレイ・アダプタ１２、モニタ１３、等の ようなブロックによって表される。サブシステムは、システム・バス１４を介し て相互接続される。プリンタ、キーボード、固定型ディスクのようなさらなるサ ブシステム及びその他が示されている。周辺装置及び入出力（Ｉ／Ｏ）機器は、 例えば、シリアル・ポート１５によってコンピュータ・システムに接続すること ができる。例えば、シリアル・ポート１５は、モデムまたはマウス入力機器にコ ンピュータ・システムを接続するために用いることができる。システム・バス１ ４を介する相互接続は、中央プロセッサ１０に各サブシステムと通信させかつシ ステム・メモリ１１または固定型ディスク１６からの命令の実行及びサブシステ ム間の情報の交換を制御させる。サブシステム及び相互接続の他の構成が可能で ある。 本発明は、“link Id（リンクId）”の概念を用いる。link Id は、本質的に は、ファイルに対するリンクの数の計数である。lastLinkId（ラストリンクＩｄ ）フィールドは、オペレーティング・システムのディレクトリ構成における各ア イノードに対して維持される。lastLinkIdフィールドは、アイノードに割り当て られた、または“linked（リンクされた）”、各ネームに対するlink Id 番号を 含む。 ファイルが最初に生成された場合、関連アイノードのlastLinkIdフィールドは 、１に設定されかつファイルに対する初期リンクも１である。そのように後続リ ンクが加えられ、lastLinkIdが増分されかつその値が新しいリンクのＩｄになる 。link Idsは、アイノード内で固有であることが必要なだけであることに注目す る−−ファイルに割り当てられた最初のリンクは、常にlink Id 1 を有し、第２ のものは、link Id 2 を有する、等である。 例として、ルート・ファイル・システムが空でありファイル“/a”が生成され ると想定する。新しいファイルは、アイノード番号３を有し（なぜならば、ルー ト・ディレクトリがアイノード番号２を常に得るので）かつ“a”は、link Id 1 を有する。ルート・ディレクトリの内容を表Ｉに示す。 表１ いま、呼出しlink(“/a”,“/b”)がなされたならば、ディレクトリは、表Ｉ Ｉに 示すようである。 表２ 次に、ディレクトリ“ｄ”（アイノード番号４）がルート・ディレクトリに加 えられると想定する。ルート・ディレクトリの内容は、表ＩＩＩに示すようであ る。 表３ この点において、呼出しlink(“/a”,“/d/f”)がなされたならば、ルート・ ディレクトリの内容は、変更されずかつdirectory4の内容は、表ＩＶに示すよう である。 表４ この点で、アイノード３のlastLinkIdフィールドは、ファイルが生成されて以 来ファイルに対する３つのリンクの合計が加えられたので値３を有する。 次に、フローチャートは、リンク・コマンドが実行された後にアイノードにLi nk Ids及びペアレント・リスト・エントリを割り当て、かつ所与のファイル・ハ ンドルにペスネームを分解、またはマップすべくLink Ids及びペアレント・リス ト・エントリ用いるための本発明のルーチンにおける段階を説明するために示さ れる。一般に、この明細書におけるフローチャートは、図２のコンピュータ・シ ステムのようなコンピュータ・システムにおいて実行する一つ以上のソフトウェ ア・ルーチンを説明する。ルーチンは、この技術分野において知られたようなあ らゆる手段によってインプリメントされうる。例えば、“Ｃ”、Ｐａｓｃａｌ、 ＦＯＲＴＲＡＮ、アセンブリ言語、等のような、あらゆる数のコンピュータ・プ ログラミング言語が用いられうる。更に、手続き、オブジェクト指向型または人 工知能技術のような種々のプログラミング・アプローチが採り入れられうる。 フローチャートの段階は、一つ以上のソフトウェア・ルーチン、処理、サブル ーチン、モジュール、等によってインプリメントされうる。ある場合には段階は 、オペレーティング・システム呼出しの使用によってインプリメントされうる。 各フローチャートは、単に本発明の方法の広範な論理フローの説明のためであり かつ段階は、本発明の範疇から逸脱することなくフローチャートに追加またはそ れから除去されうるということが理解されるであろう。更に、フローチャートに おける段階の実行の順番は、本発明の範疇から逸脱することなく変更されうる。 ソフトウェアにおけるフローチャートによって記述された方法をインプリメント することにおけるさらなる考慮は、段階の選択及び順番における変更を命令（指 図）しうる。ある考慮は、割込み駆動型、ポーリング型、または他のスキームに よる事象取扱い(event handling)である。マルチプロセッシングまたはマルチタ スキング環境は、段階を“同時”に実行させる。説明の簡略化のために各フロー チャートのインプリメンテーションは、それが単一の“ルーチン”でインプリメ ントされるように参照される。 図３では、フローチャート１００は、新しいネームをターゲット・アイノード にリンクすべくリンク・コマンドが、上述したように、実行されるときに段階１ ０２でエンター（入力）される。フローチャート１００にエンター（入力）す るまえに、ターゲット・ノードがそれに関連付けられたlastLinkIdフィールドを 有するということを想定する。lastLinkIdフィールドは、最初、ターゲット・ア イノードへの初期（オリジナル）リンクに対して１に設定される。ターゲット・ アイノードは、１のLink Id を有する。ターゲット・アイノードを生成するため に用いられるネームは、例えば、“ａ”と命名されたリンクに対して、上記表Ｉ に示したようなLink Id 及びターゲット・アイノード番号に関連付けられる。表 のそれぞれは、ペアレント・ディレクトリに存在しているアイノードのペアレン ト・ディレクトリに関連付けられたアイノードに対する情報を表す。 ステップ１０４ではターゲット・アイノードに対するlastLinkId値は、新しい リンクに対するLink Id を生成すべく増分される。ステップ１０５ではIastLink Idの値は、ペアレント・ディレクトリ表におけるリンクされたネームに割り当て られる。この例では、ターゲット・アイノードは、“ａ”と呼ばれる、一つのリ ンクだけを有し、かつlastLinkId値は、１のままであった。それゆえに、増分さ れたlastLinkId値は、２である。新しいエントリは、具体的にルート・ディレク トリである、ターゲット・アイノードのペアレント・ディレクトリに対するペア レント・ディレクトリ表においてなされる。新しいエントリは、ターゲット・ア イノード３と共に、リンクされたネーム、“ｂ”、及びLink Id 2 を含む。フロ ーチャートのルーチンは、ステップ１０６で出る。 それゆえに、図３のフローチャートは、リンク・コマンドがオペレーティング ・システムにおいて実行されるときにLink Idsを割り当てる方法を説明する。 図４は、パスネームをファイル・ハンドルに関連付けるためにファイル・シス テムにおけるLink Idsを用いるルーチンに対するフローチャート２００を示す。 フローチャート２００は、チャイルド・アイノード番号、ペアレント・アイノー ド番号、ファイル・システム番号及びLink Id を含んでいるファイル・ハンドル がパスされると想定されるようなステップ２０２でエンター（入力）される。 ステップ２０４では、ペアレント・アイノード番号及びファイル・システム番 号は、ペアレント・ディレクトリを捜し出すために用いられる。ステップ２０６ では、ディレクトリが捜し出されたかどうかというテストがなされる。ディレク トリが捜し出されなかったならば、ファイル・ハンドルは、“stale（ステール ）” であると想定されかつルーチンは、ステップ２１３を介してエラーを伴って出さ れる。 ステップ２０８では、ディレクトリ表は、チャイルド・アイノード番号及びLi nk Id におけるマッチを探すために検索される。ステップ２１０では、マッチが 見出されたかどうかというテストｉがなされる。マッチが見出されなかったなら ば、ファイル・ハンドルは、stale（ステール）であると想定されかつルーチン は、ステップ２１３を介してエラーを伴って出される。 ステップ２１２では、スラッシュ文字（“／”）及びチャイルド・アイノード 及びLink Id がマッチしているディレクトリ・エントリにおけるファイル・ネー ムは、完全なパスネームを形成すべくペアレント・ディレクトリのネームに追加 される。ペアレント・ディレクトリのネームは、オペレーティング・システムが ディレクトリ・ネームを得るために用いるあらゆる機能を用いて得られる。好ま しい実施例では、Ｕｎｉｘオペレーティング・システム・コマンド“getcwd”に よって用いられたステップを後続する手順がペアレント・ディレクトリのネーム を得るために用いられる。 そして、ルーチンは、ステップ２１４で出される。 それゆえに、図４は、ファイル・ハンドルが複数のパスネームを有することが できるファイルに対するようなパスネームにファイル・ハンドルをマップするた めのルーチンを示す。 上記明細書では、本発明は、その特定の例示的実施例を参照して記載された。 しかしながら、請求の範囲に示されたような本発明のより広い精神及び範疇から 逸脱することなく種々の変更及び変形がなされうるということが明らかであろう 。従って、明細書及び図面は、限定的ではなく説明のためであると考えられるべ きであり、本発明は、請求の範囲によってのみ制限される。

Claims (1)

1. 【特許請求の範囲】 １．コンピュータ・システムで実行しているオペレーティング・システムにおけ るファイル・ハンドルにパスネームを分解する方法であり、前記コンピュータ・ システムは、プロセッサ及びメモリを含み、前記オペレーティング・システムは 、パスネームを定義すべく一連の順序付けられたリンクを受け容れることによっ てパスネームの生成を許容し、各リンクは、リンク・ネームを含み、各リンクは 、ペアレント・ファイル及びターゲット・ファイル間に関連付けられ、各ファイ ルは、ノード番号を有し、所与の一連の順序付けられたリンクは、シーケンスの 最終リンクに関連付けられたターゲット・ファイルに対するパスネームを定義し 、所与のファイルに対するファイル・ハンドルは、所与のファイルのノード番号 を含み、前記方法は、 次のサブステップを実行することによって新しいファイルににリンクＩＤ番 号を割り当て、 予め既存のペアレント・ファイルからの前記新しいファイルに対するリ ンクを生成しかつ記憶し； 前記新しいファイルに対するノード番号を生成しかつ記憶し； 前記新しいファイルに対する固有のリンクＩＤ番号を記憶し、 前記リンクＩＤ番号は、前記ターゲット・ファイルに対する全てのリンクの 中で固有であり；かつ 上記段階に続いて、前記新しいファイルの前記ノード番号及びリンクＩＤを 用いて前記新しいファイルに対する前記パスネームを再生する 段階を具備することを特徴とする方法。 ２．前記オペレーティング・システムは、ＵＮＩＸファイル及びディレクトリ編 成スを有しているオペレーティング・システムであることを特徴とする請求項１ に記載の方法。