JPH0812628B2 - ファイルシステム装置およびその操作方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はコンピュータシステムに
関し、特に、そのファイルシステムへのアクセスに関す
る。

【０００２】

【従来の技術】今日存在するオペレーティングシステム
は、ユーザが、ファイルの１個以上のデータストリーム
にアクセスすることを可能にするファイルシステムを有
する（データストリームとは、データバイトの列であ
る）。例えば、アップルのマッキントッシュの「階層フ
ァイルシステム」では、２個のデータストリームがファ
イルごとにサポートされる。一方はデータフォークと呼
ばれ、他方はリソースフォークと呼ばれる。（アップル
（Ａｐｐｌｅ）およびマッキントッシュ（Ｍａｃｉｎｔ
ｏｓｈ）はアップルコンピュータ社の登録商標であ
る。）

【０００３】プログラマは、ストリームをオープンする
ために、ファイル名とビットパラメータの組合せによっ
て特定のストリームを選択してから、そのデータストリ
ームに対する操作をするために従来のファイルシステム
コール（例えば、ｒｅａｄ（），ｗｒｉｔｅ（），ｌｓ
ｅｅｋ（）など）を使用する。残念ながら、新しいフォ
ーク（データストリーム）がファイルシステムに付加さ
れ、その結果新しいビットパラメータが必要とされる場
合、現存のプログラムは新しいデータストリームへのア
クセスを許可するために書き直さなければならない。こ
のようなプログラムの書き直しはユーザにとって高価な
オーバヘッドとなる。

【０００４】ＩＢＭから入手可能なＯＳ／２オペレーテ
ィングシステムはもう１つの階層ファイルシステムであ
る。（ＯＳ／２はインターナショナル・ビジネス・マシ
ーンズ社の登録商標である。）ＯＳ／２によって提供さ
れる「高性能ファイルシステム」もまた、ファイルごと
に２個のデータストリームをサポートする。一方は通常
のファイルデータを含み、他方はこのファイルに付随す
る拡張属性情報を含む。ＯＳ／２では、２個のデータス
トリームをそれぞれ操作するために、異なるオペレーテ
ィングシステムコールを使用する。個のような配置は、
新しいデータストリームが付加された場合にオペレーテ
ィングシステムコールの別々のセットを必要とする。残
念ながら、新しいデータストリームがＯＳ／２のレパー
トリに付加された場合、現存のプログラムは書き直さな
ければならない。

【０００５】

【発明が解決しようとする課題】現存のオペレーティン
グシステムコールおよびコマンドと互換性のある方法
で、任意のファイルのますます増大する数のデータスト
リームにオペレーティングシステムがアクセスすること
を可能にし、それによって現存のプログラムを書き直す
必要を除去する技術が所望される。

【０００６】

【課題を解決するための手段】本発明の装置および方法
によれば、ファイルシステムは、ベース名および少なく
とも１つの付加セグメントを含むように定義されたファ
イル名を使用して、以前に格納されたデータファイルに
アクセスする。付加セグメントは、ベース名の前置子、
後置子またはその両方である。ファイルアクセス要求を
受容すると、ファイル名がベース名およびセグメントへ
と解析される。

【０００７】ベース名は、所望のファイルを取得するた
めに、格納されているファイルを検索するために使用さ
れる。続いて付加セグメントが、所望のベース名のファ
イルに付随するデータストリームにアクセスするために
選択される。このように、本発明は、現存のオペレーテ
ィングシステムコールおよびユーザレベルコマンドと互
換性のある方法で、任意のファイルのデータストリーム
にファイルシステムがアクセスすることを可能にし、そ
れによって現存のプログラムを書き直す必要を除去す
る。

【０００８】本発明の他の特徴によれば、付加セグメン
トは、格納されているファイルの属性にアクセスするた
めに、また、特定のデータストリームを処理するために
使用されるようなオペレーティングシステムを指定する
ために使用される。

【０００９】

【実施例】図１は、ＵＮＩＸオペレーティングシステム
１１０の制御下で動作するコンピュータベースファイル
システム１００を、高水準アーキテクチャ階層図を使用
して示したものである。（ＵＮＩＸは、ＵＮＩＸシステ
ム・ラボラトリーズ社（ＵＳＬ）の登録商標である。）
階層図は、ユーザレベル１２０、カーネルレベル１３
０、およびハードウェアレベル１４０を含む。ユーザレ
ベル１２０は、記憶装置（例えばディスク１８０）に格
納された所望のファイルを取得するためにファイルシス
テムにアクセスすることが可能なように、ユーザ１０１
とインタフェースする。

【００１０】ユーザレベル１２０は、ユーザプログラム
１２１およびライブラリ１２２を含む。ハードウェアレ
ベル１４０は、オペレーティングシステム１１０に、コ
ンピュータ１００によって必要とされる基本的サービス
を提供する。カーネルレベル１３０は、ハードウェアレ
ベル１４０と直接対話し、ユーザレベル１２０プログラ
ムへ共通サービスを提供し、ハードウェア特異性からユ
ーザレベル１２０プログラムを隔離する。

