(57)【要約】【課題】アイテム名が一意であることを必要とせず、またアイテム名が存在することも必要としないファイルシステムを提供すること。【解決手段】アイテムがあいまいな名前を有している場合は、ファイルシステムはあいまいさを無くするプロシージャを実施して、完全に限定されたパスなど、概念的に一意の名前をクライアント（ユーザまたはアプリケーション）に提供する。このファイルシステムは、レガシーアプリケーションやレガシーシステムとの互換性を維持するためのユーザビリティ機能、例えば、アイテムに名前が無いときは合成アイテム名を生成する機能、２つのアイテムが同一の名前を有するときは小さな整数または英数字など、あいまい性除去用の文字を使用してあいまいさを無くする機能などを提供する。【選択図】図１４
2006164288.tif 000002
【特許請求の範囲】
【請求項１】
電子ファイルシステムによって使用されるデータ構造を格納したコンピュータ可読媒体であって、該データ構造は、
前記ファイルシステムによって読み取り可能であって、複数のアイテムのためのファイル情報を格納し、
第１のアイテムのための一意の第１の識別子を格納する第１のデータフィールドと、
前記第１のアイテムのユーザが見ることの可能な名前である第１のファイル名を格納する第２のデータフィールドと、
第２のアイテムのための一意の第２の識別子を格納する第３のデータフィールドと、
前記第２のアイテムのユーザが見ることの可能な名前である前記第１のファイル名を格納する第４のデータフィールドと
を含むファイル情報テーブル、および
前記ファイルシステムによって読み取り可能であって、前記複数のアイテムの関係情報を格納し、
前記第１のアイテムの親である第３のアイテムの指標を格納する第１のデータフィールドと、
前記第２のアイテムの親である前記第３のアイテムの指標を格納する第２のデータフィールドと
を含む編成テーブル
を含むことを特徴とするコンピュータ可読媒体。
【請求項２】
前記ファイル情報テーブルは、
前記第１のファイルのための第１のあいまい性除去識別子を格納する第５のデータフィールドと、
前記第２のファイルのための第２のあいまい性除去識別子を格納する第６のデータフィールドと
をさらに含み、前記第１および第２のあいまい性除去識別子は一意であることを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項３】
各前記あいまい性除去識別子は一意の整数を含むことを特徴とする請求項２に記載のコンピュータ可読媒体。
【請求項４】
前記ファイル情報テーブルと前記編成テーブルは別個のものであることを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項５】
前記第１のファイル名は名前がないことを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項６】
電子ファイルシステムにデータを格納する方法を実施するためのコンピュータ実行可能な命令を格納するコンピュータ可読媒体であって、該命令は、
（ａ）  前記ファイルシステムに格納された第１のアイテムのための第１の一意の識別子を前記ファイルシステムに格納するステップと、
（ｂ）  前記第１のアイテムのユーザが見ることの可能な名前である第１のファイル名を前記ファイルシステムに格納するステップと、
（ｃ）  前記ファイルシステムに格納された第２のアイテムのための第２の一意の識別子を前記ファイルシステムに格納するステップと、
（ｄ）  前記第２のアイテムのユーザが見ることの可能な名前である前記第１のファイル名を前記ファイルシステムに格納するステップと、
（ｅ）  前記第１のアイテムの親である第３のアイテムを識別する第１の保持リンクを前記ファイルシステムに格納するステップと、
（ｆ）  前記第２のアイテムの親である前記第３のアイテムを識別する第２の保持リンクを前記ファイルシステムに格納するステップと
を含むことを特徴とするコンピュータ可読媒体。
【請求項７】
前記命令は、
（ａ）  前記第１のアイテムのための第１のあいまい性除去識別子を格納するステップと、
（ｂ）  前記第２のアイテムのための第２のあいまい性除去識別子を格納するステップと
をさらに含むことを特徴とする請求項６に記載のコンピュータ可読媒体。
【請求項８】
各前記あいまい性除去識別子は一意の整数を含むことを特徴とする請求項７に記載のコンピュータ可読媒体。
【請求項９】
前記命令は、
（ａ）  前記第１のあいまい性除去識別子に基づいて、前記第１のアイテムの完全に限定されたパスを生成するステップ
をさらに含むことを特徴とする請求項７に記載のコンピュータ可読媒体。
【請求項１０】
前記命令は、
（ａ）  前記第１のあいまい性除去識別子に基づいて、前記第１のアイテムへのルートパスを生成するステップ
をさらに含むことを特徴とする請求項７に記載のコンピュータ可読媒体。
【請求項１１】
電子ファイルシステムにデータを格納するためのコンピュータ支援による方法であって、
（ａ）  前記ファイルシステムに格納された第１のアイテムのための第１の一意の識別子を前記ファイルシステムに格納するステップと、
（ｂ）  前記第１のアイテムのユーザが見ることの可能な名前である第１のファイル名を前記ファイルシステムに格納するステップと、
（ｃ）  前記ファイルシステムに格納された第２のアイテムのための第２の一意の識別子を前記ファイルシステムに格納するステップと、
（ｄ）  前記第２のアイテムのユーザが見ることの可能な名前である前記第１のファイル名を前記ファイルシステムに格納するステップと、
（ｅ）  前記第１のアイテムの親である第３のアイテムを識別する第１の保持リンクを前記ファイルシステムに格納するステップと、
（ｆ）  前記第２のアイテムの親である前記第３のアイテムを識別する第２の保持リンクを前記ファイルシステムに格納するステップと
を含むことを特徴とするコンピュータ支援による方法。
【請求項１２】
（ａ）  前記第１のアイテムのための第１のあいまい性除去識別子を格納するステップと、
（ｂ）  前記第２のアイテムのための第２のあいまい性除去識別子を格納するステップと
をさらに含むことを特徴とする請求項１１に記載のコンピュータ支援による方法。
【請求項１３】
各前記あいまい性除去識別子は一意の整数を含むことを特徴とする請求項１２に記載のコンピュータ支援による方法。
【請求項１４】
（ａ）  前記第１のあいまい性除去識別子に基づいて前記第１のアイテムの完全に限定されたパスを生成するステップ
をさらに含むことを特徴とする請求項１２に記載のコンピュータ支援による方法。
【請求項１５】
（ａ）  前記第１のあいまい性除去識別子に基づいて前記第１のアイテムへのルートパスを生成するステップ
をさらに含むことを特徴とする請求項１２に記載のコンピュータ支援の方法。
【請求項１６】
複数のユーザが見ることの可能なファイルを格納するための電子ファイルシステムを動作させるように構成されたコンピュータ装置であって、前記ユーザが見ることの可能なファイルの少なくとも２つは共通のあいまいなファイル名を有することを特徴とするコンピュータ装置。
【請求項１７】
前記共通のあいまいなファイル名は名前のないファイル名を含むことを特徴とする請求項１６に記載のコンピュータ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に、コンピュータシステム用のファイルシステムに関する。より詳細には、本発明は共通の親を持つ複数のアイテムがあいまいなファイル名をもつこと、例えば同一の名前を持つこと、あるいは名前を全く持たないことなどを許容するファイルシステムを提供することに関する。
【背景技術】
【０００２】
コンピュータはハードディスクドライブ（以下、ハードドライブ）などの記憶装置にファイルを格納する。ハードドイブは、空（ｅｍｐｔｙ）のファイルキャビネット（書類棚）と同様に、単にデータを格納する場所だけを提供する。空のファイルキャビネットがファイルのためのどのような所定のファイリングシステムを強いることもないように（すなわち、ファイルキャビネットの使用者が自分自身で、例えばファイルをアルファベット順に並べることなどによって、ファイリングシステムまたは組織構造（ｏｒｇａｎｉｚａｔｉｏｎ ｓｔｒｕｃｔｕｒｅ）を生成しなければならないように）、ハードドライブもまた初期設定では単なる空の記憶空間である。したがって、ハードドライブ上のデータにアクセスする方法は、ディスク上のデータの物理位置を指定する（例えば、ファイルが格納されているハードドライブのシリンダ、ヘッド、およびセクタを指定する）か、あるいはディスク上のデータの論理位置（例えば、２１，６７１番目のブロック）を指定することに限られる。ハードディスクドライブがコンピュータにインストールされた後は、コンピュータは、ファイルシステムを使用して、ハードディスクドライブ上に格納されたファイルを、容易にアクセス可能な方法で把握することができる。
【０００３】
既知のファイルシステムでは、オペレーティングシステムと、ファイルシステムのユーザとが、ファイルシステム中のファイルをどのように編成することができるのかが極度に制限されている。すなわち、既知のファイルシステムでは一般に、ユーザはファイルとディレクトリからなるツリーの形（木構造）でアイテムを編成する必要があり、その場合、ディレクトリは、実際には、ファイルシステムによって識別される特別な種類のファイルとなる。既知のファイルシステムではまた、各アイテムはユーザから見て唯一の名前を持つ必要がある。すなわち、各アイテムはその親（ｐａｒｅｎｔ）の下で一意の名前を持つことが必要になる。言い換えると、共通の親を持つどの２つのアイテムも同一の名前を持つことはできないことになる（ただし、共通の祖先（ａｎｃｅｓｔｏｒ）を持つ２つのアイテムは同一の名前を持つことができる）。一意の名前が必要になるのは、名前が、オペレーティングシステム、ソフトウェアアプリケーション、およびユーザが、ファイルシステムに格納されたファイルまたはアイテムを検出し識別するための手段になっていたからである。しかし、ユーザがアクセスするファイルの数が益々増大してきているので、このファイル名の要件は問題が多く、耐え難い負担になってきている。
【０００４】
デジタルカメラなどの装置が、ファイル名の問題を悪化させてきている。なぜならば、このような装置は、デジタル写真など大量の新しいファイルを生成し、そのファイルの各々が自動的に決定されるファイル名を持つものであるからである。一般に、このような装置では、異なるフォルダ間でファイル名が再利用され、また数値的に増分するファイル名が使用される。このため、ユーザはこれらの装置からパソコン（パーソナルコンピュータ）など他の装置にファイルをインポート（取り込み）する際に注意が必要になる。元のフォルダ構造が維持されない場合には、ユーザは名前が衝突し（すなわち、２つ以上のファイルが同じ場所で同じ名前を持ち）、ファイルのリネーム（ファイル名を変えること）が必要になる可能性について心配しなければならないこととなる。理屈の上では単純な仕事であるはずのファイルのインポートが、実際には、時間のかかるもどかしい仕事になる。
【０００５】
図２は、現在のファイルシステムの代表的な組織構造２０１の簡単な例を示す。図２に示すように、既知のファイルシステムでは、ツリーを用いて、（丸い角の枠で囲んで示した）ディレクトリと、（四角い矩形枠で囲んで示した）ファイルとが構成される。ツリー構造では、アイテムの位置と編成とが融合され、各アイテムはただ１つのディレクトリ中に存在しなければならない。ユーザは、このような形で自分自身のファイルを編成する必要があり、したがってユーザはアイテムの新しいコピーを作成することなしに複数の編成にアイテムを配置することはできない。
【０００６】
代表的なファイルシステムにおいては、相互に関連する２つのテーブルまたはデータベースを使用してファイルが編成される。第１のテーブルまたはデータベースは、ハードドライブなどの記憶装置上でファイルが格納されている物理位置を識別するためのルックアップテーブルである。第２のテーブルは、ファイルの組織構造を定義する。本明細書では、これらのテーブルを一般的に、それぞれロケーションテーブル（ＬＯＣ）および編成テーブル（ＯＲＧ；ｏｒｇａｎｉｚａｔｉｏｎａｌ ｔａｂｌｅ）と呼ぶ。編成テーブルは、保持リンク（ｈｏｌｄｉｎｇ ｌｉｎｋｓ）、すなわち、あるアイテムが他のアイテムの親であることに関する情報を格納する。ファイルシステムによっては、ロケーションテーブルと編成テーブルを１つのテーブルまたは構造に組み合わせることができるが、ファイルシステムが適切に動作するためには、やはり両方のテーブルの要素が存在することが必要になる。例えば、マイクロソフトコーポレーションから販売されているＮＴブランドのファイルシステム、すなわちＮＴＦＳでは、マスタファイルテーブルがロケーションテーブルと編成テーブルの両方の機能を果たす。同様に、Ｕｎｉｘ（登録商標）ファイルシステム、すなわちＵＦＳではｉノードのテーブルが使用されるが、このテーブルもファイルのロケーションテーブルと編成テーブルの両方の機能を果たす。ディレクトリは特別な種類のファイルとして格納される。すなわち、ディレクトリ「ファイル」は、そのディレクトリ内のファイル名とそのファイルに対応するｉノードのリストを格納する。
【０００７】
これらおよび他の既知のファイルシステムでは、ファイルが編成テーブル中の保持リンクによって定義された少なくとも１つの位置に置かれている限り、ファイルシステムはそのファイルを物理記憶装置上に格納しておく。すなわち、ファイルを指示する少なくとも１つの保持リンクが存在することになる。言い換えると、あるファイルに対する保持リンクが編成テーブルから削除され、そのファイルを指示する保持リンクが存在しなくなった場合には、ファイルシステムは（そのファイルが記憶装置上に物理的に上書きされたかどうかに関係なく）ロケーションテーブル中のそのファイルのエントリを除去する。次いで、記憶装置はその記憶空間を新しいデータを書き込むために使用することができる。例えば、ユーザが図２に示したファイル、Ｃ：＼ＰＲＯＧＲＡＭＳ＼ＭＩＣＲＯＳＯＦＴ＼ＯＦＦＩＣＥ＼ＷＯＲＤ＼ＦＩＬＥ．ＤＯＣを「削除」しようとした場合には、ファイルシステムは最初に編成テーブルからそのファイルのエントリを除去する。そのファイルがロケーションテーブル内に他のエントリを有していない場合に、すなわち、そのファイルが他のどの場所にも格納されていない場合には、ファイルシステムはロケーションテーブル内のそのファイルのエントリを除去し、他のデータのために空間を開放する。一般に、ファイルシステムは、所与のアイテムが有する（「保持リンク」と呼ばれる）祖先の数の参照カウントを維持する。あるアイテムについての最後の保持リンクが除去されたときには、ロケーションテーブル中のそのファイルの参照を除去することによって、そのアイテムは「削除」される。しかし、参照カウントはエンドユーザの観点からは望ましくない。なぜならば、非循環有向グラフ（ｄｉｒｅｃｔｅｄ  ａｃｙｃｌｉｃ  ｇｒａｐｈ）とともに使用されたときに、そのシステムが非決定性（ｎｏｎ−ｄｅｔｅｒｍｉｎｉｓｔｉｃ）に見えるからである。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
上記の制限や制約のために、ディレクトリおよびファイルからなるツリー状の階層構造以外のデータ構造でファイルを編成することは困難になる。ユーザは、所与のアイテムが削除されることを心配せずに、様々な組織データ構造においてアイテムを編成し編成解除できることを望む。また、同一フォルダ内の各アイテムは名前を持つ必要があるが、重複した名前を持つことはできない。したがって、格納されたアイテムが名前を持つことを必要としないファイルシステムが提供できれば、当技術分野における進歩・前進になるはずである。共通の親を持つ２つのアイテムが、同一の名前を持つことができるファイルシステムを提供できれば、当技術分野における別の進歩・前進になるはずである。
【課題を解決するための手段】
【０００９】
以下では、本発明のいくつかの態様についての基本的な理解が得られるように本発明の簡単な要約を提示する。この要約は本発明を幅広く概観するものではない。また、本発明の主要要素または重要要素を識別すること、あるいは本発明の範囲を記述することを意図したものでもない。後で記述されるより詳細な説明の準備として、本発明のいくつかの概念を簡単な形で提示することだけを目的としたものである。
【００１０】
上記の従来技術における１つまたは複数の制限を克服するため、および／または本明細書を読み理解したときに明らかになるはずの他の制限を克服するために、本発明は一般に、コンピュータ可読媒体に格納されたデータアイテムおよびコンピュータ実行可能命令として実施されるファイルシステムを対象とするものである。データアイテムは一般に、これらに限られるものではないが、ファイル、フォルダ、データ、音楽など、ファイルシステムに格納できる任意のデータを意味する。ファイルシステムは、ファイル情報テーブルおよび編成テーブルを含むデータ構造を使用することができる。ファイル情報テーブルは、第１のアイテムのための一意の第１の識別子を格納する第１のデータフィールド、第１のアイテムのユーザが見ることの可能な名前である第１のファイル名を格納する第２のデータフィールド、第２のアイテムのための一意の第２の識別子を格納する第３のデータフィールド、および第２のアイテムのユーザが見ることの可能な名前である第１のファイル名を格納する第４のデータフィールドを保管する。編成テーブルは、第１のアイテムの親である第３のアイテムの指示を格納する第１のデータフィールド、および第２のアイテムの親である第３のアイテムの指示を格納する第２のデータフィールドを保管する。
【００１１】
本発明の他の例示的態様によれば、ファイルシステムにアイテムを格納するためのコンピュータで実行される方法が提供される。この方法によると、ファイルシステムクライアント（コンピュータ）は同一の親を有する２つのアイテムに対してあいまいなファイル名を格納することができるようになる。一般にこの方法は、ファイルシステムに格納された第１のアイテムの第１の一意の識別子をファイルシステムに格納すること、第１のアイテムのユーザが見ることの可能な名前である第１のファイル名をファイルシステムに格納すること、ファイルシステムに格納された第２のアイテムの第２の一意の識別子をファイルシステムに格納すること、第２のアイテムのユーザが見ることの可能な名前である第１のファイル名をファイルシステムに格納すること、第１のアイテムの親である第３のアイテムを識別する第１の保持リンクをファイルシステムに格納すること、および第２のアイテムの親である第３のアイテムを識別する第２の保持リンクをファイルシステムに格納することを含む。
【００１２】
本発明および本発明の効果・利点についてのより完全な理解は、以下の説明を添付の図面を考慮しながら参照することによって得ることができる。図面中の同一の参照番号は同一の機能を示す。
【発明を実施するための最良の形態】
【００１３】
様々な実施形態についての以下の説明では、添付の図面を参照する。添付の図面は本発明の一部をなすものであり、本発明を実施することができる様々な実施形態を例示したものである。その他の実施形態を使用することができること、ならびに本発明の範囲を逸脱することなく構造および機能に関する修正をなし得ることを理解されたい。
【００１４】
例示的コンピュータ環境
図１は、本発明を実装することができる適切なコンピュータシステム環境１００の一例を示す。このコンピュータシステム環境１００は、適切なコンピュータ環境の一例に過ぎず、本発明の使用または機能の範囲に関して、いかなる制限を加えることも意図したものではない。コンピュータ環境１００は、例示的動作環境１００に示された各コンポーネントの任意の１つまたは組合せに関して、いかなる依存性または要件も有していないものと理解されたい。
【００１５】
本発明は、他の多くの汎用または専用コンピュータシステム環境または構成とともに使用することができる。本発明とともに使用するのに適した周知のコンピュータシステム、環境、および／または構成の例には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドもしくはラップトップ装置、マルチプロセッサシステム、マイクロコントローラベースシステム、セットトップボックス、プログラマブル家電、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ（大型コンピュータ）、上記のシステムまたは装置のいくつかを含む分散コンピュータ環境などが含まれるが、これらに限られるものではない。
【００１６】
本発明は、コンピュータによって実行される、プログラムモジュールなどコンピュータ実行可能な命令の一般的なコンテキストで説明することができる。一般に、プログラムモジュールは、特定のタスクを実行するか、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明は、通信ネットワークを介してリンクされたリモート（遠隔）処理装置によって各タスクが実行される分散コンピュータ環境においても実施することができる。分散コンピュータ環境では、各プログラムモジュールはローカル（局所）およびリモート（遠隔）のどちらのコンピュータ記憶媒体、例えばメモリ記憶装置にも配置することができる。
【００１７】
図１を参照するように、本発明を実行する典型的なシステムには、コンピュータ１１０のようなタイプの汎用コンピュータ装置が含まれる。コンピュータ１１０の各コンポーネントには処理ユニット１２０、システムメモリ１３０、システムバス１２１などが含まれるが、これらに限られるものではない。システムバスは、システムメモリなど様々なシステムコンポーネントを処理ユニット１２０に連結する。システムバス１２１には、メモリバスもしくはメモリコントローラ、周辺機器バス、および様々なバスアーキテクチャのいずれかを使用するローカルバスなど、いくつかの種類のバス構造のうちのいずれかを使用することができる。例として、このようなアーキテクチャにはＩＳＡ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ  ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、メザニン（Ｍｅｚｚａｎｉｎｅ）バスとも呼ばれるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスなどが含まれるが、これらに限られるものではない。
【００１８】
コンピュータ１１０は一般に、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０によってアクセス可能な任意の使用可能媒体であればよく、揮発性および不揮発性媒体、取り外し可能および取り外し不能媒体の両方を含んでいる。一例として、コンピュータ可読媒体にはコンピュータ記憶媒体および通信媒体を含めることができるが、これらに限られるものではない。コンピュータ記憶媒体はコンピュータ可読命令、データ構造、プログラムモジュール、その他のデータなどの情報を記憶するためのいずれかの方法または技術で実装された、揮発性および不揮発性、取り外し可能および取り外し不能の両方の媒体を含む。コンピュータ記憶媒体には、これらに限られるものではないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリなどのメモリ技術製品、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌ  ｖｅｒｓａｔｉｌｅ  ｄｉｓｋｓ；デジタル多用途ディスク）などの光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置などの磁気記憶装置、あるいは所望の情報を格納するために使用でき、かつコンピュータ１１０によってアクセス可能な他の任意の媒体、または媒体の組合せが含まれる。通信媒体は一般に、コンピュータ可読命令、データ構造、プログラムモジュール、その他のデータなどを、搬送波や他の伝送機構などの変調データ信号の形で実施するとともに、いずれかの情報送達媒体を含んでいる。「変調データ信号」という用語は、１つまたは複数の信号特性セットを含むか、または情報を信号中に符号化するような形で変更された信号を意味する。例として、通信媒体には、有線ネットワーク、直接有線接続などの有線媒体、ならびに音響、ＲＦ、赤外、その他のワイヤレス無線媒体などの無線媒体が含まれるが、これらに限られるものではない。
【００１９】
システムメモリ１３０は、ＲＯＭ（読み出し専用メモリ）１３１やＲＡＭ（ランダムアクセスメモリ）１３２など、揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。基本入／出力システム（ＢＩＯＳ）１３３は、例えば起動時などに、コンピュータ１１０内の各要素間の情報転送を支援する基本ルーチンを含み、通常はＲＯＭ１３１に格納されている。ＲＡＭ１３２は一般に、処理ユニット１２０によって即時にアクセス可能かつ／または現在実行中の、データおよび／またはプログラムモジュールを含む。一例として、図１にはオペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、プログラムデータ１３７、およびファイルシステム１３８が示すが、これらに限られるものではない。
【００２０】
コンピュータ１１０は、他の取り外し可能／取り外し不能、揮発性／不揮発性のコンピュータ記憶媒体を含むこともできる。例示の意味で図１には、取り外し不能な不揮発性の磁気媒体に読み書きするためのハードディスクドライブ１４１、取り外し可能な不揮発性磁気ディスク１５２に読み書きするための磁気ディスクドライブ１５１、ならびにＣＤ−ＲＯＭや他の光媒体など取り外し可能で不揮発性の光ディスク１５６に読み書きするための光ディスクドライブ１５５が示す。例示の動作環境で使用できる他の取り外し可能／取り外し不能、揮発性／不揮発性のコンピュータ記憶媒体には、磁気テープカセット、フラッシュメモリカード、ＤＶＤ、デジタルビデオテープ、半導体ＲＡＭ、半導体ＲＯＭなどがあるが、これに限られるものではない。ハードディスクドライブ１４１は一般に、インタフェース１４０など取り外し不能メモリインタフェースを介してシステムバス１２１に接続されるが、磁気ディスクドライブ１５１および光ディスクドライブ１５５は一般に、インタフェース１５０など取り外し可能メモリインタフェースを介してシステムバス１２１に接続される。
【００２１】
上で論じ、図１に示したドライブ（駆動装置）および関連するコンピュータ記憶媒体は、コンピュータ１１０のためのコンピュータ可読の命令、データ構造、プログラムモジュール、その他のデータなどに対する記憶を提供する。図１では、例えばハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、プログラムデータ１４７、およびファイルシステム１４８を格納するように図示している。これらの各コンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、プログラムデータ１３７、およびファイルシステム１３８と同一であっても、異なっていてもよいことに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、プログラムデータ１４７、およびファイルシステム１４８は、例えばそれらが異なるコピーであることを示すために、図１では異なる番号が付与されている。ユーザは入力装置、例えばキーボード１６２や、マウス、トラックボール、タッチパッドなどを総称するポインティング装置１６１を介して、コンピュータ１１０に命令および情報を入力することができる。他の入力装置として、リモコン（遠隔制御器）１６３、マイクロホン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどを含むことができる（これらすべてを図示している訳ではない）。これらおよび他の入力装置は、システムバスに結合されたユーザ入力インタフェース１６０を介して、処理ユニット１２０に接続されることが多いが、パラレルポート、ゲームポート、またはＵＳＢ（ｕｎｉｖｅｒｓａｌ  ｓｅｒｉａｌ  ｂｕｓ）など、他のインタフェースやバス構造を用いて接続することもできる。モニタ１９１または他の種類の表示装置（例えば、ＴＶ）もまた、ビデオインタフェース１９０などのインタフェースを介してシステムバス１２１に接続される。コンピュータは、モニタの他に、例えば出力周辺機器インタフェース１９５を介して接続されるスピーカ１９７、プリンタ１９６など他の周辺出力装置を含むこともできる。
【００２２】
いくつかの態様では、手書き入力をデジタル的に取り込むためにペンデジタイザ１６５および付属のペンまたはスタイラス１６６が備えられている。ペンデジタイザ１６５とユーザ入力インタフェース１６０の間は直接接続されているように図示しているが、実際には、ペンデジタイザ１６５は無線などの任意の技術によって、処理ユニット１２０に直接結合すること、パラレルポートもしくは他のインタフェースに結合すること、およびシステムバス１２１に結合することができる。ペン１６６はまた、それに結合されたカメラ、およびカメラによって取り込まれた画像情報をバス１２１を介して対話するインタフェースに無線で送信するためのトランシーバを備えることもできる。さらにペンには、加速度計、磁力計、ジャイロスコープなど他のセンシングシステムをカメラに追加し、またはカメラの代わりに備えることで、電子インクのストロークを決定することもできる。
【００２３】
コンピュータ１１０は、リモートコンピュータ（遠隔地コンピュータ）１８０など１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク環境で動作させることができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア(ｐｅｅｒ)装置、または他の共通ネットワークノードなどであってもよい。また、図１にはリモートコンピュータ１８０に対してメモリ記憶装置１８１だけを示すが、リモートコンピュータ１８０は一般に、コンピュータ１１０に関連して上で説明した要素の多く、またはすべてを含むことができる。図１に示した論理接続には、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１８０が含まれているが、他のネットワークを含めることもできる。このようなネットワーク環境は、オフィス（事務所）、企業規模のコンピュータネットワーク、イントラネット（企業内ネットワーク）、インターネットなどにおいて一般的なものである。さらに、このシステムは、有線および／または無線の機能を含むこともできる。例えば、ネットワークインタフェース１７０は、ブルートゥース（Ｂｌｕｅｔｏｏｔｈ）、ＳＷＬａｎ、および／またはＩＥＥＥ８０２．１１クラスの組合せ機能を含むことができる。これらのプロトコルとともに、またはこれらのプロトコルの代わりに、他の無線通信プロトコルが使用できることを理解されたい。
【００２４】
ＬＡＮネットワーク環境で使用されるとき、コンピュータ１１０は、ネットワークインタフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーク環境で使用されるとき、コンピュータ１１０は一般に、インターネットなどのＷＡＮ１７３を介して通信を確立するためのモデム１７２などの手段を含む。モデム１７２は、内蔵のことも外付けのこともあるが、ユーザ入力インタフェース１６０または他の適切な機構によってシステムバス１２１に接続することができる。ネットワーク環境では、コンピュータ１１０に関連して示した各プログラムモジュールまたはその一部は、リモートのメモリ記憶装置に格納することができる。例えば、図１では、リモートのアプリケーションプログラム１８５が、メモリ装置１８１に常駐するように示しているが，これに限られる訳ではない。図１に示すネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立するための他の手段を使用してもよいことが理解されるであろう。
【００２５】
図１に図示したネットワーク接続が例示的なものであり、コンピュータ間の通信リンクを確立するための他の技術を使用できることが理解されよう。ＴＣＰ／ＩＰ、イーサネット（登録商標）、ＦＴＰ、ＨＴＴＰなどの様々な周知のプロトコルのうちのいずれかの存在を想定している。このシステムは、ユーザがウェブベースのサーバからウェブページを取り出すことができるように、クライアントサーバ構成で動作することができる。様々な従来のウェブブラウザのいずれかを使用してウェブページ上のデータを表示し、操作することができる。
【００２６】
本発明の１つまたは複数の態様は、コンピュータ１１０など１台または複数台のコンピュータ、または他の装置によって実行される１つまたは複数のプログラムモジュールなどのコンピュータ実行可能な命令の形で実施することができる。一般に、プログラムモジュールは、コンピュータまたは他の装置のプロセッサによって実行されるときに、特定のタスクを実施するか、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。コンピュータ実行可能な命令は、ハードディスク、光ディスク、取り外し可能記憶媒体、半導体メモリ、ＲＡＭなどのコンピュータ可読媒体に格納することができる。当業者ならば理解できるはずであるが、プログラムモジュールの機能は、様々な実施形態での必要に応じて組み合わせること、または分散させることができる。さらに、各機能は、その全体または一部を、集積回路やＦＰＧＡ（ｆｉｅｌｄ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙｓ；フィールド・プログラマブル・ゲート・アレー）などのファームウェアまたはハードウェア均等物の形で実施することもができる。
【００２７】
本発明の例示的な実施形態の例
本発明の例示的態様に従って、本明細書には、アイテムのライフタイムとファイルシステムの組織構造内のアイテムの配置とを融合させないことによって、例えば特性ベースの照会やリストなどを用いることによって、アイテムが複数の編成に参加すること、あるいはどの編成にも参加しないことを許容し、それら編成が１つまたは複数の非循環有向グラフ（ＤＡＧ）を形成するというファイルシステムが記載されている。ＤＡＧはアイテムが複数の親を持つことができる編成である。ＤＡＧにおいては、アイテムがその祖先の１つの親になり１つのサイクルを形成することを避けることができる。
【００２８】
本明細書で説明するファイルシステムは、例えばファイルシステム１３８および／またはファイルシステム１４８（図１）としてコンピュータ可読媒体に格納されたコンピュータ実行可能命令として実施することができる。さらに、図１の他のコンピュータ可読媒体またはメモリもまた、本明細書で説明するファイルシステムと同一の、またはそれとは異なるファイルシステムを含むことができる。例えば、媒体１５２および１５６もまたファイルシステムを含むことができる。説明のために、本明細書ではファイルシステムをファイルシステム１４８に関連して述べることとする。
【００２９】
図３および図４を参照すると、ファイルシステム１４８は、主に２つのテーブル、すなわちロケーションテーブル（ＬＯＣ）３０１と編成テーブル（ＯＲＧ）４０１に依存している。ＬＯＣテーブルとも呼ばれるロケーションテーブル３０１は、ファイルシステムに格納された各アイテムの物理および／または論理・記憶位置に関する情報、例えば、ファイル識別子（ＩＤ）３０３、ファイル名３０５、記憶ボリューム３０７、ロケーション（記憶場所）３０９、およびファイルサイズ３１１などを格納する。ファイルＩＤ３０３は各アイテムを参照するために使用される基本キーまたは照会先（ｒｅｆｅｒｅｎｃｅ）であり、ファイルシステム１４８に格納された各アイテムに対して一意である。ファイルＩＤは、各ファイルＩＤがファイルシステム１４８に格納された単一のアイテムを一意に識別する限りは、数字、アルファベットテキスト、シンボル、またはそれらの任意の組合せとすることができる。
【００３０】
ファイル名３０５は、ファイルシステム１４８のユーザによって付けられた、アイテムの短い記述的ファイル名とすることができる。ファイル名３０５は各ファイルに対するユーザの一番の概念的参照であり、ファイル名に基づいてユーザがファイルを容易に認識できるような記述的な形でユーザが指定できることが好ましい。ファイル名３０５では、例えば、８．３フォーマット、２５６文字の最大長、またはその他の最大長さなど、長さを制限することができる。ファイル名が互いに重複しているかどうかに関する制約、あるいはファイル名が必要であるかどうか、または割り当てられているかどうかに関する制約さえ無いことが好ましい。すなわち、各ファイルが一意のファイルＩＤ３０３を有する限りは，同一のディレクトリ、フォルダ、またはリスト内にあっても、複数のファイルをそれぞれ「ＲＥＡＤＭＥ．ＴＸＴ」または「Ｒｅａｄ  ｔｈｉｓ  ｆｉｒｓｔ」などと名付けることができる。この点は、各ファイルがその親のコンテキスト内で一意の名前を有する必要がある従来のファイルシステムと異なる。
【００３１】
ボリューム３０７、ロケーション３０９、サイズ３１１を使用して、物理または論理記憶位置からアイテムを取り出すことができる。ボリューム３０７により、物理または論理記憶装置、例えば物理または論理ハードディスクドライブ、光ディスク記憶装置、記憶媒体カード、半導体記憶素子などを参照することができる。ロケーション３０９により、識別された物理または論理ボリューム上のアイテムの実際の開始位置を参照することができる。また、サイズ３１１により、識別されたボリューム上で、識別されたロケーションから始まるアイテムが格納されたスペースの量についての定量的測度を参照することができる。各識別された記憶位置から各格納されたアイテムを取り出すために含まれた情報が使用できる限りは、ロケーションテーブル３０１に追加の、または代替の情報を含めることができる。
【００３２】
ＯＲＧテーブルとも呼ばれる編成テーブル４０１は、ファイルシステム１４８に格納されたアイテム間の階層関係を格納する。先に要約して述べたように、ＯＲＧテーブル４０１は１つまたは複数の非循環有向グラフ（ＤＡＧ）を定義することができる。非循環有向グラフは、ファイルシステム１４８内のアイテムを概念的に配列するための１つまたは複数のツリーを含むことができる。ＯＲＧテーブル４０１は、各関連ごとに親４０３と子４０５を含むことができる。図５は、ＬＯＣテーブル３０１の一部によって定義され、またＯＲＧテーブル４０１によって定義されたＤＡＧ５０１の一例を示す。ＤＡＧ５０１はツリーではない。なぜならば、アイテムＩ３については「Ｔｏ  Ｄｏ  Ｌｉｓｔ」と「Ｉｔｅｍｓ  Ｆｏｒ  Ｍｙ  Ｔｒｉｐ」の両方が親になっており（両方に「属する（ｉｎ）」とも呼ばれる）、アイテムＩ４については「Ｉｔｅｍｓ  Ｆｏｒ  Ｍｙ  Ｔｒｉｐ」と「Ｋｅｙ  Ｓｌｉｄｅ  Ｄｅｃｋｓ」の両方が親になっているからである。ファイルシステム１４８に格納された各アイテムは、組織構造がＤＡＧである限りは、親を持たないこと、１つの親を持つこと、または２つ以上の親を持つことができる。
【００３３】
図６は、ファイルシステム１４８で使用することができるソフトウェアモジュールのブロック図を示す。ファイルシステム１４８は、ファイルシステム１４８全体の動作を管理するファイルシステムマネージャソフトウェアモジュール６０１を含むことができる。マネージャ６０１は、本明細書に記載のＬＯＣテーブル３０１およびＯＲＧテーブル４０１を使用して、（例えば、循環が許されないなど）ＤＡＧに設定されたあらゆる制約に関するルールを実施しながら、データストア６１１に格納された各アイテムの追加、更新、削除、および読出し／照会（問合せ）を実施することができる。マネージャ６０１は、オペレーティングシステムなどの上位プログラムがファイルシステム１４８と対話できるようにする１つまたは複数のＡＰＩ（アプリケーションプログラムインタフェース）を公開することができる。ＡＰＩには、Ａｄｄ＿Ｉｔｅｍ  ＡＰＩ  ６０３、Ｕｐｄａｔｅ＿Ｉｔｅｍ  ＡＰＩ  ６０５、Ｄｅｌｅｔｅ＿Ｉｔｅｍ  ＡＰＩ  ６０７、およびＱｕｅｒｙ＿Ｉｔｅｍ  ＡＰＩ  ６０９を含めることができる。
【００３４】
Ａｄｄ＿Ｉｔｅｍ  ＡＰＩ  ６０３は、新しいアイテムをファイルシステム１４８に格納するときに、オペレーティングシステムや他の上位プログラムまたはアプリケーションによってコールされることができる。Ａｄｄ＿Ｉｔｅｍ  ＡＰＩ  ６０３は、新しいアイテムの現在の一時記憶場所へのポインタおよびファイル名、ならびにオプションにより対象とする記憶ボリュームおよび／または親ＩＤを入力として受け取ることができる。Ａｄｄ＿Ｉｔｅｍ  ＡＰＩは、新しく追加されたアイテムのファイルＩＤをオプションにより返すことができる。
【００３５】
Ｕｐｄａｔｅ＿Ｉｔｅｍ  ＡＰＩ  ６０５は、ファイルシステム１４８に既に格納済みの既存のアイテムを更新するためにコールすることができる。また、入力として、ファイルＩＤならびに１つまたは複数のオプションで含められた情報、すなわちアイテムの更新されたバージョンへのポインタ、ＯＲＧテーブル４０１に含めるための更新された関係（関連）、および／または更新されたファイル名の中から選択された情報を受け取ることができる。
【００３６】
Ｄｅｌｅｔｅ＿Ｉｔｅｍ  ＡＰＩ  ６０７は、削除するファイルＩＤをそのＤｅｌｅｔｅ＿Ｉｔｅｍ  ＡＰＩに渡すことによって、ファイルシステム１４８からアイテムを除去するためにコールすることができる。アイテムがファイルシステム１４８から削除されるのは、Ｄｅｌｅｔｅ＿Ｉｔｅｍ  ＡＰＩ  ６０７が明白にコールされたときだけである。
【００３７】
Ｑｕｅｒｙ＿Ｉｔｅｍ  ＡＰＩ  ６０９は、ＯＳまたはアプリケーションによって使用するためにファイルシステムからアイテムを取り出す（読み出す、検索する）必要があるときにコールすることができる。Ｑｕｅｒｙ＿Ｉｔｅｍは、入力としてファイルＩＤを受け取り、要求されたアイテムを返す。上記の各ＡＰＩはＡＰＩの種類のうちの代表的なものであり、本発明の例示的実施形態に含めることが好ましい。ファイルシステム１４８には、システムの必要性または設計に基づいて追加の、または代替のＡＰＩを含めることもできる。
【００３８】
ファイルシステム１４８は各アイテムが０を含む任意の数の親を持つことを許容するので、単一のボリュームまたはファイルシステム内に複数の独立したデータ構造（すなわち、複数のＤＡＧ）が存在し得る。この点が既知のファイルシステムと異なっており、既知のファイルシステムでは、一般にクライアント（ユーザまたはアプリケーション）が各ボリュームあたり単一のツリーにアイテムを格納するように制限されている。したがって、本明細書で説明するようなファイルシステムに各アイテムが格納される概念空間は、ファイル領域（ＦＲ）と呼ばれる。ファイル領域は、アイテムのライフタイムを管理するために使用される編成領域（ｏｒｇａｎｉｚａｔｉｏｎａｌ ａｒｅａ）の上位ユーザ概念（ｈｉｇｈ−ｌｅｖｅｌ ｕｓｅｒ ｃｏｎｃｅｐｔ）を意味する。アイテムがファイル領域にとどまる限りは、そのアイテムがＯＲＧテーブル４０１に定義されたいずれかの親子関係に従うかどうかとは関係なく、そのアイテムが削除されることはない。
【００３９】
ファイル領域は、各アイテムが概念的に関連づけられているかどうかに関係なく、概念的にはアイテムを置くことができるボックスと考えることができる。アイテムがファイル領域に置かれている場合は、そのアイテムは、ユーザがそのアイテムを削除するまでファイル領域内にとどまる。アイテムがファイル領域内に存在している間は、アイテムがファイル領域内に存在するかどうかに影響を与えることなく、またアイテムのライフタイムに影響を与えることもなく、アイテムはファイル領域内の１つまたは複数のＤＡＧのいずれかで構成することができる。すなわち、ファイルは、そのファイルを削除することをユーザがファイルシステムに断言的に指示するまでは削除されることはない。アイテムのライフタイムを保証するために、データストアが単一のファイル領域として管理される限りは、関係するすべてのデータストアが同一のコンピュータ、ネットワークなどの中で互いに物理的に接近しているかどうかに関係なく、ファイル領域はどのように定義された記憶領域でも包含することができる。例えば、ファイル領域は、コンピュータのすべての内部ハードドライブ、コンピュータの単一のハードドライブの一部、単体またはローカルの記憶装置と組み合わされたネットワーク上の記憶装置、または他の任意に定義された記憶空間を包含することができる。
【００４０】
図７および図８は、３つの独立したＤＡＧ５０１、７０３、７０５を含むファイル領域７０１を示す。ＤＡＧ５０１、７０３、および７０５の間で要求される関係は、それらが同一のファイル領域内にあることだけであり、それらの間の概念的関係は要求されない。図８は、図７に示したＤＡＧを記述するＯＲＧテーブル８０１を示す。図７は、ファイル領域７０１の概念的な図を示し、図８はファイル領域７０１で使用されている保持リンクを示す。ファイル領域７０１は、ユーザによってオープンすることができ、オープンされた時点で、ファイルシステム１４８はユーザにファイルシステムによって定義されたファイル領域内のすべての「トップレベル（最高位）」アイテムまたは「フローティング（浮動）」アイテムを提示することができる。本明細書の使用では、あるアイテムが、ファイル領域に対応するＯＲＧテーブル内の他のアイテムのどの保持リンクからもターゲットにされていない場合に、そのアイテムを「トップレベル」または「フローティング」と定義する。したがって、図７では、アイテムｉ１、ｉ７、Ｔｏ  Ｄｏ  Ｌｉｓｔ、およびＩｔｅｍｓ  Ｆｏｒ  Ｍｙ  Ｔｒｉｐがトップレベルアイテムまたはフローティングアイテムと見なされる。エンドユーザにとって、リストｉ７は組織データ構造の形になっている。複数の親の概念に基づけば、アイテムは、例えばｉ３のように複数のリスト（目録）に属することができる。リストは、順序通りまたは順不同で他のアイテムを保持するアイテムであり、リストは、ユーザがこれまでのファイルシステムにおいて取り扱いに慣れしたしんでいるフォルダ／ディレクトリに置き換わることができる。リストはまた、他のリストに属するか、または他のリストを含むことができる。
【００４１】
ファイルシステム１４８は、ユーザまたはアプリケーション（まとめてクライアントと呼ぶ）が、アイテムの基になる組織構造からアイテムを除去する（ｒｅｍｏｖｅ）ことを望む場合と、クライアントがファイルシステムからアイテムを完全に削除する（ｄｅｌｅｔｅ）ことを望む場合を区別する。図９および図１０は、ユーザまたはアプリケーションがＫｅｙ  Ｓｌｉｄｅ  Ｄｅｃｋｓリストからアイテムｉ５を除去した後のファイル領域７０１を示す。すなわち、ファイルシステムマネージャ６０１は、Ｕｐｄａｔｅ＿Ｉｔｅｍ  ＡＰＩ  ６０５の要求に基づいて、アイテムｉ５（ファイルＩＤ  ０００００６）の親であるＫｅｙ  Ｓｌｉｄｅ  Ｄｅｃｋｓ（ファイルＩＤ  ０００００７）を識別する、ＯＲＧテーブル１００１中の保持リンクを除去する。アイテムｉ５はもはや複数アイテム組織構造の一部ではない。なぜならば、ＯＲＧテーブル４０１からアイテムｉ５に関連するすべての保持リンクが除去されたからである。しかし、アイテムｉ５はまだファイル領域７０１に残っているので、アイテムｉ５はファイルシステム１４８またはＬＯＣテーブル３０１からは削除されていない。言い換えると、クライアントがアイテムｉ５を削除することを要求したのではなく、アイテムｉ５を除去（ｒｅｍｏｖｅ）するよう要求したので、アイテムｉ５はデータストア６１１およびＬＯＣテーブル３０１から削除されなかったことになる。クライアントが積極的に、断言的にアイテムｉ５を選択し、Ｄｅｌｅｔｅ＿Ｉｔｅｍ  ＡＰＩ  ６０７による削除動作を要求したときだけ、マネージャ６０１はデータストア６１１およびＬＯＣテーブル３０１からアイテムｉ５（ファイルＩＤ０００００６）を抹消する。
【００４２】
図１１および図１２を参照すると、ファイルシステム１４８を使用して、従来から知られているファイルシステム、例えばディレクトリツリーで使用されている組織構造に基づいて、ユーザによく知られた組織構造を模擬（模倣）することができる。ＬＯＣテーブル３０１（図３）を再度参照すると、ファイルＩＤ０００３０１〜０００３１２を有するアイテムは、ファイルシステム１４８に格納されたリストの保持リンクを表す。各順不同のリストは、ファイル領域１２０１（図１２）およびＯＲＧテーブル１１０１（図１１）の形で概念的に表されたディレクトリツリー１２０３中のディレクトリを表す。このディレクトリツリー１２０３と従来から知られているディレクトリツリーの主な違いは、サブディレクトリ「Ｓｈａｒｅｄ」が順不同リストの２つの「Ｕｓｅｒ  Ｄａｔａ」のどちらからもアクセスできることであり、その結果ファイルシステム１４８が複数の親の機能をうまく利用できることである。このようにして、今までどおりユーザが使い慣れた組織構造を提供しながら、各ディレクトリをユーザ間で容易に共用することができる。
【００４３】
本発明のこの例示的実施形態によれば、ファイルシステム１４８は、ファイルシステム１４８が実装されたコンピュータシステムまたはネットワークの各個別のユーザのための専用ワークスペースを提供し、またそのコンピュータシステムまたはネットワークのすべてのユーザが使用できる共通共用ワークスペースも提供する。どちらもがＵｓｅｒ  Ｄａｔａの下にあるＰｒｉｖａｔｅおよびＳｈａｒｅｄファイル領域を含むような名前空間が形成される。これにより、システムに対するユーザの照会をＵｓｅｒ  Ｄａｔａによって形成されたアイテムドメインで検索することが可能になり、その結果、すべての一般的な照会に対して専用と共用の両方のアイテムが返されることになる。図１２の名前空間を使用することにより、（新しい写真または音楽を入手する、文書を作成するなどのために）ユーザがファイルシステムの各アイテムと対話するとき、ユーザは概念的に「これは専用か共用か？」の質問を考えることだけが必要であって、そのアイテムを適切なワークスペース内に置くことができる。次いで、Ｓｈａｒｅｄワークスペースのすべてのユーザは、Ｓｈａｒｅｄワークスペースへの共通の可視性を有する。さらに、ワークスペースごとに共用のリサイクルごみ箱を設置して、あるユーザが他のユーザがまだ必要としているアイテムを削除した場合でも他のユーザがそのアイテムを取り出せるようにすることもできる。
【００４４】
共通共用ワークスペースのシナリオはホームユーザに限定されるものではない。企業ドメイン上では、知識労働者はプロジェクトで協働するために同僚のための共用ワークスペースを提供することができる。ワークスペースの柔軟性により、ワークスペースの各ユーザに、アイテムを構成し、ワークスペース内のアイテムを照会する機能が与えられ、これらのアイテムについての共通の全体の可視性が提供される。
【００４５】
図１３は、アイテムの基になる組織構造からアイテムを除去するメソッド、および／またはファイルシステム１４８からアイテムを削除するメソッドを示す。最初に、ステップ１３０１で、クライアントは特定のファイルＩＤを有するアイテムを選択する。次に、ステップ１３０３で、クライアントは、クライアントがファイルシステム１４８から完全にアイテムを削除したいのか、あるいはクライアントが単にアイテムの基になる組織構造からアイテムを除去したいのかを指示する。ステップ１３０３で、クライアントが「除去」を選択した場合は、ステップ１３０５でファイルシステムマネージャは、アイテムのファイルＩＤが子カラム（子の欄）に存在するあらゆるエントリをＯＲＧテーブルから抹消する。次いで、このメソッドは終了する。
【００４６】
ステップ１３０３で、クライアントが「削除」を選択した場合には、ステップ１３０７でファイルシステムマネージャ６０１は、アイテムのファイルＩＤが親カラム（親の欄）に存在する各ＯＲＧテーブルエントリごとに、そのアイテムの子が子であり、そのアイテムの親が親であるエントリを、それらがＯＲＧテーブルに未だ存在していない場合には、ＯＲＧテーブルに追加する。以下に、使用可能な擬似コードを示す。
【００４７】
For each ORG table entry X where Xparent = file_ID(ITEM)
For each ORG table entry Y where Ychild = file_ID(ITEM)
If ORG table does not have entry（Yparent, Xchild) 
Then Add ORG table entry (Yparent, Xchild)
【００４８】
このようにしてＯＲＧテーブルを更新した後に、ステップ１３０９で、ファイルシステムマネージャは、そのアイテムのファイルＩＤを親または子として参照するあらゆるエントリをＯＲＧテーブルから削除する。最後に、ステップ１３１１で、ファイルシステムマネージャ６０１は、ＬＯＣテーブルからそのアイテムが格納された場所を示すエントリを削除する。ファイルシステムマネージャ６０１はさらに、安全削除動作を実施し、削除取り消し動作ができないようにガーベッジデータ（不要なデータ）を有するアイテムの位置に蓄積データを上書きする。
【００４９】
別法として、ファイルシステムマネージャはステップ１３０７をスキップし、ステップ１３０９で単に、そのアイテムが親または子であるあらゆるエントリをＯＲＧテーブルから消去することもできる。この別法の副作用は、削除されるそのアイテムの各子が、ファイルシステム１４８の組織構造に引き続き存在する第２のアイテムがその子の親になっている場合を除き、ファイルシステム１４８の組織構造から消去されるようになることである。
【００５０】
上記の方法は、選択されたアイテムおよびその選択されたアイテムによって指示されるあらゆるアイテムが基になる組織構造から除去されるように説明されている。しかし、当業者ならば、あるアイテムが組織構造から除去されるときにそのアイテムの子が組織構造から除去されない代替方法も使用できることを理解されたい。除去方法がどのように行なわれるかは、除去（ｒｅｍｏｖａｌ）と削除(ｄｅｌｅｔｉｏｎ)が２つの別個のプロセスであるという事実ほど重要ではない。削除プロセスは記憶装置全体からアイテムを削除するが、除去プロセスは、アイテムのライフタイムに影響を与えることなく、基になる組織構造からアイテムを除去する（すなわち、記憶装置またはファイルシステムからアイテムを削除する訳ではない）。
【００５１】
従来のファイルシステムナビゲーションツール、例えば米国ワシントン州レドモンドのマイクロソフトコーポレーションによるＷｉｎｄｏｗｓ（登録商標）ＥＸＰＬＯＲＥＲブランドのシステムナビゲーションツールは、一般にファイルシステムの組織構造のファイルだけを示す。したがって、クライアントがファイルシステム１４８の組織構造からアイテムを除去した場合、すなわちアイテムがＯＲＧテーブルに存在しない場合には、そのアイテムはファイルシステムナビゲーション表示には表示されない。しかし、本発明の諸態様を使用すると、クライアントは、ファイルシステムマネージャ６０１にすべてのフローティングまたはトップレベルアイテム（すなわち、親がないアイテム）を照会して、現在の組織構造中に存在しない任意のアイテムを見つけ出すことができる。
【００５２】
ファイルシステム１４８は、ＯＲＧテーブル４０１によって定義された組織構造に基づいて、ドメイン照会、セキュリティなど追加の機能を提供することができる。すなわち、組織構造の定義に加えて、ＯＲＧテーブル中の保持リンクを使用して、名前空間（ネームスペース）とも呼ばれる照会可能なアイテムドメインを形成することができる。クライアントは、そのアイテムが親である、少なくとも１つの保持リンクに関係する任意のアイテムを照会することができる。例えば、図７を参照すると、「Ｉｔｅｍｓ  Ｆｏｒ  Ｍｙ  Ｔｒｉｐ」についての照会では、アイテムｉ３、ｉ４、ｉ５、ｉ８ならびにＫｅｙ  Ｓｌｉｄｅ  Ｄｅｃｋｓが返される。重複アイテムは、一度だけ返されることが好ましい。例えばｉ４については、Ｋｅｙ  Ｓｌｉｄｅ  Ｄｅｃｋｓも親になっているが、一度だけ返すことが好ましい。
【００５３】
ファイルシステム１４８の組織構造を使用して、レガシー（ｌｅｇａｃｙ）アプリケーション（古い仕様や技術のアプリケーション）による使用のために名前空間を伝達することもできる。また、新しいユーザに、ファイルシステム１４８と対話するための概念的に認識可能なユーザインタフェースを提供することもできる。例えば、図１２を参照すると、「Ｕ１」の下のアイテム「Ｕｓｅｒ  Ｄａｔａ」は、クライアントから、＼Ｕｓｅｒｓ＼Ｕ１＼Ｕｓｅｒ  Ｄａｔａとして参照することができ、エンドユーザおよびレガシーアプリケーションに概念的によく知られたインタフェースを提供することができる。
【００５４】
ＯＲＧ４０１によって定義された組織構造を使用して、ファイルシステム１４８のセキュリティ情報を伝達することもできる。すなわち、セキュリティテーブル（図示せず）によりアイテムのセキュリティ情報を提供することもできる。デフォルトで、ユーザが所与のアイテムにアクセスすることができる場合には、そのユーザは、デフォルトで所与のアイテムが指示する他の全てのアイテムに、直接または間接的にアクセスすることができる。
【００５５】
例えば、アイテムＵ１（図１２）のセキュリティは、ユーザネーム＝Ｒｏｓｓを有するユーザだけが、Ｕ１内のファイルにアクセスできるように指示することができる。Ｕ１が親になっているアイテムであるＡｐｐ  ＤａｔａおよびＵｓｅｒ  Ｄａｔａに異なるセキュリティ情報が与えられていない場合には、やはりＲｏｓｓだけがそれらのアイテムを閲覧することができる。同様のことが、（Ｕ１が親であるＵｓｅｒ  Ｄａｔａが親になっている）ＰｒｉｖａｔｅとＳｈａｒｅｄについても当てはまる。アイテムＵ２のセキュリティは、ユーザネーム＝Ｊｏｒｄａｎを有するユーザだけがＵ２内のファイルにアクセスできるように指示することができる。Ｕ２が親になっているアイテムであるＡｐｐ  ＤａｔａおよびＵｓｅｒ  Ｄａｔａに異なるセキュリティ情報が与えられていない場合には、やはりＪｏｒｄａｎだけがそれらのアイテムを閲覧することができる。同様のことが、（Ｕ２が親であるＵｓｅｒ  Ｄａｔａが親になっている）ＰｒｉｖａｔｅとＳｈａｒｅｄについても当てはまる。アイテムＳｈａｒｅｄは矛盾したセキュリティ情報を有しているように見えるが、セキュリティ情報は加法的であることが好ましい。したがって、アイテムＳｈａｒｅｄはＵ１およびＵ２の両方からセキュリティ情報を受け取り、「ＲｏｓｓとＪｏｒｄａｎだけ」を許可することになる。あるいは、Ｕ１が「Ｔｏｍではなく、Ｒｏｓｓだけ」に相当する許可を有していると想定する。このとき、アイテムＳｈａｒｅｄは「Ｔｏｍではなく、ＲｏｓｓとＪｏｒｄａｎだけ」に相当するセキュリティ許可を受けることになる。
【００５６】
アイテムがＯＲＧから除去されたとき、セキュリティは除去されたアイテムへの伝達を停止する。例えば、図９に示すように、アイテムｉ５が「Ｋｅｙ  Ｓｌｉｄｅ  Ｄｅｃｋｓ」から除去された場合には、ｉ５にアクセスする許可がユーザに与えられている場合を除き、もはやユーザはｉ５にアクセスできないことになる。しかし、ファイルシステム１４８は、デフォルトで、あるクライアントが特にあるアイテムへのアクセスを禁止されていない限り、そのクライアントはすべてのアイテムにアクセスすることができると指定することもできる。
【００５７】
上述のようにリストもまた名前空間を形成するので、（本明細書に記載のファイル領域、ＤＡＧ、またはリストとともに動作する機能を備えていないことがある）Ｗｉｎｄｏｗｓ（登録商標）  ＸＰマシンや他のレガシーマシンのユーザがファイルシステム１４８に接続した場合は、ユーザはそのリストが、ナビゲートすることができるフォルダに見えることに気付くかもしれない。同様に、ユーザが（レガシーオペレーティングシステム上、またはファイルシステム１４８によって使用可能なシステム上の）リストのコンテキストに存在する所与のアイテムをダブルクリックしたとき、ファイルシステムは要求元アプリケーションに対して現在のリストによって形成された名前空間を提供する。これ（名前空間）は、アプリケーションに必要なコンテキストを提供する。例えば、ユーザがリスト「Ｔｏ  ｄｏ  Ｌｉｓｔ」を介してアイテムｉ２をオープンしようと試みた場合、ファイルシステムは「Ｔｏ  ｄｏ  Ｌｉｓｔ」を介して形成されるパス、すなわち、＼Ｔｏ  Ｄｏ  Ｌｉｓｔ＼ｉ２をアプリケーションに返す。したがってユーザが、（例えば、アイテムの新しいコピーを生成するために）アプリケーション内のコマンド「Ｆｉｌｅ｜Ｓａｖｅ  Ａｓ．．．」の使用を選択した場合は、アプリケーションはユーザに提示するための正しいコンテキストを得ることができることになる。
【００５８】
あいまいな名前
上記のように、各アイテムは一意のアイテム名を持つ必要はない。なぜならば、各アイテムはひとえに（本質的に）ファイルＩＤによって識別されるからであり、ファイルＩＤはファイルシステム内の各アイテムを一意に識別するからである。したがって、複数のアイテムが同一のファイル名を持つことができる。さらに、アイテムは名前を持つ必要も無い。以前のファイルシステムとは異なり、共通の親を持つ２つ以上のアイテムでさえ、同一の名前を持つことができる。また、どちらもが全く名前を持たないことも可能である（すなわち、ネームフィールドが空またはヌル）。あるアイテムが名前を持たないか、または同じ親を持つ他のアイテムと共通の名前を持つ場合、そのアイテムはあいまいなファイル名を持つと言われる。しかし、アイテムがあいまいな名前（ａｍｂｉｇｕｏｕｓ ｎａｍｅ）を持つことを許容することにより、ファイルシステムの適切な動作に関する問題が生じることになる。このような問題には、あいまいな名前でアイテムを参照することが含まれる。すなわち、クライアント（ユーザまたはアプリケーション）が、どのようにしてそのアイテムを参照するのか、およびあいまいな名前を持つ２つ以上のアイテムをどのようにして区別するのかが含まれる。
【００５９】
図１４は、同じファイル名を持つ２つのアイテム１４０３、１４０５、ならびにファイル名を持たないアイテム１４０７を示す。したがって、これら３つのアイテム１４０３、１４０５、１４０７の各々はあいまいなファイル名を持つことになる。ファイルシステム１４８でアイテムが生成されたとき、ファイルシステムはＬＯＣテーブルでそのアイテムに一意のファイルＩＤを割り当てる。次いでこのファイルＩＤは、アイテムを参照するためにファイルシステムによって使用され、またオプションによりクライアントによっても使用される。ユーザクライアントはファイル名によってアイテムを参照する可能性が高く、一方アプリケーションクライアントはファイルＩＤによってアイテムを参照する可能性が高い。しかし、名前のないアイテムに対しては、ファイルＩＤがアイテムへの主要な参照になる。
【００６０】
図１４において、アイテム１４０３（ＲｅａｄＭｅ）および１４０５（ＲｅａｄＭｅ）は、どちらもアイテム１４０１（Ｐ１）が直接の親となっている。アイテム１４０３およびアイテム１４０５は同一のファイル名を有しているが、それらは２つの異なるアイテムであり、かつ異なるデータを格納する。各アイテム１４０３および１４０５は、それらの異なるファイルＩＤ、００４１６および００４１７によって、それぞれ一意に識別することができる。アイテム１４０７にはファイル名が割り当てられておらず、したがってそのファイルＩＤ（００４１８）によって参照される。例えば、Ｓａｖｅ  Ａｓダイアログボックスによってアイテムを保管するとき、ファイルはファイル名なしで生成することができる。ユーザは、単にエンターキーを打つだけで，名前の入力なしにアイテムを保管することができる。
【００６１】
重複したファイル名または全くファイル名が無いことを許容することによって、本質的にユーザとレガシーアプリケーションに対しては混乱が生じる可能性がある。リストはフォルダと下位互換性を持つことができるので、レガシーアプリケーションでは重複した名前によって、妥協できない名前の衝突が引き起こされる可能性がある。したがって、本発明の様々な態様により、ファイルシステム１４８は、他の方法ではあいまいになる所望のアイテムをクライアントによって識別できるようにするユーザビリティ機能（便利で使い勝手の良い機能）を提供することができる。
【００６２】
この例では、ファイルシステム１４８は、Ｗｉｎ３２アプリケーションなどのレガシーシステムとの下位交換性を提供し、一意のファイル名を提供する。Ｗｉｎ３２アプリケーションに対する下位交換性が必要なのは、Ｗｉｎ３２アプリケーションが、一意の名前空間が存在するとの想定の下に設計されているからである。したがって、Ｗｉｎ３２アプリケーションでは、アイテムをオープンするためにファイル名が必要になる。Ｗｉｎ３２アプリケーションとの下位交換性を提供するために、ファイルシステム１４８は、ファイルシステム１４８がレガシーアプリケーションに提供する一意のファイル名を自動的に生成することによって、ファイル名のあいまいさを無くする。ファイルシステム１４８はまた一意のファイル名へのパスも生成する。例えば、アイテム１４０３と１４０５に対するパスは、単に＼Ｐ１である。パスと名前を併せて、アイテムの完全に限定された名前（ｑｕａｌｉｆｉｅｄ ｎａｍｅ）が構成される。したがって、アイテム１４０３の完全に限定されたあいまいな名前は、＼Ｐ１＼ＲｅａｄＭｅとなる。アイテム１４０５はアイテム１４０３とは異なるアイテムであるが、アイテム１４０５の完全に限定されたあいまいな名前もまた、＼Ｐ１＼ＲｅａｄＭｅとなる。両方のアイテムが同一の完全に限定されたパス（ｑｕａｌｉｆｉｅｄ ｐａｔｈ）を有することになるので、ファイルシステム１４８は、以下で説明するような方法でそれらのあいまいさを無くする。
【００６３】
ファイル名それ自体があいまいなために、ファイルシステム１４８がファイル名のあいまいさを無くすることが望まれる状況には、少なくとも２つのシナリオが存在する。第１のシナリオは、共通の親の下で複数のアイテムが同一のファイル名（例えば、上記の例のＲｅａｄＭｅなど）を持つ場合である。第２のシナリオは、アイテムが全く名前を持たない場合である。どちらのシナリオでも、レガシーアプリケーションに提供するために、一意の完全に限定されたファイル名が生成される。本発明の例示的態様によれば、ファイルシステム１４８はアイテム名として単にファイルＩＤだけを使用することができる。例えば、ファイルシステム１４８は、アイテム１４０３を完全に限定された名前、＼Ｐ１＼００４１６で識別し、アイテム１４０５を完全に限定された名前、＼Ｐ１＼００４１７で識別し、アイテム１４０７を完全に限定された名前、＼Ｐ１＼００４１８で識別することができる。しかし、ユーザがアイテムの内容を認識するために、しばしば名前を利用するので、数値ネームの有用性は限られる。さらに、アプリケーションはＭＲＵ（Ｍｏｓｔ  Ｒｅｃｅｎｔｌｙ  Ｕｓｅｄ：直前に使用された）リスト、例えばアプリケーションのファイルメニューに最近オープンしたアイテムの名前を表示することも多い。ユーザがＭＲＵリスト中の数値ネームの表示を見て困惑しないとも限らないので、たとえ可能であり、本発明の範囲に含まれると見なされるとしても、この選択肢は好ましくない。
【００６４】
その代わりとして、共通の親の下で複数のアイテムが重複した名前を有するシナリオでは、ファイルシステム１４８は重複したファイル名を基にして、そのファイル名に人間可読の（必須ではないが、好ましくは小さな値の）整数を挿入することによって、一意のファイル名を生成する。例えば、アイテム１４０３には、一意のファイル名「Ｒｅａｄｍｅ１」を与え、アイテム１４０５には一意の名前「ＲｅａｄＭｅ２」を与えることができる。アイテムが全くファイル名を持たない場合には、一意のファイル名はファイルシステム１４８によって提供される識別用整数になる。したがって、アイテム１４０７には一意のファイル名「３」を与えることができる。ファイルシステムは、ファイル名のあいまいさを無くするために使用された整数を再利用しないことが好ましい。ファイルシステム１４８は、ファイルシステムは、特定のアイテムを参照するたびに、一貫して同一のあいまい性除去用の整数を使用するように、将来の参照のために一意のファイル名情報を保管する。ファイルシステム１４８は、単にファイルＩＤとともに使用された整数だけを保管し追跡することもできるし、一意の名前全体を保管することもできる。このようにして、レガシーアプリケーションは、アイテムを作成するかまたは最後に修正したクライアントによって最初に提供されたファイル名に非常に近い名前を表示し確認することになる。また、表示される名前空間は、レガシーアプリケーションを使用するとき、またはレガシーオペレーティングシステムからファイルシステム１４８にアクセスするときには、ユーザにとって見覚えのあるものになる。本発明の代替態様によれば、このファイルシステムは、あいまい性除去用の文字、記号、英数字、短い英数字列、または他の視覚的識別子を使用することができる。
【００６５】
ファイルシステム１４８は、一意のファイル名を生成するたびに一意のあいまい性除去用の整数を使用するので、ファイルシステム１４８は、アイテムの完全に限定された名前に加えて、ファイル領域のルートから、各あいまい性が除去されたアイテムへの一意のパスを生成することができる。例えば、アイテム１４０３はそのアイテムの完全に限定され、あいまい性が除去された名前、＼Ｐ１＼ＲｅａｄＭｅ１、またはそのアイテムのあいまい性が除去されたルートパス、＼ＲｅａｄＭｅ１によって参照することができる。同様に、アイテム１４０５は、＼Ｐ１＼ＲｅａｄＭｅ２、または＼ＲｅａｄＭｅ２によって参照することができる。クライアントがアイテムを見つけ出すための十分なコンテキストを有していない状況（例えば、クライアントがリストをブラウズ（閲覧）するのではなく、照会によってアイテムを見つける状況）では、追加のパスを使用することによりアイテムへの単純なパスを提供する。追加のパスはまた、アイテムの不揮発性の名前を提供する。例えば、ユーザがＰ１を経由してＲｅａｄＭｅ１をオープンする場合、オープン動作を実施するアプリケーションは、そのＭＲＵリストに保管された＼Ｐ１＼ＲｅａｄＭｅ１を使用する。しかしその後、ユーザがファイルシステム１４８の組織構造からアイテム１４０３を除去した場合には、上述のように、＼Ｐ１＼ＲｅａｄＭｅ１パスはもはや有効ではなく、オープン動作に失敗する。しかし、オープン動作の失敗を検出したときに、アプリケーションは、ファイル領域のルート（最上位のディレクトリ）からのパスを使用してファイルシステムにアイテムを照会することができ、それは成功することとなる。
【００６６】
本発明の一態様によれば、すべてのアイテムは、そのアイテムがもともとあいまいな名前を持っていたかどうかには関係なく、完全に制限されたパスの他に、ルートパスを持つことができる。例えば、編成テーブルはルートから各アイテムへの隠し保持リンク（ｈｉｄｄｅｎ ｈｏｌｄｉｎｇ ｌｉｎｋ）を格納することができる。このようにして、アプリケーションはルートから任意のアイテムを参照することができる。さらに、ルートから各アイテムに保持リンクを備えることにより、セキュリティ許可を伝達するために、組織構造を使用する実施形態において、基本レベルのセキュリティを提供する。また、すべてのアイテムに対するリンクのすべてを含む全体のセット（集合）を形成することによって、一意のあいまい性除去用の整数を容易に決定できるようになる。次いでファイルシステムは、例えば、各アイテムに、そのアイテムを参照するために使用できる一意の整数を割り当てることによって、ファイルシステムのルートからアドレス可能な全アイテムのあいまいさを無くすることができる。
【００６７】
あるアイテムのあいまい性除去用の整数または他の視覚的識別子は、そのアイテムがその後あいまいでない名前にリネーム（改名）された場合でも不変であることが好ましい。したがって、アプリケーションは、引き続きそのアイテムに割り当てられたあいまい性除去用の整数を用いてアイテムを要求し、オープンすることができるが、このことは現在既知のファイルシステムでは不可能である。例えば、本明細書に記載のあいまい性除去用の整数の機能を認識しているアプリケーションファイルシステムのクライアントは、最近使用されたアイテムのあいまい性除去用の整数情報をそれ自体で追跡し、格納することができる。ユーザが最近使用したアイテムをオープンするように要求したとき、そのアプリケーションクライアントは、ファイルシステムの組織構造内のそのアイテムの位置に関わらず、特定のあいまい性除去用の整数に対応するアイテムだけをファイルシステムに要求することができる。
【００６８】
本発明の一典型的態様によれば、ファイルシステムに格納されたアイテムが名前を持っていない場合には、ファイルシステム、オペレーティングシステム、および／またはアプリケーションは、アイテムの名前以外の情報を使用してユーザにファイルを提示することができる。例えば、デジタルカメラによって生成されたデジタル写真の場合には、一般にデジタルカメラは順次的な数値ファイル名を生成するので、ファイル名はほとんど使用されていない。本発明の諸態様を使用することにより、デジタルカメラがファイル名を提供する必要は全く無くなる。ファイルシステム、オペレーティングシステム、またはアプリケーションは、ユーザにファイルをサムネイル形式で提示し、ユーザはそこから所望のアイテムを選択してさらに使用することができる。
【００６９】
本発明を、現時点で本発明を実施する好ましいモードである特定の具体例に即して説明してきたが、当業者ならば、上述のシステムおよび技術に関する多数の変形形態および代替形態が存在することを理解されるはずである。したがって、本発明の趣旨および範囲については、添付の特許請求の範囲に記載されているように広く解釈すべきである。
【図面の簡単な説明】
【００７０】
【図１】本発明の一例示的実施形態によるメディアユーザインタフェースの実装に適する一般的な動作環境を示す図である。
【図２】既知のファイルシステムの一般的な組織構造を示す図である。
【図３】本発明の一例示的実施形態によるロケーションテーブル（ＬＯＣ）を示す図である。
【図４】本発明の一例示的実施形態による編成テーブル（ＯＲＧ）を示す図である。
【図５】図４に示された編成テーブルによる非循環有向グラフ（ＤＡＧ）組織構造を示す図である。
【図６】本発明の一例示的実施形態によるファイルシステムのブロック図である。
【図７】本発明の一例示的実施形態によるファイル領域を示す図である。
【図８】図７の組織構造を定義する編成テーブルを示す図である。
【図９】本発明の一例示的実施形態によるファイル領域を示す図である。
【図１０】図９の組織構造を定義する編成テーブルを示す図である。
【図１１】本発明の一例示的実施形態による編成テーブルを示す図である。
【図１２】図１１に示された編成テーブルによるファイル領域を示す図である。
【図１３】本発明の一例示的実施形態による、ファイルシステムに格納されたアイテムを管理する方法を示す流れ図である。
【図１４】本発明の一例示的実施形態によるファイルシステムの一部を示す概念構成図である。
【符号の説明】
【００７１】
１２０  処理ユニット
１２１  システムバス
１３０  システムメモリ
１３１  ＲＯＭ
１３２  ＲＡＭ
１３３  ＢＩＯＳ
１３４  オペレーティングシステム
１３５  アプリケーションプログラム
１３６  他のプログラムモジュール
１３７  プログラムデータ
１３８  ファイルシステム
１４０  取り外し不能不揮発メモリインタフェース
１４４  オペレーティングシステム
１４５  アプリケーションプログラム
１４６  他のモジュール
１４７  プログラムデータ
１４８  ファイルシステム
１５０  取り外し可能不揮発メモリインタフェース
１６０  ユーザ入力インタフェース
１６１  マウス
１６２  キーボード
１６５  デジタイザ
１７０  ネットワークインタフェース
１７１  ローカルエリアネットワーク
１７２  モデム
１７３  広域ネットワーク
１８０  リモートコンピュータ
１８５  アプリケーションプログラム
１９０  ビデオインタフェース
１９１  モニタ
１９５  出力周辺機器インタフェース
１９６  プリンタ
１９７  スピーカ
３０１  ＬＯＣテーブル
３０３  ファイルＩＤ
３０５  ファイル名
３０７  ボリューム
３０９  ロケーション
３１１  サイズ
４０１  ＯＲＧテーブル（編成テーブル）
４０３  親
４０５  子
６０１  ファイルシステムマネージャ
６０３  ＡＤＤ＿Ｉｔｅｍ  ＡＰＩ（アプリケーションプログラムインタフェース）
６０５  ＵＰＤＡＴＥ＿Ｉｔｅｍ  ＡＰＩ
６０７  ＤＥＬＥＴＥ＿Ｉｔｅｍ  ＡＰＩ
６０９  ＱＵＥＲＹ＿Ｉｔｅｍ  ＡＰＩ
１４０１  Ｐ１（ファイルＩＤ  ４１５）
１４０３  ＲｅａｄＭｅ（ファイルＩＤ  ４１６）
１４０５  ＲｅａｄＭｅ（ファイルＩＤ  ４１７）
１４０７  （ファイルＩＤ  ４１８）
【図１】
2006164288.tif 000003
【図２】
2006164288.tif 000004
【図３】
2006164288.tif 000005
【図４】
2006164288.tif 000006
【図５】
2006164288.tif 000007
【図６】
2006164288.tif 000008
【図７】
2006164288.tif 000009
【図８】
2006164288.tif 000010
【図９】
2006164288.tif 000011
【図１０】
2006164288.tif 000012
【図１１】
2006164288.tif 000013
【図１２】
2006164288.tif 000014
【図１３】
2006164288.tif 000015
【図１４】
2006164288.tif 000016