JPH09506195A - 拡張属性ファイルシステム - Google Patents

Abstract

(57)【要約】 本発明は、ファイルシステムを管理、保守、及び制御するために拡張属性（２１０）の定義、フォーマット、及び構造を提供する。このことは、ファイルシステムのディレクトリエントリ（１１０Ａ〜１１０Ｄ）に関連した、管理、保守、制御及びその他にユーザが規定するデータを含むデータベースを生成することによって、達成される。データベースは、１つ或いはセットになった拡張属性（２１０）の内部に記憶される。本発明によれば、各々の拡張属性（２１０）は、第１の複数のフィールド（３１０〜３１８）を備える拡張属性を規定するヘッダ（２１０Ａ）を含んでいる。各々の拡張属性は、データを記憶する複数のレコード（２１０Ｂ）も含んでいる。さらに、複数のレコードのうちの各レコードは、第２の複数のフィールド（３４０〜３４８）を備えている。拡張属性は、ファイルシステムのディレクトリエントリテーブル（１１０）のディレクトリエントリ（１１０Ａ〜１１０Ｄ）に記憶されたストリングによって特定される。ストリングは、本発明のデータベースアーキテクチャを有する拡張属性を示す所定のサブストリングを備えている。拡張属性の第１の複数のフィールドは、ヘッダ長（３１０）、へッダのバージョン番号（３１２）、ヘッダの改訂番号（３１４）、データベースにおける拡張属性の数（３１６）、及びデータベースにおける複数のレコードのレコード数（３１８）を含む。第２の複数のフィールドは、レコードのネーム（３４６）とデータ（３４８）とレコード長（３４０）とレコード名の長さ（３４２）とデータ長（３４４）とを記憶するフィールドを備えている。ネーム及びデータの双方は、ストリングスとして記憶される。

Description