【００１１】システムを階層の集合として見た場合、オ
ペレーティングシステムは、ユーザプログラムからの独
立を強調して、通常、システムカーネル１３０、または
単にカーネルと呼ばれる。ユーザプログラムは下部のハ
ードウェアとは独立であるため、異なるハードウェア上
で動作するＵＮＩＸシステム間でユーザプログラムを移
動することは容易である。ＵＮＩＸオペレーティングシ
ステムの周知の動作の一般的説明は、モーリス・Ｊ．バ
ック著「ＵＮＩＸオペレーティングシステムの設計」の
第２章から導かれる。

【００１２】システムコールインタフェース１３１は、
ユーザレベル１２０（ユーザプログラム１２１およびプ
ログラムライブラリ１２２）とカーネルレベル１３０の
間の境界を表す。システムコールインタフェース１３１
は、ユーザプログラムコールをＵＮＩＸシステムコール
に変換する。システムコールはＣプログラムにおける通
常のファンクションコールのように見え、ライブラリ
は、このファンクションコールを、周知の方法で、オペ
レーティングシステムに入るために必要なプリミティブ
にマップする。

【００１３】システムコールの集合は、ファイルシステ
ムドライバ１３２と対話するシステムコール、および、
プロセス制御サブシステム１３３と対話するシステムコ
ールを含む。ファイルシステムドライバ１３２は、ファ
イル空間を割り当て、ファイルへのアクセスを制御し、
ユーザのためにデータを検索するなどのファイル管理を
行う。プロセスは、ｏｐｅｎ（読み出しまたは書き込み
のためにファイルをオープンする）、ｃｌｏｓｅ、ｒｅ
ａｄ、ｗｒｉｔｅ、ｓｔａｔ（ファイルの属性を照会す
る）、ｃｈｏｗｎ（ファイルの所有者の記録を変更す
る）、および、ｃｈｍｏｄ（ファイルのアクセス許可を
変更する）のような、特殊なシステムコールの集合によ
ってファイルシステムドライバ１３２と対話する。

【００１４】ファイルシステムドライバ１３２は、カー
ネルと補助記憶装置の間のデータフローを調整するバッ
ファ１３６を使用してファイルデータにアクセスする。
バッファリング機構は、カーネルとの間のデータ転送を
開始するために、ブロックＩ／Ｏデバイスドライバ１３
７と対話する。デバイスドライバ１３４は、周辺装置の
動作を制御するカーネルモジュールである。

【００１５】ブロックＩ／Ｏデバイス１４１は、ランダ
ムアクセス記憶装置である。または、ブロックＩ／Ｏデ
バイス１４１のデバイスドライバ１３７が、システムの
他の部分に対して、デバイス１４１をランダムアクセス
記憶装置のように見せる。例えば、テープドライバは、
カーネルが、テープ装置をランダムアクセス記憶装置と
して扱うことを可能にする。ファイルシステムはまた、
バッファリング機構の介入なく、「生の」すなわちキャ
ラクタＩ／Ｏデバイスドライバ１３８とも直接対話す
る。生のデバイスは、時にキャラクタＩ／Ｏデバイス１
４２と呼ばれるが、ブロックデバイス以外のすべてのデ
バイスを含む。

【００１６】プロセス制御サブシステム１３３は、プロ
セス同期、プロセス間通信、メモリ管理、およびプロセ
ススケジューリングを行う。ファイルシステムドライバ
１３２およびプロセル・システム制御サブシステム１３
３は、実行のためにメモリにファイルをロードする際に
対話する。プロセス制御サブシステム１３３は、実行前
に、実行可能ファイルをメモリに読み込む。

【００１７】プロセスを制御するためのシステムコール
には、ｆｏｒｋ（新たなプロセスを作成する）、ｅｘｅ
ｃ（プログラムのイメージを実行中のプロセス上にオー
バレイする）、ｅｘｉｔ（プロセスの実行を終了す
る）、ｗａｉｔ（プロセスの実行を、以前にｆｏｒｋさ
れたプロセスのｅｘｉｔと同期させる）、ｂｒｋ（プロ
セスに割り当てられたメモリのサイズを制御する）、お
よびｓｉｇｎａｌ（異常事態に対するプロセスの応答を
制御する）がある。

【００１８】前記のように、ファイルシステム１００は
ディスク１８０上に格納されたファイルにユーザがアク
セスすることを可能にする。「ファイル」は、１個以上
のデータストリームを含み、所有者および許可その他の
属性ならびに１個以上のファイル名を有する論理情報オ
ブジェクトとみなされる。データストリームは、独立な
データバイトの列と見なされ、マシン上の他のデータス
トリームとは独立に拡大縮小することができる。例え
ば、次のものはファイル操作である：ｒｅｎａｍｅ、ｌ
ｉｎｋ、所有者変更、グループ所有者変更、モード変
更。次のものはデータストリーム操作である：ｒｅａ
ｄ、ｗｒｉｔｅ、および（データストリームの一部の）
ｌｏｃｋ。

【００１９】図１、２および３を合わせて参照しなが
ら、ファイルシステムの概要を説明する。あらゆるファ
イルには、１個以上のパス名３１０によって名前が付け
られる。パス名３１０は、デリミタ（／）によって分離
されたファイル名（例えばｈｏｍｅ）を含む。ファイル
の内部表現はｉノードによって与えられる。

【００２０】ｉノードは、ファイルデータのディスク様
式の記述およびその他の情報、例えば、ファイル所有
者、アクセス許可、およびアクセス回数などを含む。ｉ
ノードという用語は、インデックスノードという用語を
短縮したものであり、ＵＮＩＸシステムに関する文献で
一般的に使用されている。あらゆるファイルは、１個の
ｉノードを有するが、いくつかのパス名を有することが
可能であり、それらのパス名はすべてその１個のｉノー
ドにマップされる。

【００２１】各パス名はリンクと呼ばれる。プロセスが
パス名によってファイルを参照すると、カーネルは、１
度に１ファイル名成分ずつパス名を解析し、プロセスが
そのパス内のディレクトリを検索する許可を有すること
をチェックし、最終的にそのファイルに対するｉノード
を取り出す。例えば、プロセスがコール「ｏｐｅｎ（／
ｈｏｍｅ／ｊｑｐ）」をすると、カーネルは「／ｈｏｍ
ｅ／ｊｑｐ」に対するｉノードを取り出す。

【００２２】３１５のように、完全パス名に対する「フ
ァイルシステムツリー」はスラッシュ文字（「／」）で
始まり、そのパス名がファイルシステムツリーの「ルー
ト」に関係することを指定する。パス名の後続の成分名
につながる分枝に従うと、「／ｈｏｍｅ／ｊｑｐ／２＠
ｍｅｍｏｉｒｓ」は完全パス名を表すが、「／ｊｑｐ／
２＠ｍｅｍｏｉｒｓ」はそうではない。パス名の最初の
スラッシュを取り除くことにより、パス名はルートから
始まる必要はなく、実行中のプロセスの「カレントディ
レクトリ」に関係することを表すことができる。従っ
て、カレントディレクトリ「／ｈｏｍｅ」から始まる
と、パス名「Ｂｉｎ」は、完全パス名が「／ｈｏｍｅ／
Ｂｉｎ」であるファイルを表すことになる。

【００２３】本発明によれば、ファイル名３２０すなわ
ち全ファイル名は、前置子、ベース名および後置子を含
むものとみなすことができ、ベース名によって指定され
る特定のファイル（ファイルシステムオブジェクト）の
別々のデータストリームを選択するために使用すること
が可能である。ベース名３３０は、図３に示すように、
（一般にディレクトリに格納された）従来の「物理」フ
ァイル名３３１、所定の構文３３２、または非部分文字
列ベースの名前３３３である。これらは、同一出願人に
よる同日の特許出願に記載されている。

【００２４】プロセスが新たなファイルを作成すると、
ファイルシステムドライバ１３２はそのファイルに未使
用のｉノードを割り当てる。ｉノードは、すぐ後で説明
するように、物理ファイルシステム２２０のセクション
２２３に格納されるが、ファイルシステムドライバ１３
２は、ファイルを操作する際にはｉノードをインコアメ
モリｉノードテーブルに読み込む。

【００２５】ＵＮＩＸシステムは一般的にレギュラーフ
ァイルおよびディレクトリをディスクのようなブロック
デバイス上に保持する。それぞれ１個以上のファイルシ
ステムを含むいくつかの物理ディスク装置を有するよう
な設置もある。ファイルシステム２２０は、論理ブロッ
クの列として編成され、各ブロックは、システムの実現
に依存して、５１２、１０２４、２０４８、または任意
の都合の良い５１２バイトの整数倍のバイト数からな
る。５１２の倍数の使用は慣例によるものであり、５１
２バイトのブロックを使用する本質的理由はない。

【００２６】物理ファイルシステムは、図２の２２０に
図示される物理構造を有する。ブートブロック２２１
（一部のファイルシステムのみに存在）は、ファイルシ
ステムの最初（一般に第１セクタ）を占有し、オペレー
ティングシステムをブート、すなわち初期化するために
マシンに読み込まれるブートストラップコードを含む。
システムをブートするにはただ１つのブートブロックが
あればよいが、あらゆるファイルシステムが（おそらく
は空の）ブートブロックを有することもある。

【００２７】スーパーブロック２２２は、ファイルシス
テムの状態（大きさ、格納可能ファイル数、ファイルシ
ステム上の空きスペースの位置、などの情報）を記述す
る。ｉノードリスト２２３は、ファイルシステム内でス
ーパーブロックの後に続く、ｉノードのリストである。
管理者は、ファイルシステムを設定する際にｉノードリ
スト２２３のサイズを指定する。ファイルシステムドラ
イバ１３２は、ｉノードリスト２２３へのインデックス
によってｉノードを参照する。

【００２８】１つのｉノードはファイルシステムのルー
トｉノードである。このｉノードによって、ｍｏｕｎｔ
システムコールの実行後にファイルシステムのルートデ
ィレクトリ構造がアクセス可能になる。データブロック
２２４は、ｉノードリストの最後から始まり、データス
トリーム（すなわち、ファイルデータ）の内容を保持す
る。割り当てられたデータブロックは、ファイルの実際
のデータを含み、ファイルシステム内のただ１つのファ
イルに属することができる。