【発明の詳細な説明】 拡張属性ファイルシステム 発明の背景 １．発明の分野 本発明は、拡張属性を使用するファイルシステムの分野に関する。２．背景技術 先行技術において、いくつかのオペレーティングシステムは、拡張属性（ＥＡ ）の概念をサポートしている。通常、先行技術の拡張属性は、「属性」すなわち データベースの内容を記憶するために使用される。 １９９３年６月８日にＢａｉｒｄらに対して発行された米国特許第５，２１８ ，６９６号に開示されている先行技術の方法は、ＵＮＩＸのトリーをベースにし たファイルディレクトリシステムにおいて、ファイルディレクトリを動的に拡張 し且つ高速にアクセスする方法を実行している。その技術は、少なくとも零レコ ードを有するファイルのネーム指向なアクセスを提供し、コンピュータに結合し ている外部記憶を通ったファイル及びレコードへのアクセスパスが、一対の関連 するディレクトリによって規定される。レコードエントリの属性ディレクトリは 、２部トークン上にソートされる。トークンは、レコードに割り当てられた固有 のシリアル番号と、親のレコードエントリに割り当てられた固有のシリアル番号 と、からなっている。各々のレコードエントリは、トークンと、ファイル或いは レコードのネームと、外部記憶のアドレス或いはポインタと、を含んでいる。ネ ームディレクトリは、属性ディレクトリのサブセットである。トークンを介した 横断路は、リーフをサーチ可能なＢトリーを構成する。ネームディレクトリは、 属性ディレクトリへの高速なアクセスを提供する。このように、Ｂａｉｒｄらは 、ファイルディレクトリを動的に拡張し且つ高速にアクセスする方法に関してい る。しかし、この先行技術は、拡張属性の内部にデータベースを生成及び記憶す ることによる、改良されたファイルシステムの管理、保守及び制御を提供する拡 張属 性のアーキテクチャを欠いている。 １９９２年５月１２日にＪｏｈｎｓｏｎらに対して発行された米国特許第５， １１３，５１９号に開示されている他の先行技術の方法は、分散データ処理シス テムのサーバデータ処理システムにて、ファイル属性を維持するシステム及び方 法を実行している。ファイル属性は、ファイルサイズ、改良時刻、及びアクセス 時刻を含んでいる。このシステム及び方法は、分散環境のプロセスをファイルに アクセスさせるプロトコルを提供する。ファイルは、システムコールを通じて、 或いはファイルを各プロセスのアドレス空間にマッピングするメカニズムを通じ て、アクセスされる。これによって、ファイルの属性は、関連するプロセスのす べてに分散される。属性は、分散環境の他の属性の各々からは別個に且つ独立し て維持される。Ｊｏｈｎｓｏｎらは、分散データ処理システムのサーバデータ処 理システムで、ファイルサイズ、改良時刻、及びアクセス時刻を維持するシステ ム及び方法に関する。しかし、この先行技術は、拡張属性の内部にデータベース を生成及び記憶することによって改良されたファイルシステムの管理、保守及び 制御を提供する拡張属性のアーキテクチャを欠いている。 先行技術は、拡張属性に名前を付けて情報を記憶できるが、拡張属性に情報を 記憶するアーキテクチャを規定していない。これより、先行技術は、拡張属性を 使用した高性能なファイル管理を提供しない。 本発明の要旨 本発明は、ファイルシステムを管理、保守及び制御するための拡張属性の定義 、フォーマット及び構成を提供する。このことは、ファイルシステムのディレク トリエントリに関連した、管理、保守、制御及びその他にユーザが規定するデー タを含むデータベースを生成することによって、達成される。データベースは、 １つ或いはセットになった拡張属性の内部に記憶される。 本発明によれば、各々の拡張属性は、第１の複数のフィールドを備える拡張属 性を規定するヘッダを含んでいる。各々の拡張属性は、データを記憶する複数の レコードも含んでいる。さらに、複数のレコードのうちの各レコードは、第２の 複数のフィールドを備えている。拡張属性は、ファイルシステムのディレクトリ エントリテーブルのディレクトリエントリに記憶されたストリングによって特定 される。ストリングは、本発明のデータベースアーキテクチャを有する拡張属性 を示す所定のサブストリングを備えている。拡張属性の第１の複数のフィールド は、ヘッダ長、ヘッダのバージョン番号、ヘッダの改訂番号、データベースにお ける拡張属性の数、及びデータベースにおける複数のレコードのレコード数を含 む。第２の複数のフィールドは、レコードのネームとデータとレコード長とレコ ード名の長さとデータ長とを記憶するフィールドを備えている。ネーム及びデー タの双方は、ストリングスとして記憶される。 図面の簡単な説明 図１は、ディレクトリエントリテーブルと拡張属性とを備えるファイルシステ ムを示す図である。 図２は、ヘッダとＮレコードのセットとを含む本発明の拡張属性を示す図であ る。 図３は、本発明の拡張属性の内部フォーマットを示す図である。 図４は、図３の拡張属性のヘッダフィールド及びレコードフィールドに使用さ れるデータのタイプを示す図である。 図５は、ＦＭＥＡデータベースを含み得るディレクトリエントリをサーチする 方法を示す流れ図である。 本発明の詳細な説明 拡張属性を使用してファイルシステム管理を提供する方法が述べられる。以下 の記載では、本発明のより十分な記述を提供するために、ファイルフォーマット やポインタなどの数々の特定の詳細が詳しく述べられる。しかし、本発明がこれ らの特定の詳細なしに実施し得ることは、当業者には明らかであろう。また、不 必要に本発明を不明確にしないように、既知の特徴は詳細には述べられない。拡張属性アーキテクチャをサポートするファイルシステム 本発明は、拡張属性のサポートでファイルシステム（例えば、ネットウェアフ ァイルシステムのバージョン３．Ｘ及びそれ以上のもの）を管理するアーキテク チャである。図１は、ファイルシステム、すなわちネットウェアファイルシステ ムのバージョン３．Ｘの典型を示す図である。ファイルシステム１０４は、ディ レクトリエントリテーブル１１０と拡張属性１２０、１３０及び１４０とを備え る。ディレクトリエントリテーブル１１０は、ディレクトリエントリ１１０Ａ〜 １１０Ｄを備えている。図１は、単一の拡張属性１２０或いは拡張属性１２０及 び１３０のリストが、各々のディレクトリエントリ１１０Ａ〜１１０Ｄに関連し 得ることを示している。ディレクトリエントリ１１０Ａ〜１１０Ｄは、ファイル システム１１０の中のファイル或いはディレクトリとして規定される。各々のデ ィレクトリエントリ１１０Ａ〜１１０Ｄの拡張属性は、ファイルシステム１０４ のユーザからは「隠されて」いて、通常はファイルシステム１０４のどのクライ アントからも「見えない」。アプリケーションソフトウエア及びオペレーティン グシステム（例えばＯＳ／２）は、拡張属性（例えば拡張属性１２０及び１３０ ）を使用して、ファイルについての情報を記憶する。この情報は、所有者やアプ リケーションに依存した情報を含む。 本発明は、ファイルシステム１０４を管理、保守及び制御する目的で、拡張属 性１２０及び１３０の定義、フォーマット、及び構成を、より明確に特定する。 これは、ディレクトリエントリ１１０Ａ〜１１０Ｄに関連した管理、保守、制御 、及びその他のユーザが規定するデータを含むデータベースを生成することによ って、実現される。データベースは、拡張属性１２０或いは拡張属性１２０及び １３０のセットの内部に記憶される。 以下の記載では、このアーキテクチャをサポートする拡張属性１２０及び１３ ０は、ファイル管理拡張属性（ＦＭＥＡ）として参照される。本発明のファイル システム１０４は、既知の長さのテキストストリングを有する拡張属性１２０、 １３０及び１４０を許容する。本発明の好適な実施形態では、テキストストリン グは、長さにして２５５キャラクタまでを備え得る。ＦＭＥＡアークテクチャを サポートしている拡張属性１２０及び１３０は、そのネームのはじめに「ＦＭＥ Ａ」というサブストリングを含むことを要求される。本発明は、サブストリング 「ＦＭＥＡ」に限られものではなく、本発明の範囲から逸脱することなく他のキ ャラクタの組み合わせも使用し得る。サブストリングの後には、ファイルシステ ム１０４の拡張属性のネーミング規定によって許されるキャラクタの組み合わせ が続き得る。「ＦＭＥＡ」でそのネームが始まるストリングを有する拡張属性は 、特定のディレクトリエントリのためのＦＭＥＡデータベースの一部とみなされ る。他の拡張属性がディレクトリエントリ１１０Ａ〜１１０Ｄに関連し得るが、 ＦＭＥＡアーキテクチャに従ったツール或いは方法によってはサポートされてい ない。例えば、ディレクトリエントリ１１０Ａの拡張属性１４０はサブストリン グ「ＸＹＺ１２３」で始まるネームを有し、ＦＭＥＡデータベースの一部ではな い。しかし、ディレクトリエントリ１１０Ｃの拡張属性１２０は、ＦＭＥＡデー タベースの一部である。拡張属性アーキテクチャを使用するデータベース ＦＭＥＡデータベースは、図２に示されるようにフォーマットされた１つまた はそれ以上のＦＭＥＡとして構成される。図２は、ＦＭＥＡ２１０が、ヘッダ２ １０Ａ及びＮレコードのセット２１０Ｂ（すなわち、レコード１からレコードＮ ）を含むことを示す図である。ディレクトリエントリ１１０ＤのＦＭＥＡ２１０ は、「ＦＭＥＡ ＴＷＯ」というネームで参照される。ヘッダ２１０Ａの後には 、一つまたはそれ以上のレコードのセット２１０Ｂが続く。このアーキテクチャ のためには、レコードのないＦＭＥＡはデータベースから削除される。すなわち 、もしＦＭＥＡ２１０がレコードを有していなければ、ＦＭＥＡ２１０はデータ ベースから削除される。図２は、データベースの内部構造を図示する。拡張属性の内部アーキテクチャ 図３は、ＦＭＥＡの内部フォーマットを示す図である。拡張属性２１０は、サ ブストリング「ＦＭＥＡ」で始まるそのネームが示すように、ＦＭＥＡである。 拡張属性２１０は、ヘッダ２１０ＡとＮレコードのセット２１０Ｂとを備えてい る。Ｎレコードのセット２１０Ｂは、レコード２を含んでいる。ヘッダ２１０Ａ とレコード２とが、（点線で示されて）詳細に示されている。 ヘッダ２１０Ａは可変長構造を有していて、長さフィールドの調整及びヘッダ 構造の末尾への付加的な情報の添付によって、拡張し得る。ヘッダ２１０Ａは、 フィールド３１０、３１２、３１４、３１６及び３１８を備えている。ヘッダ３ １０の長さはヘッダ構造の長さを（すなわちバイトで）特定し、拡張属性２１０ の中の第１のレコード（すなわち、レコード１）のオフセットを決定するために も使用される。フィールド３１２及び３１４は、ＦＭＥＡのバージョンと改訂と をそれぞれ記憶する。フィールド３１６は、データベースにおけるＦＭＥＡの数 を含んでいる。データベースにおける各々のＦＭＥＡは、そのヘッダのフィール ド３１６にこの数を記憶している。ＦＭＥＡ２１０のフィールド３１８は、デー タベースのすべての必要なＦＭＥＡの存在を決定する目的で使用される。レコー ドフィールド３１８の数は、フィールド３１６によって与えられるＦＭＥＡデー タベースのレコード総数というよりは、特定のＦＭＥＡ２１０の内部のレコード を意味する。 図３の拡張属性２１０は、レコード２を含むＮレコードのセット２１０Ｂを含 んでいる。ＦＭＥＡ２１０のレコード２は図３の詳細に示されていて、フィール ド３４０、３４２、３４４、３４６及び３４８を備えている。レコードフィール ド３４０の長さは、レコード構造の長さを（即ちバイトで）特定する。フィール ド３４２は、そのネームに、所定の数（例えば２５５キャラクタ）までのキャラ クタの数を特定するネームの長さを含んでいる。フィールド３４４は、レコード （すなわちレコード２）に含まれるデータ長を記憶する。フィールド３４６は、 特定のレコード（すなわち、この例ではレコード２）のネームを含む。ＦＭＥＡ ２１０のフィールド３４８は、レコード２に記憶されているデータを含む。 図４は、本発明の好適な実施形態において、図３のＦＭＥＡ２１０のためのヘ ッダ２１０Ａのフィールド３１０〜３１８及びレコードのフィールド３４０〜３ ４８に使用される特定のデータのタイプを示す図である。本発明の好適な実施形 態では、バイトは、符号無しの８ビットの整数として規定され、ワードは、符号 無しの１６ビットの整数として規定され、ｄワードは、符号無しの３２ビットの 整数として規定され、ストリングはバイトのシーケンスとして規定される。 ヘッダ２１０Ａのヘッダフィールド３１０の長さは、ヘッダ２１０Ａが６５、 ５３５バイトの長さ迄をとり得るようなワードデータタイプである。ＦＭＥＡの バージョン及び改訂のフィールド３１２及び３１４は、各々がダブルワード（す なわち、３２ビットの整数）である。データベースフィールド３１６におけるＦ ＭＥＡの数は、データベースが４ギガバイト（４ＧＢ）迄の拡張属性を含み得る ようなダブルワードである。レコードフィールド３１８の数は、拡張属性（すな わち、特定のＦＭＥＡ２１０）が６５、５３５レコードまでを含み得るようなワ ードである。 レコード２のレコードフィールド３４０の長さは、レコードが６５、５３５バ イトまでの長さであり得るようなワードデータタイプである。ネームフィールド ３４２の長さは、レコードネーム３４６（ストリング）が２５５キャラクタまで を含み得るバイトである。データフィールド３４４の長さは、データ３４８（ス トリング）が６５、５３５キャラクタまでを含み得るワードである。上述のよう に、ネームフィールド３４６及びデータフィールド３４８は、（それぞれ２５５ バイトまで及び６５、５３５バイトまでの）バイトのシーケンスである。拡張属性アーキテクチャを使用するデータベースの動作 図１〜４に示されている拡張属性のアーキテクチャ（ＦＭＥＡ）は、レコード ネーム３４６をサーチキーとして使用するディレクトリエントリ（すなわち、図 １のディレクトリエントリテーブル１１０のディレクトリエントリ１１０Ａ〜１ １０Ｄ）へのアクセスを提供するツール及び方法によって、使用され得る。例え ば、アプリケーションプログラムは、ファイルシステムが、図１のディレクトリ エントリ１１０Ａ〜１１０Ｄに「ワードプロセッシング」や「スプレッドシート 」などのアプリケーションのタイプの「標識を付ける」ことを認め得る。これに より、全ファイルシステム１０４は、「ワードプロセッシング」というタイプを 有するすべてのファイル及びディレクトリ（すなわち、ディレクトリエントリテ ーブル１１０のディレクトリエントリ１１０Ａ〜１１０Ｄ）をサーチされ得る。 「ワードプロセッシング」というストリングは、ファイルシステム１０４のファ イル及びディレクトリのためのＦＭＥＡデータベースの中のあるレコード（例え ば、図２〜４に示されるセット２１０Ｂのレコード２）のネームフィールド３４ ６に記憶される。これによって、ファイルシステム１０４の監督者は、例えば実 行可能ファイルとは対照的なテキストファイルによって使用される記憶空間を決 定し得る。「ワードプロセッシング」というタイプを有するファイル及びディレ クトリの検索という特定の例が示されているが、本発明がファイルシステム（例 えばノベルネットワーク環境）のファイル及びディレクトリの管理、保守及び制 御を実行するためのツール及び方法によっても使用され得ることは、当業者には 明らかであろう。 拡張属性アーキテクチャを提供する本発明は、ファイルシステムの監督者が、 コンピュータネットワーク環境（例えば、ノベルネットワーク環境）においてフ ァイル及びディレクトリを容易に管理することを可能にする。表１は、ノベルネ ットワークのユーティリティを使用し得る本発明のいくつかのアプリケーション を含んでいる。 ＮＣＯＰＹユーティリティは、ＦＭＥＡネーム３４６にマッチするすべてのフ ァイルをコピーする。ＮＤＩＲユーティリティは、ファイルシステム１０４の中 でＦＭＥＡレコードネーム（例えば、「ワードプロセッシング」）にマッチする ファイルのディレクトリ情報を表示する。ＳＭＳユーティリティは、ＦＭＥＡレ コードネーム３４６にマッチするディレクトリエントリ１１０Ａ〜１１０Ｄのバ ックアップコピーをとる。ＦＩＬＥＲユーティリティは、ＦＭＥＡデータベース 及びその内容の生成及び監督を行う。ＦＬＡＧユーティリティは、レコードネー ムをＦＭＥＡデータベースに追加する。これは、ファイル或いはディレクトリ（ ディレクトリエントリ１１０Ａ〜１１０Ｄ）にストリングで「標識を付ける」こ とによって実行される。 本発明は、ファイルのバージョン制御システムを実現するために使用され得る 。拡張属性アーキテクチャを使用すれば、バージョン制御システムは、ファイル のバージョン番号、ファイルが作成された日付、ファイルの所有者（或いは責任 者）、及びＦＭＥＡではないアプリケーションがファイルを改良したときを検知 するための電子フットプリントなどのファイル情報を追跡し続けることができる 。先行技術のバージョン制御システムは、特にソフトウエアファイルのリリース に関して非効率である。ＦＭＥＡアーキテクチャ及びファイルシステムユーティ リティを用いると、ソースコードのライブラリアンは、「リリース」というスト リングを使用してレコードネーム３４６にリリースファイルとして「標識を付け 」得る。ＮＣＯＰＹユーティリティが、例えばすべての「リリース」ファイルを コンパクトディスク（ＣＤ）に記憶のためにコピーするために使用され得る。先 行技術においては、この操作は「リリース」ファイルを手作業でコピーすること によって手作業で行われているが、これは速度が遅く非効率的である。これより 、本発明は、「リリース」ファイルをコピーする効率的な方法を提供する。 本発明の拡張属性（ＦＭＥＡ）アーキテクチャによれば、複数のＦＭＥＡデー タベースがファイルに関連させられる。アプリケーションプログラムは、アプリ ケーションプログラムが本発明のアーキテクチャに従っている限りは、アプリケ ーションプログラムによる使用のためのＦＭＥＡのセットを生成し得て、ファイ ルシステムのユーティリティ及び他のＦＭＥＡアプリケーション（及び方法）が それらをサポートし得る。本発明を使用したディレクトリエントリのサーチ 図５は、関連したＦＭＥＡデータベースを含み得るディレクトリエントリをサ ーチする方法を示す図である。図はさらに、ＦＭＥＡデータベースの各レコード を読みレコードのネーム及びデータをユーザに出力する方法を示している。図５ は、本発明に従ってファイルシステムの管理、保守及び制御のために拡張属性の 定義、フォーマット及び構造を使用するデータフローを示す例として、用いられ ている。処理は、ステップ５００で始まる。ステップ５０２で、ディレクトリエ ントリ（ＤＥ）が見つかる（例えば、ＤＥ１１０Ａ〜１１０Ｄ）。決定ブロック ５０４では、ディレクトリエントリが関連したＦＭＥＡデータベースを有してい るかどうかを決定するためのチェックが行われる。本発明の好適な実施形態では 、このチェックは、拡張属性のネームの開始サブストリングを見て、それが「Ｆ ＭＥＡ」を含んでいるかどうかを決定することによって行われる。拡張属性のネ ームが「ＦＭＥＡ」で始まっているときには、拡張属性はＦＭＥＡデータベース を含むと推定される。これより、決定ブロック５０４が偽（ｎｏ）を返すと、処 理は決定ブロック５１２に進む。決定ブロック５１２では、ファイルシステム（ 例えばファイルシステム１０４）にさらにディレクトリエントリがあるかどうか を決定するためのチェックが行われる。決定ブロック５１２が偽（ｎｏ）を返す と、処理はステップ５１４に進む。ステップ５１４で、処理は終了する。決定ブ ロック５１２が真（ｙｅｓ）を返すと、処理はステップ５０２に進む。決定ブロ ック５０４が真（ｙｅｓ）を返すと、処理はステップ５０６に進む。 ステップ５０６で、拡張属性のカウントが零にセットされる。ステップ５０８ で、ディレクトリエントリのＦＭＥＡがオープンされる（例えば、図１のＤＥ１ １０Ｃの拡張属性１２０）。ステップ５１０で、ＦＭＥＡデータベースのヘッダ が、データベースにおける拡張属性の数を得るために読まれる（例えば、図４に 示されるヘッダ２１０Ａのフィールド３１６）。ステップ５１６で、拡張属性の カウントがＦＭＥＡデータベースの中の拡張属性の数よりも小さいかどうかを決 定するためのチェックが行われる。決定ブロック５１６が偽（ｎｏ）を返すと、 処理は（上述した）決定ブロック５１２に進む。決定ブロック５１６が真（ｙｅ ｓ）を返すと、処理はステップ５１８に進む。 ステップ５１８で、ＦＭＥＡのヘッダが、特定の拡張属性の中のレコードの数 を得るために読まれる（すなわち、図３及び４に示されているヘッダ２１０Ａの フィールド３１８）。ステップ５２０で、拡張属性のネームがユーザに出力され る。ステップ５２２で、レコードのカウントが零にセットされる。決定ブロック ５２４で、レコードのカウントが拡張属性の中のレコードの数よりも小さいかど うかを決定するためのチェックが行われる。決定ブロック５２４が偽（ｎｏ）を 返すと、処理はステップ５３４に進む。ステップ５３４で、ＦＭＥＡデータベー スを含む他の拡張属性（ＦＭＥＡ）が得られる。ステップ５３６では、拡張属性 のカウントがインクリメントされる。処理は、決定ブロック５１６に進む。決定 ブロック５２４が真（ｙｅｓ）を返すと、処理はステップ５２６に進む。 ステップ５２６で、拡張属性のレコード（例えば、図３に示されている拡張属 性２１０のレコード２）が読まれる。ステップ５２８で、レコードのネーム（す なわち、図３及び４に示されているフィールド３４６）が出力される。ステップ ５３０で、レコードのデータ（すなわち、図３及び４に示されているフィールド ３４８）がユーザに出力される。レコードのネーム３４６及び／或いはデータ３ ４８が解釈或いは他の処理を必要とし得ることは、当業者には明らかであろう。 ステップ５３２で、レコードのカウントがインクリメントされる。処理は、決定 ブロック５２４に進む。 このようにして、ファイルシステムの管理、保守、及び制御のために拡張属性 の定義、フォーマット、及び構造を提供する方法が開示される。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＭＷ，ＳＤ，ＳＺ)，ＡＭ， ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，Ｃ Ｎ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＨＵ ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＴ， ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ，Ｎ Ｚ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＩ，ＳＫ ，ＴＪ，ＴＴ，ＵＡ，ＵＺ，ＶＮ 【要約の続き】 備えている。拡張属性の第１の複数のフィールドは、ヘ ッダ長（３１０）、へッダのバージョン番号（３１ ２）、ヘッダの改訂番号（３１４）、データベースにお ける拡張属性の数（３１６）、及びデータベースにおけ る複数のレコードのレコード数（３１８）を含む。第２ の複数のフィールドは、レコードのネーム（３４６）と データ（３４８）とレコード長（３４０）とレコード名 の長さ（３４２）とデータ長（３４４）とを記憶するフ ィールドを備えている。ネーム及びデータの双方は、ス トリングスとして記憶される。