【００２９】本発明の動作は、仮想ファイルシステムを
使用してＵＮＩＸシステム上に実現された拡張ファイル
システム（ＥＦＳ）において利用されるものとして説明
する。一部のＵＮＩＸシステムは、全ファイルシステム
操作を編成するために仮想ファイルシステム（ＶＦＳ）
の概念を使用している。本発明はＶＦＳ機構を必要とし
ないが、ＶＦＳは本発明を説明する便利な概念的モデル
を提供する。ＶＦＳは、システムＶファイルシステムス
イッチ（ＦＳＳ）とＳＵＮ ＯＳ ＶＦＳ機構の合併で
ある。ユーザプログラムは、ＳＶＲ４．０ＶＦＳアーキ
テクチャによって影響を受けないことに注意すべきであ
る。

【００３０】ＶＦＳは、ファイルシステム型とは独立
の、プログラムおよびユーザとのインタフェースを提供
しつつ、個々のファイルシステムが個々の方法でファイ
ルシステム操作を処理することを可能にする。ファイル
システム型に依存するカーネルルーチンは、その種類に
特有の作業を実行する。

【００３１】ＶＦＳの重要な長所は、サードパーティー
のソフトウェアハウスによって、新たなファイルシステ
ム型が定義され実現されることが可能なことである。Ｖ
ＦＳを構成するカーネルインタフェースの集合は、ＵＳ
Ｌから入手可能なＶＦＳファイルシステム型作成者ガイ
ドで利用可能である。

【００３２】本発明は、特殊なファイル名によって、現
存のＵＮＩＸシステムと互換性のある方法で各データス
トリームにアクセスすることを可能にする。この特殊な
ファイル命名方式は、ベース名および前置子、後置子ま
たはその両方を含むファイル名を使用する。さらに、本
発明は、ファイル名によってファイルにアクセスする任
意のオペレーティングシステムとともに利用可能であ
る。

【００３３】本発明の能力の概観を、例として、前置子
およびベース名のみからなるファイル名に関して説明す
ることにする。明らかに、同じ能力を得るために、ベー
ス名および後置子の組合せ、または、前置子、ベース名
および後置子の組合せを使用したファイル名もまた使用
することができる。

【００３４】本発明は、拡張ファイルシステム（ＥＦ
Ｓ）で利用されているように、非デフォルトデータスト
リームへのアクセスを可能にするために、ファイル名前
置子文字列を使用する。例えば、デフォルトのＥＦＳの
設定では次のように動作する：ファイル名「ｆｏｏ」
は、ファイル「ｆｏｏ」のデフォルト（第０番目）のス
トリームにアクセスする。

【００３５】すなわち、「ｆｏｏ」の前に前置子がない
場合はデフォルトまたはヌル（第０番目）のデータスト
リームにアクセスし、ファイル名「１＠ｆｏｏ」はファ
イル「ｆｏｏ」の第１ストリームにアクセスし、ファイ
ル名「２＠ｆｏｏ」はファイル「ｆｏｏ」の第２ストリ
ームにアクセスし、ファイル名「３＠ｆｏｏ」はファイ
ル「ｆｏｏ」の第３ストリームにアクセスし、などとな
る。この前置子方式により、現存のＵＮＩＸアプリケー
ション（例えば、ｖｉ（１）、ｓｈ（１））およびサー
ビス（例えば、遠隔ファイルシステム（ＲＦＳ））によ
ってすべてのストリームを操作することができる。

【００３６】こうした多重データストリームの１つの使
用法は、複数のクライアントオペレーティングシステム
のサポートである。例えば、マッキントッシュのＨＦＳ
およびＯＳ／２の高性能ファイルシステム（ＨＰＦＳ）
はいずれもファイルごとに２つのデータストリームをサ
ポートする。マッキントッシュのＨＦＳおよびＯＳ／２
のＨＰＦＳのいずれにおいても、リソースフォークおよ
び拡張属性データが、アイコン、フォント、履歴、主題
情報、アプリケーション固有の設定パラメータなどのよ
うなデータを保持するために使用される。

【００３７】本発明を利用すれば、ＵＮＩＸベースのフ
ァイルシステムは、次のようにして、異種のクライアン
トマシン（例えば、マッキントッシュとＯＳ／２）に対
するファイルサーバをサポートすることができる：スト
リーム０（例えば２１２）が共有（正規）データを含
む；ストリーム１（例えば２１３）がマッキントッシュ
のリソースフォークを含む；ストリーム２（例えば２１
４）がＯＳ／２の拡張属性データを含む；他のストリー
ム（例えば２１５）が、ＵＮＩＸシステムのような他の
オペレーティングシステムの補助データまたは拡張属性
のために使用される。

【００３８】ファイルシステム１３２は各ストリームを
追跡し、それらがアクセスされる場合にそれぞれ独立で
あってファイル操作（例えば、ファイル名変更、所有者
変更、．．．）と一貫性があることを保証する。

【００３９】これから、図１の階層図を参照しながら、
本発明の動作のさらに詳細な説明をする。

【００４０】図１および４をともに参照して、本発明の
動作を詳細に説明する。本発明は、パス名をｖノードに
変換する間に起こる標準的参照パス名機能の一部とし
て、ファイルシステム特有の参照機能を実行するように
実現される。本発明によれば、単一のｉノードが複数の
データストリームを含むことが可能となるため、ｖノー
ドという用語は特定のデータストリームに付随する仮想
ノードを指すために使用する。従って、ファイルごとに
４個のデータストリームがあれば、ｉノードごとに４個
のｖノードがあることになる。特に断らない限り、ｖノ
ードとはファイルの第０番目のデータストリームを指
す。

【００４１】ファイルへの最初のアクセスは、ｏｐｅ
ｎ、ｃｈｄｉｒ（ディレクトリ変更）、またはｌｉｎｋ
システムコールの場合と同様に、パス名による。カーネ
ル１３０は、内部的にはパス名ではなくｖノードで作業
するため、カーネルは、ファイルにアクセスするために
パス名をｖノードに変換する。ＵＮＩＸシステムカーネ
ルのアルゴリズムは、パス名を１度にファイル名の１成
分だけ解析し、各成分を名前に基づいてｖノードに変換
し、ディレクトリを探索し、最後に入力パス名のｖノー
ドを返す。

【００４２】本発明の詳細な動作は一般的な動作コンテ
クストで説明される（図５）ため、ステップ４０１〜４
２５およびステップ４２９〜４３９は、パス名をｖノー
ドに変換する現在のステップを簡単に説明している。

【００４３】ユーザプログラム１２１がプロセスコー
ル、例えばｏｐｅｎ（パス名、ｏｐｅｎ ｖノードフラ
グ）、を実行すると、オペレーティングシステムカーネ
ル（以後カーネル）１３０は、ステップ４０１で、コマ
ンドｖｎ＿ｏｐｅｎ（ｎａｍｅ，ｓｅｇ，ファイルモー
ド、作成モード、ｖｐｐ，ｃｒｗｈｙ）を生成する。

【００４４】コマンドｖｎ＿ｏｐｅｎは許可チェックを
実行し、ｎａｍｅによってファイルをオープンし、結果
のｖノードへのポインタを返す。コマンドｖｎ＿ｏｐｅ
ｎにおいて、パラメータｎａｍｅはパス名を含む。ｓｅ
ｇはファイル名の存在するアドレス空間（ユーザ空間ま
たはカーネル空間のいずれか）である。ファイルモード
はオープンモードである。作成モードは、ファイルが作
成される場合の許可ビットを含む。ｖｐｐは結果のｖノ
ードポインタへのポインタである。ｃｒｗｈｙは、この
ルーチンが呼び出される理由であり、ファイルモードの
Ｆｃｒｅａｔｅビットがセットされている場合に限り定
義される。

【００４５】ステップ４０２では、ファイル名がユーザ
プログラム１２１から受容される。ステップ４０３で、
カーネル１３０は、Ｆｃｒｅａｔｅビットがセットされ
ているかどうかをチェックする。セットされている場
合、ステップ４０５で、コマンドｖｎ＿ｃｒｅａｔ
ｅ（）が従来の方法で生成される。ｖｎ＿ｃｒｅａｔｅ
のコマンドは、カーネル１３０に対し、プロセスコール
が新たなファイルの作成を希望していることを知らせ
る。この動作は周知であり、本発明の理解にとっては重
要でない。

【００４６】Ｆｃｒｅａｔｅビットがセットされていな
い場合、ステップ４０７で、パスが存在するかどうかを
決定するためにパス名がチェックされる。例では、パス
名は「／ｈｏｍｅ／ｊｑｐ／２＠ｍｅｍｏｉｒｓ」であ
った。パス名がヌルの場合、ステップ４０９で、「エン
トリが見つからない」エラーがシステムユーザに返され
る。

【００４７】パス名がヌルでない場合、ステップ４１１
で、パス名中の後続デリミタすなわちスラッシュが除去
される。（例では、「ｍｅｍｏｉｒｓ」の後に後続スラ
ッシュはない。）ステップ４１３で、「ｎａｍｅ」の第
１文字が「／」文字（パス名がルートから開始すること
を示す）である場合、作業ディレクトリがルートにセッ
トされる。その他の場合は、作業ディレクトリはカレン
トディレクトリにセットされる。ステップ４１５で、作
業ディレクトリがディレクトリであるかどうかが判定さ
れる。ディレクトリでない場合、ステップ４１７で、
「ディレクトリでない」エラーがユーザに返される。作
業ディレクトリがディレクトリである場合、ステップ４
１９で、先頭ファイル名成分（すなわち、例では「ｈｏ
ｍｅ」）がパス名から取り出される。