Claims (1)

1. 【特許請求の範囲】 １．複数のディレクトリエントリを有するファイルシステムの拡張属性に含まれ るデータベースをナビゲートする方法であって、該方法は、 （ａ） ファイルシステムの内部の該複数のディレクトリエントリの一つを読 むステップと、 （ｂ） 拡張属性が該ディレクトリエントリに関連しているかを決定し、もし そうであるならば、ステップ（ｃ）に進むステップと、 （ｃ） 該拡張属性の第１のフィールドを調べるステップであって、該第１の フィールドが該ディレクトリエントリに関連している拡張属性の数を示している 、ステップと、 （ｄ） 該拡張属性に記憶されているレコードの数を該拡張属性の第２のフィ ールドから読むステップと、 （ｅ） 該拡張属性のレコードを調べるステップと、 （ｆ） 該拡張属性の調べられたレコードの第１のカウンタをインクリメント するステップと、 （ｇ） 調べられたレコードの該カウンタの値を該拡張属性に記憶されている レコードの該数と比較するステップと、 （ｈ） 調べられたレコードの該カウンタの値が該拡張属性に記憶されている レコードの数よりも小さいならば、ステップ（ｅ）からステップ（ｇ）を繰り返 すステップと、 （ｉ） 該複数のディレクトリエントリの残りに対してステップ（ａ）からス テップ（ｈ）を繰り返すステップと、 を包含している、方法。 ２．前記複数のディレクトリエントリがファイルのためのエントリとサブディレ クトリのためのエントリとを備えている、請求項１に記載の方法。 ３．前記拡張属性のレコードを調べる前記ステップが、 該レコードのデータを調べるステップと、 該レコードの該データをユーザによって特定されるレコード選択規準と比較す るステップと、 該データが該規準に適合するならば、該レコードの該データを該ユーザに供給 するステップと、 を包含している、請求項１に記載の方法。 ４．前記拡張属性の第１のフィールドを調べる前記ステップが、 前記第１のディレクトリエントリのために調べられた拡張属性のカウンタをイ ンクリメントするステップと、 調べられた拡張属性の該カウンタの値を該ディレクトリエントリに関連する拡 張属性の前記数と比較するステップと、 調べられた拡張属性の該カウンタの該数が拡張属性の該数と等しいならば、該 ディレクトリエントリに関連した他の拡張属性を読まないステップと、 を包含する、請求項１に記載の方法。 ５．前記拡張属性の第１のフィールドを調べる前記ステップが、該拡張属性のヘ ッダを調べるステップを含み、該ヘッダは該ヘッダの長さを特定するデータを備 えている、請求項１に記載の方法。 ６．前記ヘッダが前記第１のフィールド及び前記第２のフィールドを備えている 、請求項５に記載の方法。 ７．前記拡張属性の前記レコードの各々が前記レコードの長さを特定するデータ を備えている、請求項６に記載の方法。 ８．前記拡張属性の第１のレコードの冒頭が前記ヘッダの前記長さを特定する前 記データから決定されて、該拡張属性の引き続くレコードの冒頭が該第１のレコ ードの該長さを特定する該データから決定されている、請求項７に記載の方法。 ９．ファイルシステムのディレクトリエントリに関連した拡張属性からデータを 読む方法であって、該方法は、 （ａ） 第１のディレクトリエントリを読んで、第１のＦＭＥＡコンプライア ントな拡張属性が該第１のディレクトリエントリに関連しているどうかを決定す るステップと、 （ｂ） 該第１のＦＭＥＡコンプライアントな拡張属性の第１のフィールドを 調べるステップであって、該第１のフィールドは該第１のディレクトリエントリ に関連したＦＭＥＡコンプライアントな拡張属性の数を示している、ステップと 、 （ｃ） 該第１のＦＭＥＡコンプライアントな拡張属性の第２のフィールドを 調べるステップであって、該第２のフィールドは該第１のＦＭＥＡコンプライア ントな拡張属性に記憶されたレコードの数を示している、ステップと、 （ｄ） 該第１のＦＭＥＡコンプライアントな拡張属性に記憶されているレコ ードを読むステップと、 を包含している、方法。 １０．（ｅ）前記第１のＦＭＥＡコンプライアントな拡張属性の残りのレコード を読むステップをさらに包含する、請求項９に記載の方法。 １１．（ｆ）前記第２のフィールドを調べて、前記第１のディレクトリに関連し た残りのＦＭＥＡコンプライアントな拡張属性のレコードを読むステップをさら に包含する、請求項１０に記載の方法。 １２．（ｇ）前記ファイルシステムの残りのディレクトリエントリに対してステ ップ（ａ）から（ｆ）を繰り返すステップをさらに包含する、請求項１１の方法 。 １３．前記ステップ（ｄ）が、前記第１のレコードに記憶されていたデータをユ ーザに表示するステップをさらに包含する、請求項９に記載の方法。 １４．ファイルシステムの中のディレクトリエントリの拡張属性にデータベース を記憶する方法であって、該方法は、 複数の拡張属性をファイルシステムのディレクトリエントリに関連付けるステ ップであって、該複数の拡張属性の各々が該ディレクトリエントリに関連した該 複数の拡張属性の数を示す第１のフィールドを備えている、ステップと、 該ディレクトリエントリに関連した該複数の拡張属性の各々に任意の内容の任 意の数のレコードを記憶するステップと、 を包含する、方法。 １５．前記複数の拡張属性がネームを有していて、複数の拡張属性をディレクト リエントリに関連付ける前記ステップが、該複数の拡張属性の該ネームの中のあ らかじめ規定されたテキストストリングを用いるステップを含み、該テキストス トリングは、該複数の拡張属性をＦＭＥＡコンプライアントなアーキテクチャを 有していると特定する、請求項１４に記載の方法。 １６．前記複数の拡張属性の各々が、該複数の拡張属性の各々に記憶されている レコードの数を示す第２のフィールドを備えている、請求項１４に記載の方法。