【００４８】ステップ４２１で、取り出されたファイル
名成分「ｈｏｍｅ」が「．」と比較される。等価である
場合、ステップ４２３で、システムは現在の作業ディレ
クトリを参照し、制御はステップ４１５に戻る。ファイ
ル名成分が「．」でない場合、ステップ４２５で、ファ
イル名が「．．」と比較される。「．．」と等価である
場合、ステップ４２７で、現在の作業ディレクトリの親
が参照され、制御はステップ４１５に戻る。「．．」と
等価でない場合、ステップ４２７が、図５に示されるよ
うに、取り出されたファイル名「ｈｏｍｅ」に対して実
行される。これは、本発明のファイルシステムに特徴的
な参照機能である。

【００４９】ファイルシステム固有の参照機能について
以下で詳細に説明するが、取り出されたファイル名「ｈ
ｏｍｅ」が（３２１に示すように）前置子および後置子
を含まないことに注意する。図５の各ステップがファイ
ル名「ｈｏｍｅ」に対して実行された後、ファイル「ｈ
ｏｍｅ」のファイルオブジェクトにアクセスするｖノー
ド参照とともに、ステップ４２９に戻る。ｖノード参照
が発見されなかった場合、ステップ４３１でエラーがユ
ーザに返される。発見された場合、ステップ４３３で、
システムは、そのｖノード参照が、記号リンクであるデ
ータオブジェクトを参照しているかどうかをチェックす
る。

【００５０】参照している場合、ステップ４３５で、リ
ンクの内容が残りのパス名の前に置かれる。参照してい
ない場合、ステップ４３７で、システムは、パス名の中
にさらにファイル名成分があるかどうか判定する。ファ
イル名成分がない場合、ステップ４３９で、データオブ
ジェクトへのｖノード参照とともに制御は復帰する。さ
らにファイル名成分が存在する場合、さらに処理するた
めに制御はステップ４１５に戻る。

【００５１】図５を参照して、本発明の実施例を、ファ
イルシステムに特徴的な参照機能として説明する。ここ
では、パス名の例「／ｈｏｍｅ／ｊｑｐ／２＠ｍｅｍｏ
ｉｒｓ」のファイル名「ｈｏｍｅ」の処理について説明
する。ステップ５０１で、カレントディレクトリにおけ
る要求者の実行許可が標準的方法でチェックされる。許
可が存在しない場合、ステップ５０２で、アクセスエラ
ーメッセージがユーザに返される。

【００５２】許可が存在する場合、ステップ５０３で、
前置子または後置子が存在するかどうかを判定するため
のチェックが行われる。図３から、ファイル名３２０が
３個のセグメント、すなわち、前置子、ベース名および
後置子を含む可能性があることに注意する。いくつかの
可能な前置子および後置子を表１に掲げる。これらは、
図２のスーパーブロック２２２の一部として格納され
る。

【００５３】前置子および後置子が発見されない場合、
処理はステップ５０７に進む。今の例のファイル名「ｈ
ｏｍｅ」には前置子や後置子は使用されていない。ファ
イル名「ｈｏｍｅ」は表１に掲げられた可能な前置子の
うちのいずれをも含んでいないため、ステップ５０５
で、ベース名はファイル名「ｈｏｍｅ」と等価であり、
カレントディレクトリでこのベース名が検索される。

【００５４】しかし、表１で前置子または後置子の一致
が発見された場合、それぞれ、前置子または後置子の一
致が存在することを示すソフトウェアフラグがセットさ
れる。基本的に、前置子または後置子の一致は、表１の
各前置子および後置子をファイル名と比較することによ
って判定される。前置子および後置子は一般的にファイ
ルシステムのスーパーブロックに格納される。

【００５５】ステップ５０５で、「ベース名」を生成す
るために、前置子および後置子が全ファイル名から取り
除かれる。ステップ５０７で、ファイル名から前置子ま
たは後置子が取り除かれて生じた「ベース名」を使用し
てディレクトリが検索される。ステップ５０９で、ディ
レクトリに「ベース名」が発見された場合、ステップ５
１１で、前置子または後置子フラグをチェックする。前
置子または後置子が発見されない場合、ステップ５１３
で、制御は第０データストリームのベース名に付随する
ｖノードを返す。従って、今の例では、ファイル名「ｈ
ｏｍｅ」に対し、「ｈｏｍｅ」ファイルオブジェクトの
第０データストリームのｖノードが図４のステップ４２
９に返され、前記の方法による処理が続けられる。

【００５６】前置子または後置子がファイル名に発見さ
れた場合、この機能は、オブジェクトベース名の選択さ
れたデータストリームの参照ｖノードとともに成功ステ
ータスを返す。

【００５７】従って、今の例のパス名「／ｈｏｍｅ／ｊ
ｑｐ／２＠ｍｅｍｏｉｒｓ」では、ファイル名「ｈｏｍ
ｅ」は、ステップ５０１、５０３、５０７、５０９、５
１１、５１３を介し、ステップ４２９、４３３および４
３７によって処理される。続いて、ステップ４１５、４
１９、４２１、４２５および４２７でファイル名「ｊｑ
ｐ」が処理される。「ｊｑｐ」は前置子や後置子を持た
ないため、「ｈｏｍｅ」と同様に、すなわち、ステップ
５０１、５０３、５０７、５０９、５１１、５１３によ
って、続いてステップ４２９、４３３および４３７によ
って処理される。

【００５８】ファイル名「ｈｏｍｅ」および「ｊｑｐ」
を処理した後、ファイル名「２＠ｍｅｍｏｉｒｓ」が同
様に処理される。従って、ステップ４１５、４１９、４
２１、４２５および４２７が実行される。しかし、「２
＠ｍｅｍｏｉｒｓ」は前置子すなわち「２＠」を有する
ため、ステップ５０５が実行されて前置子フラグがセッ
トされる。こうして、処理はステップ５０１、５０３、
５０５、５０７、５０９、５１１からステップ５１５に
進む。

【００５９】ステップ５１５で、この機能は「ｍｅｍｏ
ｉｒｓ」というファイル名に対する前置子「２＠」によ
って指定されるデータストリームの参照ｖノードととも
に成功を返す。例えば、前置子「２＠」によって指定さ
れるデータストリームは、「ｍｅｍｏｉｒｓ」ファイル
のテキストとともに利用されるフォントまたはアイコン
を指定する。前置子および後置子のさまざまな型および
使用法を以下で説明する。

【００６０】表１を参照して、本発明によって利用可能
なさまざまな設定の前置子および後置子のいくつかの例
について簡単に説明する。ベース名を物理ファイル名と
呼ぶ場合、＜前置子＞＜ベース名＞＜後置子＞の組合せ
は仮想ファイル名と呼ぶことができる。この場合、各仮
想ファイル名はベース名のファイルとデータを共有す
る。

【００６１】仮想ファイル名の能力の応用例の１つは、
ＵＮＩＸシステム上でマッキントッシュ（ＭＡＣ）のフ
ァイル名構造、すなわち、「ファイル名、ビット」をシ
ミュレートすることである。ここで、ビットは、そのフ
ァイルがデータファイルであるかまたはリソースファイ
ルであるかを示す。本発明によれば、前置子または後置
子は、例えばそれぞれ＜ビット＞＜ファイル名＞または
＜ファイル名＞＜ビット＞のように、ＵＮＩＸシステム
へのビット情報を識別する。もう１つの応用は、ＵＮＩ
ＸシステムにＯＳ／２属性能力を与えることである。Ｏ
Ｓ／２では、ファイル名に前置子または後置子が付随
し、それによって、標準的なファイルシステムプリミテ
ィブ、例えば、ｏｐｅｎ、ｒｅａｄ、ｗｒｉｔｅ、ｃｌ
ｏｓｅ、ｌｏｃｋ、を介してアクセスされる拡張属性デ
ータを可能にする。

【００６２】以下で前置子として説明する例は後置子と
しても利用可能であることに注意する。表１の前置子の
型は１個以上の数字、文字または記号で表現することも
可能である。例えば、前置子「１＠」がＯＳ／２システ
ムの「拡張属性」を表し、前置子「２＠」がマッキント
ッシュシステムのリソースファイルを表してもよい。前
置子「ｕｎｘ＠」はＵＮＩＸシステム拡張属性能力を表
すことができる。他の前置子の例としては、ベース名フ
ァイルの古いバージョンを意味する「ｏｌｄ＠」や、ベ
ース名ファイルのコンパイルまたはインタープリットさ
れたバージョンを表す「ＣＩ＠」がある。

【００６３】本発明は事前に格納されたファイルのデー
タにアクセスするものとして説明してきたが、他の応用
例ではそのデータの一般的特性または属性にアクセスす
ることも可能である。こうした特性は明示的に格納され
る必要はなく、むしろ実行時に計算されまたはテストさ
れる。例えば、オープンされ読み出される際に、ファイ
ルの全データストリームによって使用されている記憶領
域の全バイト数の文字列表示を返す全ファイルサイズス
トリームを追加することが可能である。

【００６４】こうして、本発明のファイル命名方式を使
用して、ユーザは、実際のファイルに付随するファイル
の「属性」に対し、ファイルとして、すなわち、ｏｐｅ
ｎ（）、ｒｅａｄ（）、ｗｒｉｔｅ（）、ｃｌｏｓ
ｅ（）を使用して、アクセスすることができる。「属
性」は、所有者、グループ、モードなどの現存の属性と
ともに、ファイル型、内容の主題または要約、履歴、そ
のオブジェクトと他のオブジェクトの間の関係、アイコ
ン、設定データ、そのファイルのコンパイル／インター
プリット形式、アプリケーションまたはファイル型固有
のデータ（例えば、仮想データストリームの例として全
サイズを使用すると、アクセスの際に仮想データストリ
ームが生成される）のような新しいすなわち拡張された
属性を含む。

【００６５】上記の属性リストで、コンパイル／インタ
ープリット形式は、仮想ファイルとしてアクセス可能な
仮想特性であってもよい。掲げられた他の属性は一般的
に物理データストリームとしてアクセス可能な物理特性
である。

【００６６】

【発明の効果】このように、特に、本発明のファイル命
名方式は、ネットワークファイルシステム、遠隔ファイ
ルシステム、Ａｎｄｒｅｗファイルシステムなどのよう
なファイル共有機構またはプロトコルによってファイル
属性（上記）にアクセスするために使用される。本発明
のファイル命名方式を使用すれば、ファイルに付随した
多くの補助的ストリームが互換性のある方法で可能とな
る。

【００６７】さらに、この方式はファイル名に基づいて
いるため、ファイル名を使用してファイルにアクセスす
ることができる将来のファイル共有機構とともに使用す
ることも可能であろう。さらに、本発明のファイル命名
方式は、Ｍａｃのリソースフォーク、ＯＳ／２の拡張属
性などのストリームにアクセスするための特定の機構を
サポートしていないオペレーティングシステムからそれ
らにアクセスするために使用することもできる。最後
に、本発明は、ファイル名を使用してアクセス可能なフ
ァイルシステムをサポートする任意のオペレーティング
システムとともに利用可能である。

【図面の簡単な説明】

【図１】本発明の動作の説明に有用な、コンピュータお
よびそのオペレーティングシステムのブロック図であ
る。

【図２】ファイルおよびファイルシステムの論理および
物理構造の図である。

【図３】本発明の説明に有用な用語を定義する図であ
る。

【図４】本発明のさまざまな動作機能を説明する流れ図
である。

【図５】本発明のさまざまな動作機能を説明する流れ図
である。

【符号の説明】

１００ コンピュータベースファイルシステム １０１ ユーザ １１０ ＵＮＩＸオペレーティングシステム １２０ ユーザレベル １２１ ユーザプログラム １２２ ライブラリ １３０ カーネルレベル １３１ システムコールインタフェース １３２ ファイルシステムドライバ １３３ プロセス制御サブシステム １３４ デバイスドライバ １３６ バッファ １３７ ブロックＩ／Ｏデバイスドライバ １３８ キャラクタＩ／Ｏデバイスドライバ １４０ ハードウェアレベル １４１ ブロックＩ／Ｏデバイス １４２ キャラクタＩ／Ｏデバイス １８０ ディスク ２２０ 物理ファイルシステム ２２１ ブートブロック ２２２ スーパーブロック ２２３ ｉノードリスト ２２４ データブロック ３２０ ファイル名 ３３０ ベース名 ３３１ 従来型「物理」ファイル名 ３３２ 所定構文 ３３３ 非部分文字列ベースの名前

【表１】

Claims (12)

【特許請求の範囲】
1. 【請求項１】 ファイルアクセス要求の一部として受容
   したファイル名を、ベース名セグメントおよび１個以上
   の付加セグメントへと解析する手段と、 所望のファイルを選択するためにベース名セグメントを
   使用してファイルシステムを検索する手段と、 所望のベース名ファイルに付随し、付加セグメントを使
   用して選択されたデータストリームにアクセスする手段
   とからなることを特徴とする、格納されたファイルのデ
   ータまたはデータの特性へのアクセスを可能にするファ
   イルシステム装置。
2. 【請求項２】 付加セグメントがベース名の前置子であ
   ることを特徴とする請求項１の装置。
3. 【請求項３】 付加セグメントがベース名の後置子であ
   ることを特徴とする請求項１の装置。
4. 【請求項４】 ベース名ファイルがデータファイルであ
   り、アクセスされるデータストリームがマッキントッシ
   ュのリソースフォークであることを特徴とする請求項１
   の装置。
5. 【請求項５】 付加セグメントが、１個以上の格納ファ
   イルからアクセスされるファイル属性を識別するために
   使用されることを特徴とする請求項１の装置。
6. 【請求項６】 ベース名ファイルが非部分文字列ベース
   の基準を使用して識別されることを特徴とする請求項１
   の装置。
7. 【請求項７】 付加セグメントが、１個以上の格納ファ
   イルの属性に、ファイルとしてアクセスするために使用
   されることを特徴とする請求項１の装置。
8. 【請求項８】 ベース名ファイルがデータファイルであ
   り、 付加セグメントが、データファイルを処理するために利
   用されるオペレーティングシステムにアクセスするため
   に使用されることを特徴とする請求項１の装置。
9. 【請求項９】 ベース名セグメントが、前記装置に付随
   した記憶手段内の所望のファイルを探索するための直接
   の記憶手段アドレスを示す１個以上の文字の第１セット
   を含むことを特徴とする請求項１の装置。
10. 【請求項１０】 ベース名セグメントが格納ファイルの
    グループにアクセスし、 ベース名セグメントが、ファイルのグループのうちのい
    ずれにアクセスすべきかを識別する１個以上の文字の第
    ２セットを含むことを特徴とする請求項１の装置。
11. 【請求項１１】 ファイルシステムがＵＮＩＸオペレー
    ティングシステム下で動作することを特徴とする請求項
    １の装置。
12. 【請求項１２】 ファイルアクセス要求の一部として受
    容したファイル名を、ベース名セグメントおよび１個以
    上の付加セグメントへと解析するステップと、 所望のファイルを選択するためにベース名セグメントを
    使用してファイルシステムを検索するステップと、 所望のベース名ファイルに付随し、付加セグメントを使
    用して選択されたデータストリームにアクセスするステ
    ップとからなることを特徴とする、格納されたファイル
    のデータまたはデータの特性を取得するためのファイル
    システム装置の操作方法。