JPH06161855A

JPH06161855A - ファイル装置およびファイルアクセス方法

Info

Publication number: JPH06161855A
Application number: JP5225049A
Authority: JP
Inventors: Eric J Bauer; ジェイ．バウアーエリック
Original assignee: American Telephone and Telegraph Co Inc; AT&T Corp
Current assignee: AT&T Corp
Priority date: 1992-08-19
Filing date: 1993-08-19
Publication date: 1994-06-10
Also published as: CA2099399A1; US5627996A; CA2099399C; EP0588488A1

Abstract

(57)【要約】【目的】異なるファイル名フォーマットを使用して同
一のコンピュータファイルにアクセスする。【構成】相異なるファイル名フォーマットを使用する
複数のファイル名によって識別されるデータファイルを
格納するディレクトリと、ユーザによって入力された目
的ファイル名に対応する本発明の装置によって利用され
るファイル名フォーマットを識別するユーザリクエスト
を受け取る手段と、前記目的ファイル名に一致するファ
イル名を有するデータファイルを探索するために前記デ
ィレクトリにアクセスし、前記識別されたファイル名フ
ォーマットを利用したファイル名をチェックする手段と
からなる。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

【従来の技術】コンピュータのオペレーティングシステ
ムは、ファイル名がある制約を満たすことを要求する。
一般的な制約として、ファイル名内の最大文字数を制限
することがある。ＭＳ−ＤＯＳオペレーティングシステ
ム（ＭＳ−ＤＯＳはマイクロソフト社の登録商標であ
る）はファイル名を１１文字に制限している。ＭＡＣＩ
ＮＴＯＳＨオペレーティングシステム（ＭＡＣＩＮＴＯ
ＳＨはアップルコンピュータ社の登録商標である）はフ
ァイル名を３１文字に制限している。ＵＮＩＸファイル
システム（ＵＮＩＸはＵＮＩＸシステムラボラトリーズ
社の登録商標である）およびＯＳ／２ハイパフォーマン
スファイルシステム（ＯＳ／２はＩＢＭの登録商標であ
る）はファイル名を２５５文字に制限している。もう１
つの一般的な制約は、ファイル名が含むことが可能な文
字セットを制限することである。例えば、ＭＳ−ＤＯＳ
システムはファイル名に「」（空白）のような文字を
禁じており、ＭＡＣＩＮＴＯＳＨは「：」（コロン文
字）を禁じている。ＭＳ−ＤＯＳシステムはまた、ファ
イル名を、８文字の名前および３文字の拡張子というフ
ォーマットに制限しているが、他のファイルシステムは
任意のファイル名構造を許容している。

【０００３】

【発明が解決しようとする課題】制限的ファイル名フォ
ーマットを有するオペレーティングシステムのユーザ
が、ファイルを異なるオペレーティングシステム間で共
有するることができるように、他のオペレーティングシ
ステムによって作成され命名されたファイルにアクセス
することができれば好ましい。非制限的ファイル命名フ
ォーマットを有するオペレーティングシステムが、制限
的ファイル命名フォーマットを有するオペレーティング
システムによって作成されたファイルにアクセスするこ
とを可能にすることは明らかに非常に容易である。困難
であるのは、制限的ファイル命名フォーマットを有する
オペレーティングシステムから非制限的ファイルへのア
クセスを実現することである。ＭＳ−ＤＯＳのようない
くつかのオペレーティングシステムは他のオペレーティ
ングシステム（例えばＭＡＣＩＮＴＯＳＨおよびＵＮＩ
Ｘ）よりも制限的なファイル名を有するため、非制限的
オペレーティングシステムでは制限的オペレーティング
システムにおいて不法である名前によってファイルを作
成および命名することが可能である。例えば、ＭＡＣＩ
ＮＴＯＳＨまたはＵＮＩＸファイルシステムでは「ｍｅ
ｅｔｉｎｇａｇｅｎｄａ」というファイルを作成する
ことが可能であるが、このファイル名はＭＳ−ＤＯＳシ
ステム上では不法である。なぜならば、これは長過ぎ
（１４文字）、８文字ファイル名／３文字拡張子フォー
マットを満たしておらず、不法文字（空白）を含むため
である。

【０００４】

【課題を解決するための手段】この問題の１つの解決法
は、ＭＡＣＩＮＴＯＳＨおよびＵＮＩＸのユーザが作成
する長い非制限的な名前に対する別名である短い制限的
なＭＳ−ＤＯＳファイル名を作成することである。例え
ば、ＭＡＣＩＮＴＯＳＨファイル「ｍｅｅｔｉｎｇａ
ｇｅｎｄａ」は、ファイル名別名「ｍｅｅｔｉｎｇ．ａ
ｇｅ」によってＭＳ−ＤＯＳシステムからアクセス可能
である。この解決法の問題点は、ＭＡＣＩＮＴＯＳＨ、
ＵＮＩＸおよびその他の非制限的オペレーティングシス
テムユーザが見るファイル名の空間をこれらの短い別名
で汚すのが好ましくないことである。ディレクトリの内
容をリストする際に、クライアントユーザはファイルご
とにただ１つの正当なファイル名を見ることを望む。例
えば、ＭＡＣＩＮＴＯＳＨユーザは「ｍｅｅｔｉｎｇ
ａｇｅｎｄａ」を見ることを望み、「ｍｅｅｔｉｎｇ
ａｇｅｎｄａ」、「ｍｅｅｔｉｎｇ．ａｇｅ」および他
のクライアントオペレーティングシステムのための別名
を見ることは望まない。

【０００５】本発明によれば、上記の問題点は、ユーザ
プログラムのファイルアクセス要求が、ユーザによって
入力された目的ファイル名に対して使用されるファイル
名フォーマットを識別することによって解決される。一
実施例では、ファイル名フォーマットは、前置セグメン
ト（例えば「ｄｏｓ＝」）に、ＭＳ−ＤＯＳ別名である
ベース名（例えば「ｍｅｅｔｉｎｇ．ａｇｅ」）を続け
ることによって識別され、これによって、非制限的ファ
イル名オペレーティングシステム上で動作しているＭＳ
−ＤＯＳファイルサーバは、ＭＳ−ＤＯＳクライアント
に「ｍｅｅｔｉｎｇａｇｅｎｄａ」という名前のファ
イルへの便利なアクセスを提供することができる。本発
明を組み込んだファイルシステムのクライアントコンピ
ュータユーザは、ファイルサーバアプリケーションプロ
グラム（これはユーザプログラムである）からファイル
名別名の名前を取得することができる。ファイルサーバ
アプリケーションは、前置セグメント「ｄｏｓ＝」およ
びベース名「．」（すなわち、「ｄｏｓ＝．」）によっ
て、またはカスタムオペレーティングシステムコールを
介して、システムコールを発する。システムは、ＭＳ−
ＤＯＳファイル名別名（例えば「ｍｅｅｔｉｎｇ．ａｇ
ｅ」のみを応答する。その後、クライアントコンピュー
タユーザは、制限的オペレーティングシステム（例えば
ＭＳ−ＤＯＳ）から「ｍｅｅｔｉｎｇａｇｅｎｄａ」
という名前のファイルにアクセスすることができる。ユ
ーザは、従来の方法で「ｄｏｓ＝ｍｅｅｔｉｎｇ．ａｇ
ｅ」としてそのファイルにアクセスすることが可能であ
る。本発明の意図しているのはファイルサーバアプリケ
ーションとともに使用する使用法であるため、ＭＳ−Ｄ
ＯＳコンピュータから作業するクライアントコンピュー
タユーザは「ｍｅｅｔｉｎｇ．ａｇｅ」と入力し、ファ
イルサーバアプリケーションが「ｄｏｓ＝」を前置して
ファイル名「ｄｏｓ＝ｍｅｅｔｉｎｇ．ａｇｅ」を生成
し、これがファイルシステムに渡されることが期待され
る。このように、本発明によれば、コンピュータベース
のファイルシステムは、記憶手段に事前に記憶された任
意の複数のデータファイルにアクセスすることが可能と
なり、各ファイルは、デフォルト（標準）ファイル名お
よび１以上の別名フォーマットによって識別される。シ
ステムは、０以上の付加セグメントおよびベース名を有
する目的ファイル名を含むユーザプログラム要求を受け
取る。１以上の付加セグメントの存在は、別名フォーマ
ットのうちの１つを使用すべきことを示し、付加セグメ
ントの不存在（または標準ファイル名の明示的な指定）
は、標準名フォーマットを使用すべきことを示す。その
後、システムは記憶装置にアクセスし、その中のファイ
ル名をチェックして、識別されるファイル名を利用し
て、ベース名と同一のファイル名を有するデータファイ
ルを探索する。

【０００６】本発明のもう１つの目的によれば、データ
ファイルはあるファイル名フォーマットを使用して識別
され、それからシステムは付加セグメント中に識別され
るファイル名フォーマットを使用してファイル名を編集
する。その後、ベース名が、要求するベース名ファイル
を探索するために、計算されたファイル名と比較され
る。

【０００７】

【実施例】

［高度な説明］図１は、本発明が利用可能なクライアン
ト／サーバシステム（ネットワーク）のブロック図であ
る。このネットワークは、ローカルエリアネットワーク
（ＬＡＮ）１０４を介して複数のクライアントワークス
テーション（コンピュータ）１０２、１０３に接続され
たサーバコンピュータ１００を有する。サーバコンピュ
ータ１００は、例えば、クライアントコンピュータ１０
２、１０３に、ハードディスク１８０上に格納されたデ
ータへの共有アクセスを提供する。

【０００８】一実施例では、各クライアントコンピュー
タ１０２、１０３は、周知のＭＳ−ＤＯＳオペレーティ
ングシステムまたはＯＳ／２オペレーティングシステム
を使用して動作するパーソナルコンピュータ（ＰＣ）で
ある。ＬＡＮ１０４は、例えば、ＡＴ＆ＴのＳＴＡＲＬ
ＡＮシステムである。サーバコンピュータ１００は、例
えば、ＵＮＩＸシステムＶリリース４．０オペレーティ
ングシステム上で動作するＡＴ＆Ｔ６３８６ワークグル
ープシステムコンピュータである。クライアントＰＣ１
０２、１０３およびサーバコンピュータ１００は、ＡＴ
＆ＴのＳｔａｒＧＲＯＵＰ（登録商標）システムソフト
ウェアを使用することが可能である。このＳｔａｒＧＲ
ＯＵＰシステムソフトウェアは、ＭＳ−ＤＯＳおよびＯ
Ｓ／２クライアントＰＣがＬＡＮ上のデータファイルを
透過的に共有することを可能にする。

【０００９】ＵＮＩＸオペレーティングシステム１２０
の最上部でサーバプログラム１２３を動作させるサーバ
コンピュータ１００は、ＬＡＮ１０４上でクライアント
ＰＣ１０２、１０３によって利用可能な大容量ハードデ
ィスク（例えば１８０）をサポートすることができる。
各目的オペレーティングシステムの種類に対して別々の
サーバプログラム１２３（例えば、１つはＭＳ−ＤＯＳ
用、１つはＵＮＩＸ用など）が存在することが可能であ
る。

【００１０】クライアントコンピュータ１０３上のソフ
トウェアは、サーバコンピュータ１００上のサーバプロ
グラム１２３と対話して、クライアントプログラム１１
０によるディスク１８０へのアクセスを可能にする。特
に、ディスク１８０を参照するシステムコールがリダイ
レクタ１１２によってリクエストメッセージに組み込ま
れ、ネットワークソフトウェア１１３（当業者にはＮＥ
ＴＢＩＯＳおよびプロトコルソフトウェアとして周知）
によってローカルエリアネットワーク１０４を通じてサ
ーバプログラム１２３へ送信される。サーバプログラム
１２３はそのリクエストを処理し、応答をクライアント
コンピュータ１０３へ送信する。

【００１１】クライアント・サーバ対話の動作に関する
さらに詳細な説明は、Ｉ．Ｊ．ハイザー「ＵＮＩＸコン
ピュータ用ＤＯＳサーバプログラム」（ＡＴ＆Ｔテクノ
ロジー第４巻第１号（１９８９年））という論文に記載
されている。

【００１２】サーバコンピュータ１００（コンピュータ
ベースのファイルサーバともいう）は、高レベルアーキ
テクチャ層ダイヤグラムを使用して示されるように、Ｕ
ＮＩＸオペレーティングシステム１０５の制御下で動作
する。この層ダイヤグラムは、ユーザレベル１２０、カ
ーネルレベル１３０、およびハードウェアレベル１４０
を含む。ユーザレベル１２０は、ＬＡＮ１０４を介して
クライアント（以下ユーザともいう）１０２、１０３と
インタフェースし、ディスク１８０に格納された所望の
ファイルへのアクセスを可能にする。

【００１３】ユーザレベル１２０は、ユーザプログラム
１２１（サーバプログラムと同様）およびライブラリ１
２２を含む。ハードウェアレベル１４０は、オペレーテ
ィングシステム１１０に、コンピュータ１００によって
必要とされる基本的なサービスを提供する。カーネルレ
ベル１３０は、ハードウェアレベル１４０と直接対話
し、ユーザレベル１２０のプログラムに共通のサービス
を提供し、ユーザレベル１２０のプログラムをハードウ
ェア特異性から絶縁する。システムを層のセットとして
見ると、オペレーティングシステムは、ユーザプログラ
ムからの絶縁を強調して、一般的にシステムカーネル１
３０（または単にカーネル）と呼ばれる。ユーザプログ
ラムは下位のハードウェアから独立であるため、異なる
ハードウェア上で動作しているＵＮＩＸシステム間でユ
ーザプログラムを移動することは容易である。ＵＮＩＸ
オペレーティングシステムの周知の動作の一般的な説明
は、モーリス・Ｊ．バック「ＵＮＩＸオペレーティング
システムの設計」の第２章にある。

【００１４】システムコールインタフェース１３１は、
ユーザレベル１２０（ユーザプログラム１２１およびプ
ログラムライブラリ１２２）とカーネルレベル１３０の
境界を表す。システムコールインタフェース１３１は、
ユーザプログラムコールをＵＮＩＸシステムコールに変
換する。システムコールは、Ｃプログラムの通常のファ
ンクションコールのようなものであり、ライブラリは、
これらのファンクションコールを周知の方法でオペレー
ティングシステムに入力するのに必要なプリミティブに
マッピングする。システムコールのセットは、ファイル
システムドライバ１３２と対話するもの、および、プロ
セス制御サブシステム１３３と対話するものを含む。フ
ァイルシステムドライバ１３２は、ファイルの管理、フ
ァイル空間の割当、ファイルへのアクセスの制御、およ
びユーザのためのデータの取得を行う。プロセスは、ｏ
ｐｅｎ（読み出しまたは書き込みのためにファイルを開
く）、ｃｌｏｓｅ、ｒｅａｄ、ｗｒｉｔｅ、ｓｔａｔ
（ファイルの属性を照会する）、ｃｈｏｗｎ（ファイル
の所有者の記録を変更する）およびｃｈｍｏｄ（ファイ
ルのアクセス許可情報を変更する）のようなシステムコ
ールの特定のセットを介してファイルシステムドライバ
１３２と対話する。ファイルシステムドライバ１３２
は、カーネルと補助記憶装置の間のデータフローを調節
するバッファ１３６を使用してファイルデータにアクセ
スする。バッファリング機構は、ブロックＩ／Ｏデバイ
ス１４１と対話して、カーネルとのデータ転送を開始す
る。ブロックＩ／Ｏデバイス１４１は、ランダムアクセ
ス記憶装置である。すなわち、そのデバイスドライバ１
３７は、ブロックＩ／Ｏデバイス１４１がシステムの残
りの部分にはランダムアクセス記憶装置であるようにみ
えるようにする。例えば、テープドライバは、カーネル
がテープ装置をランダムアクセス記憶装置として扱うこ
とを可能にする。また、ファイルシステムは、バッファ
リング機構の介入なしに、「ｒａｗ」すなわちキャラク
タＩ／Ｏデバイスドライバ１３８と直接対話する。ｒａ
ｗデバイス（キャラクタＩ／Ｏデバイスとも呼ばれる）
１４２は、ブロックデバイスでないすべてのデバイスを
含む。

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

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

【００１７】図１、２および３をあわせて参照して、フ
ァイルシステムの概観を説明する。あらゆるファイルは
１つ以上のパス名３１０によって名付けられる。パス名
は、３１０に示すように、デリミタ（／）によって区切
られたファイル名（例えばｈｏｍｅ）を含む。ファイル
の内部表現はｉノード２００によって与えられる。ｉノ
ード２００は、ファイルデータのディスクレイアウトの
記述およびその他の情報（例えばファイル所有者、アク
セス許可情報、およびアクセス回数）を含む。「ｉノー
ド」という用語は、インデクスノードという用語の略で
あり、ＵＮＩＸシステムに関する文献で一般的に使用さ
れている。あらゆるファイルは１つのｉノードを有する
が、そのファイルはいくつかのパス名を有することもあ
り、それらはすべてそのｉノードにマッピングされる。
各パス名はリンクと呼ばれる。プロセスがファイルをパ
ス名によって参照する場合、カーネルは一度に１ファイ
ル名成分ずつパス名を解析し、そのプロセスがそのパス
内のディレクトリを検索する許可を有することをチェッ
クした後、そのファイルのｉノードを取得する。例え
ば、プロセスが「ｏｐｅｎ（／ｈｏｍｅ／ｊｑｐ）」
というコールをした場合、カーネルは「／ｈｏｍｅ／ｊ
ｑｐ」に対するｉノードを取得する。３１５によって示
されるように、完全パス名に対する「ファイルシステム
ツリー」はスラッシュ文字「／」で始まり、パス名がフ
ァイルシステムツリーの「ルート」に相対的であること
を指定する。パス名「／ｈｏｍｅ／ｊｑｐ／ｍｅｅｔｉ
ｎｇａｇｅｎｄａ」の連続する成分名に導く分枝に従
うと完全パス名が指定されるが、「／ｊｑｐ／ｍｅｅｔ
ｉｎｇａｇｅｎｄａ」ではそうではない。パス名はル
ートから始まる必要はなく、パス名の最初のスラッシュ
を除くことによって、実行プロセスの「カレントディレ
クトリ」に相対的に指定することもできる。この場合、
カレントディレクトリ「／ｈｏｍｅ」から始まって、パ
ス名「ｂｉｎ」は、その完全パス名が「／ｈｏｍｅ／ｂ
ｉｎ」であるファイルを指定する。

【００１８】プロセスが新しいファイルを作成すると、
ファイルシステムドライバ１３２はそれに未使用ｉノー
ドを割り当てる。ｉノードは物理ファイルシステム２２
０のセクション２２３に格納される（後述）。ファイル
システムドライバ１３２は、ファイルを操作する際にそ
のｉノードをコア内メモリｉノードテーブルに読み込
む。ＵＮＩＸシステムは一般的に正規のファイルおよび
ディレクトリをディスクのようなブロックデバイス上に
保持する。あるインストール例では、いくつかの物理デ
ィスクユニットがあり、それぞれが１またはいくつかの
ファイルシステムを含む。ファイルシステム２２０は論
理ブロックの列から編成され、各ブロックは、システム
処理系に応じて、５１２、１０２４、２０４８、または
任意の都合の良い５１２の整数倍のバイト数を含む。５
１２の整数倍は慣用によって使用されているものであ
り、５１２バイトブロックを使用する本質的な理由はな
い。

【００１９】物理ファイルシステムは例えば図２の２２
０に示すような物理構造を有する。ブートブロック２２
１（いくつかのファイルシステムのみ）は、ファイルシ
ステムの最初（一般には第１ディスクセクタ）を占有
し、ブートストラップコードを含むことがある。ブート
ストラップコードは、オペレーティングシステムをブー
ト（初期化）するためにマシンに読み込まれる。システ
ムをブートするのに必要なブートブロック２２１は１つ
のみであるが、あらゆるファイルシステムが（おそらく
は空の）ブートブロックを有することがある。スーパー
ブロック２２２は、ファイルシステムの状態（大きさ、
格納可能なファイル数、ファイルシステム上のフリー空
間の場所、その他の情報）を記述する。ｉノードリスト
２２３は、ファイルシステムのスーパーブロックに続く
ｉノードのリストである。管理者は、ファイルシステム
を設定する際にｉノードリスト２２３のサイズを指定す
る。ファイルシステムドライバ１３２は、ｉノードリス
ト２２３内へインデックスによってｉノードを参照す
る。あるｉノードはファイルシステムのルートｉノード
である。このｉノードによって、ｍｏｕｎｔシステムコ
ールの実行後にファイルシステムのルートディレクトリ
構造にアクセスすることができる。データブロック２２
４はｉノードリストの最後から始まり、ファイルデータ
の内容を保持する。割り当てられたデータブロックは、
ファイルの実際のデータを含み、ファイルシステム中の
ただ１つののファイルに所属することができる。

【００２０】以後、本発明の動作について、仮想ファイ
ルシステムを使用してＵＮＩＸシステム上に実現される
拡張ファイルシステム（ＥＦＳ）において利用されるよ
うに説明する。いくつかのＵＮＩＸシステムは、すべて
のファイルシステム動作を編成するために仮想ファイル
システム（ＶＦＳ）の概念を使用している。本発明はＶ
ＦＳ機構を必要としないが、ＶＦＳは本発明を説明する
ための便利な概念的モデルを提供する。ＶＦＳはＳｙｓ
ｔｅｍＶファイルシステムスイッチ（ＦＳＳ）および
ＳＵＮＯＳＶＦＳ機構の合併である。（ＳＵＮＯ
Ｓはサン・マイクロシステムズの登録商標である。）注
意すべき重要な点であるが、ユーザプログラムは、ＳＶ
Ｒ４．０ＶＦＳアーキテクチャによって影響されな
い。

【００２１】ＶＦＳは、独自の方法で各ファイルシステ
ムがファイルシステム動作を処理することを可能にしな
がら、プログラムおよびユーザにファイルシステムタイ
プ独立なインタフェースを提供する。ファイルシステム
タイプ従属なカーネルルーチンがタイプに特有の作業を
行う。

【００２２】ＶＦＳの基本的な長所は、新しいファイル
システムタイプがサードパーティソフトウェアハウスに
よって定義され実現されることが可能であることであ
る。ＶＦＳを構成するカーネルインタフェースのセット
は、ＵＮＩＸシステム・ラボラトリーズ社から入手可能
なＶＦＳファイルシステムタイプライターズガイドで入
手可能である。

【００２３】［一般的な説明］本発明は、ファイルシス
テムを使用するプログラムまたは人間ユーザ（以下まと
めてユーザという）が、ディレクトリ構造に格納されて
いるファイルの標準ファイル名とは異なる別名を使用し
てファイルにアクセスすることを可能にする。

【００２４】本発明を使用するファイルシステムでは、
非制限的ファイル名の別名形式をファイルシステム事態
に格納することができる（例えば図８のディレクトリ８
００）。換言すれば、このような別名は、システムに、
格納されたファイル名（図８のディレクトリ８００に格
納されている）から別名（例えば、図７に示すようなＭ
Ｓ−ＤＯＳベースの所定のファイル名マッピングアルゴ
リズムを使用して）を計算させることによって「進行中
に」生成することが可能である。ＭＳ−ＤＯＳユーザが
ディレクトリファイルエントリのリストを要求すると、
サーバ１２３はファイル「ｄｏｓ＝」内のディレクトリ
エントリを枚挙する。システムは、コンピュータのセキ
ュリティおよび管理制御に従って、カレント作業ディレ
クトリ内の全ファイルに対するＭＳ−ＤＯＳ別名を返
す。換言すれば、このようなＭＳ−ＤＯＳ別名は、周知
のファイルシステム固有のシステムコール（例えばｉｏ
ｃｔｌ（））を使用して枚挙される。

【００２５】ＭＳ−ＤＯＳユーザ（またはプログラム）
は、ＭＳ−ＤＯＳファイル名別名のリストを取得した
後、所望のファイル名別名を選択し、そのファイル名別
名（例えば図１の１９１によって示される「ｍｅｅｔｉ
ｎｇ．ａｇｅ」）を使用してファイルコールを呼び出
す。ファイルサーバアプリケーションプログラム（図１
の１２３）は、クライアントコンピュータがＭＳ−ＤＯ
Ｓオペレーティングシステムを実行していることを知る
と、セグメント「ｄｏｓ＝」を前置し、ファイル名「ｄ
ｏｓ＝ｍｅｅｔｉｎｇ．ａｇｅ」を生成し（図１の１９
２）、これはファイルシステムドライバ１３２へ渡され
る。

【００２６】ファイル名中に前置セグメントが含まれて
いない場合、ファイルシステムは、ベース名をディレク
トリに格納されているファイル名と比較する（図８の８
１１、８１３および８１５）。前置セグメントが「ｄｏ
ｓ＝」であり、ＭＳ−ＤＯＳ別名が別名１としてファイ
ルシステムによって格納されている場合、ファイルシス
テムは、ベース名を、ディレクトリに格納されている別
名１の値と比較することになる（図８の８２１、８２
３、および８２５）。前置セグメントが「ｓｐａｎｉｓ
ｈ＝」であり、スペイン語ファイル名翻訳が別名３とし
て格納されている場合、システムは、ベース名を、ディ
レクトリに格納されている別名３の値と比較することに
なる（図８の８４１、８４３、および８４５）。

【００２７】前置セグメントが「進行中に」計算された
ファイル名別名を選択した場合、ファイルシステムは、
選択されたファイル名別名マッピングアルゴリズム（図
７）によって目的ベース名との照合を試みる。

【００２８】［詳細な説明］図１の層ダイヤグラムを参
照して、本発明のさらに詳細な動作の説明をする。

【００２９】図１〜４を併せて参照して、本発明の詳細
な動作を説明する。本発明は、パス名からｖノードへの
変換中に生じる標準的な参照パス名機能の一部としてフ
ァイルシステム固有の参照機能を実行するように実現さ
れる。

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

【００３１】ステップ４０１〜４２５およびステップ４
２９〜４３９は、パス名からｖノードへの変換の現在の
ステップを示す。本発明の詳細な動作（図５）が一般的
な動作状況で説明できるように、これらのステップにつ
いて簡単に説明する。

【００３２】ユーザ検索リクエストまたはその他のシス
テムリクエストに応答して、ユーザプログラム１２１は
システムコール（例えばファイルのｏｐｅｎ）を発す
る。ユーザプログラム１２１がシステムコール（例えば
ｏｐｅｎ（パス名，ｏｐｅｎフラグ））を発すると、オ
ペレーティングシステムカーネル（以下カーネルとい
う）１３０は、ステップ４０１で、周知のコマンドｖｎ
＿ｏｐｅｎ（ｎａｍｅ，ｓｅｇ，ｆｉｌｅｍｏｄｅ，
ｃｒｅａｔｅｍｏｄｅ，ｖｐｐ，ｃｒｗｈｙ）を発生
する。コマンドｖｎ＿ｏｐｅｎは、許可チェックを実行
してファイルを名前（ｎａｍｅ）によってオープンし、
得られたｖノードへのポインタを返す。コマンドｖｎ＿
ｏｐｅｎにおいて、パラメータｎａｍｅはパス名を含
む。ｓｅｇはファイル名が入っているアドレス空間（ユ
ーザ空間またはカーネル空間）である。ｆｉｌｅｍｏ
ｄｅはｏｐｅｎモードである。ｃｒｅａｔｅｍｏｄｅ
はファイルが作成される場合の許可ビットを含む。ｖｐ
ｐは結果のｖノードポインタへのポインタである。ｃｒ
ｗｈｙは、このルーチンが呼ばれる理由である。これ
は、ファイルモードのＦｃｒｅａｔｅビットがセットさ
れている場合に限り定義される。

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

【００３４】Ｆｃｒｅａｔｅビットがセットされていな
い場合、ステップ４０７で、パス名が空でないかどうか
チェックされる。われわれの例では、パス名は「／ｈｏ
ｍｅ／ｊｑｐ／ｍｅｅｔｉｎｇａｇｅｎｄａ」であっ
た。（われわれのＤＯＳシステムコール例では、パス名
は「ｈｏｍｅ／ｊｑｐ／ｄｏｓ＝ｍｅｅｔｉｎｇ．ａｇ
ｅ」となることに注意。）パス名が空である場合、ステ
ップ４０９で、「エントリが見つからない」エラーがユ
ーザプログラム１２１に返される。

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

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

【００３７】このように、図５のステップがファイル名
「ｈｏｍｅ」に対して実行された後、ファイル「ｈｏｍ
ｅ」のファイルオブジェクトにアクセスするためのｖノ
ードとともにステップ４２９に戻る。ｖノード参照符号
がない場合、ステップ４３１で、エラーがユーザプログ
ラム１２１に返される。そうでない場合、ステップ４３
３で、システムは、ｖノード参照符号が、記号リンクで
あるデータオブジェクトを参照しているかどうかをチェ
ックする。そのとおりである場合、ステップ４３５で、
そのリンクの内容が残りのパス名の前に置かれる。そう
でない場合、ステップ４３７で、システムは、パス名中
にさらにファイル名成分があるかどうか判定する。これ
以上ファイル名成分がない場合、ステップ４３９で、制
御は、データオブジェクトへのｖノード参照符号ととも
に戻る。さらにファイル名成分が存在する場合、さらに
処理するために制御はステップ４１５に戻る。

【００３８】図５を参照して、ファイルシステム固有の
参照機能として実現された本発明について説明する。わ
れわれの例のパス名「／ｈｏｍｅ／ｊｑｐ／ｍｅｅｔｉ
ｎｇａｇｅｎｄａ」のファイル名「ｈｏｍｅ」の処理に
ついて説明する。ステップ５０１で、カレントディレク
トリにおける要求者の実行許可情報が標準的な方法でチ
ェックされる。許可が存在しない場合、ステップ５０２
で、アクセスエラーメッセージがユーザに返される。許
可が存在する場合、ステップ５０５、５１５および５２
５で、ファイルシステムは、プレフィクス（前置子）ま
たはサフィクス（後置子）が使用されているかどうかチ
ェックする。ファイル名「ｈｏｍｅ」にはプレフィクス
もサフィクスも存在しないので、処理は５２８に進み、
エントリ「ｈｏｍｅ」に対するカレントディレクトリを
検索する。ステップ５０９は、エントリが発見されたこ
とをチェックし、ステップ５１３で成功が返される。こ
のパス名中の「ｊｑｐ」および「ｍｅｅｔｉｎｇａｇ
ｅｎｄａ」の処理は「ｈｏｍｅ」の処理と同様であるた
め、説明しない。

【００３９】許可が存在する場合、ステップ５０５で、
サーバは、ＭＳ−ＤＯＳプレフィクス／サフィクスが使
用されているかどうか判定する。われわれの例では、ク
ライアントコンピュータユーザは「ベース名」を入力
し、サーバアプリケーションプログラム１２３がプレフ
ィクス「ｄｏｓ＝」を追加し、「ｄｏｓ＝ベース名」を
カーネル１３０に送ったと仮定している。その後、ステ
ップ５０７で、ＤＯＳプレフィクス／サフィクスがファ
イル名から切り出される。その後、ステップ５０８で、
図６または図７のＤＯＳ名前参照ストラテジが使用され
る（後述）。ステップ５０９で、一致する名前が発見さ
れたかどうか判定される。発見された場合、ステップ５
１３で、サーバは、発見されたファイル名への参照符号
とともに成功指示子を返す。ステップ５１１でＤＯＳフ
ァイル名が発見されなかった場合、「ファイル名が発見
されない」エラーがクライアントに返される。

【００４０】ステップ５０５で、ＤＯＳプレフィクス／
サフィクスが使用されていないと判定された場合、ステ
ップ５１５で、ＭＡＣＩＮＴＯＳＨプレフィクス／サフ
ィクスが使用されているかどうか判定される。答えがＹ
ＥＳである場合、ステップ５１７で、ＭＡＣＩＮＴＯＳ
Ｈプレフィクス／サフィクスがファイル名から切り出さ
れる。その後、ステップ５１８で、ＭＡＣＩＮＴＯＳＨ
参照ストラテジが図６または図７で使用される（後
述）。その後、ステップ５０９でが前記のように実行さ
れる。

【００４１】ステップ５１５で、ＭＡＣＩＮＴＯＳＨプ
レフィクス／サフィクスが使用されていない場合、ＤＯ
ＳおよびＭＡＣＩＮＴＯＳＨが他のオペレーティングシ
ステムに対して前述したように、ステップ５２５、５２
６および５２７で、他のオペレーティングシステムプレ
フィクス／サフィクスがテストされる。

【００４２】プレフィクス／サフィクスシステムは、コ
ンピュータオペレーティングシステムによって定義され
る以外の名前空間を表現するために使用される。例え
ば、５２５の「他のプレフィクス／サフィクス」は、ベ
ース名が英語ファイル名のスペイン語翻訳であることを
示す「ｓｐ＝」とすることが可能である。一般的に、フ
ァイルサーバアプリケーションプログラム１２３は、ス
ペインのユーザ用に設定されると、クライアントコンピ
ュータユーザがスペイン語でファイルを命名することが
できるように、「ｓｐ＝」プレフィクス／サフィクスを
付け加えることができる。従って例えば、ユーザが、ス
ペイン語ファイル名「ｌａａｇｅｎｄａｄｅｌａ
ｒｅｕｎｅｏｎ」を要求すると、サーバは、それを、図
８の作業ディレクトリ８００内の標準ファイル名「ｍｅ
ｅｔｉｎｇａｇｅｎｄａ」（８１３）の別名８４３と
して識別する。作業ディレクトリ８００内には、標準フ
ァイル名（例えば８１１および８１５）に対する他のス
ペイン語ファイル名等価物（例えば８４１および８４
５）が示されている。

【００４３】以下では図６および８を参照する。図６
は、参照ストラテジを実現するために使用する流れ図で
あり、これは、例えば、図８のディレクトリ８００内の
ＵＮＩＸファイルを探索するためにＤＯＳファイル名の
別名を利用する。以下の例では、ＤＯＳファイル名は、
図８でａｌｔｎａｍｅ１（すなわち、８２１、８２３お
よび８２５）として示された、ファイルエントリの別名
ロケーションに格納されていると仮定する。ステップ６
０１で、プログラムはディレクトリ８００の第１エント
リ８０１から開始するよう初期化される。ステップ６０
２で、システムは、プレフィクス／サフィクス（例えば
「ｄｏｓ＝」）情報を使用して、いずれの指定名前型
（ファイル名、ａｌｔｎａｍｅ１、ａｌｔｎａｍｅ２・
・・この例では違いはない）を各ファイルエントリ８０
１〜８０５でチェックするかを決定する。ステップ６０
３で、ベース名がディレクトリ８００の第１ファイルエ
ントリ８０１にリストされた指定名前型の値と一致する
か否かが判定される。一致する場合、ステップ６０５
で、発見されたディレクトリエントリへの参照符号とと
もに、成功の指示子がユーザプログラム１２１に返され
る。ベース名が第１エントリ内の指定名前型と一致しな
い場合、ステップ６０７で、ディレクトリ内にチェック
すべきエントリがさらに存在するかどうかが判定され
る。存在する場合、ステップ６１１で、プログラムは次
のディレクトリエントリ（すなわち、ファイルエントリ
８０３）に進み、制御はステップ６０３に戻る。ステッ
プ６０７でディレクトリ８００内にもうエントリが存在
しないと判定された場合、ステップ６０９で、「エント
リ名が見つからない」エラーがユーザプログラム１２１
に返される。

【００４４】図６の流れ図に示すプログラムは、ベース
名が、ディレクトリ８００の各エントリ８０１〜８０５
の以前に決定されたＤＯＳファイル名別名に対してチェ
ックされる手続きを示している。このように、例えば、
ファイルシステムによってａｌｔｎａｍｅ１として格納
されたＤＯＳベース名が「ｍｅｅｔｉｎｇ．ａｇｅ」で
ある場合、エントリ８０３が識別されユーザプログラム
１２１に返される。

【００４５】図７および８を参照して、ディレクトリ８
００のＵＮＩＸファイル名８１２、８１４および８１６
のＤＯＳベース名等価物を決定するために所定のアルゴ
リズム（ファイル名マッピング機能）を使用する参照ス
トラテジについて説明する。

【００４６】図９は、デフォルト（標準）ファイル名
（例えば８１１、８１３、８１５）を、選択された別名
型にマッピングするために使用可能な一般的アルゴリズ
ムのリストを示している。

【００４７】ファイルサーバがサポートするクライアン
トオペレーティングシステムの各型に対して「フォーマ
ット依存一致」アルゴリズムを実現することができる。
呼のフォーマット依存一致アルゴリズムは、１）ユーザ
プログラムリクエストにおいて取得されるベース名のフ
ォーマットを標準ファイル名のフォーマットに「進行中
に」変換すること、または、２）標準ファイル名のフォ
ーマットをユーザプログラムリクエストにおいて取得さ
れるベース名のフォーマットに変換することを可能にす
る。図９は、サポートされるいくつかの重要なクライア
ントオペレーティングシステム（例えば、ＤＯＳ、ＭＡ
ＣＩＮＴＯＳＨ、ＯＳ／２の高性能ファイルシステム、
ＰＥＮＰＯＩＮＴオペレーティングシステム（ＰＥＮＰ
ＯＩＮＴはＧＯ社の商標）、ＮＴウィンドウズオペレー
ティングシステム（ＮＴウィンドウズはマイクロソフト
社の登録商標））に対するフォーマット依存一致アルゴ
リズムを列挙している。

【００４８】ステップ７０１で、プログラムはディレク
トリ８００の第１エントリに初期化される。ステップ７
０２で、システムは、プレフィクス／サフィクス情報を
使用して、別名ファイル名を計算するためにいずれの所
定のアルゴリズムを使用すべきかを指定する。これらの
別名アルゴリズムのリストを図９に示す。われわれの例
では、プレフィクス「ｄｏｓ＝」のため、ＤＯＳアルゴ
リズムが選択される。ステップ７０３で、計算すべき別
名ファイル名がＤＯＳアルゴリズムを使用して計算され
る。われわれの例では、１つのこのような所定アルゴリ
ズムは、ファイル名中のすべての空白が除去され、最初
の１１文字が８．３のＤＯＳフォーマットに調整される
ように指定する。ステップ７０５で、プログラムは、ベ
ース名が、ディレクトリ８００内の第１エントリ８０１
のファイル名８１１に対して計算された別名ファイル名
に一致するか否かを判定する。一致する場合、ステップ
７０７で、ディレクトリ８００内の発見されたエントリ
への参照符号とともに、成功がユーザプログラム１２１
に返される。一致しない場合、ステップ７０９で、ディ
レクトリ８００内にさらにエントリが存在するかどうか
が判定される。もうこれ以上エントリがない場合、ステ
ップ７１１で、ユーザプログラム１２１は「エントリ名
が見つからない」メッセージを取得する。さらにエント
リが存在する場合、ステップ７１３で、プログラムは次
のエントリ８０３のファイル名（すなわち８１３）に進
み、制御はステップ７０３に戻る。プロセスステップ７
０３、７０５、７０９および７１３は、ベース名が発見
される（ステップ７０７）か、または、ベース名が発見
されない（ステップ７１１）まで、ディレクトリ８００
のすべてのエントリに対して順次実行される。または、
アルゴリズムは、目的ベース名（これでステップ７０３
を置き換える）に適用され、ここで計算された名前が、
格納されているファイル名と比較（これでステップ７０
５を置き換える）されることも可能である。

【００４９】例えば、ＵＮＩＸファイル名（例えば８１
３）が「ｍｅｅｔｉｎｇａｇｅｎｄａ」である場合、
前述のアルゴリズム（空白を除去して強制的に８．３フ
ォーマットにする）を使用して、システムはＤＯＳ等価
ファイル名「ｍｅｅｔｉｎｇａ．ｇｅｎ」を計算する。
ディレクトリ８００のファイル名８１３と等価なこの計
算されたＭＳ−ＤＯＳファイル名が、ユーザプログラム
入力ファイルアクセスコマンド（ｄｏｓ＝ベース名）の
ベース名と比較される。

【００５０】図３、５〜８を併せて参照して、ＤＯＳク
ライアントがいかにして、「ｒｅｓｕｍｅ」、「ｍｅｅ
ｔｉｎｇａｇｅｎｄａ」および「ｃｈｉｌｄｈｏｏｄ
ａｄｖｅｎｔｕｒｅｓ」という名前の以前に作成され
たＵＮＩＸファイルにアクセスすることができるかを概
観しておく。まずいずれのファイルがディレクトリ内に
存在するかを決定するため、ＤＯＳクライアントはディ
レクトリ内の全ファイルを列挙するためにコマンドを実
行する。このリストコマンドはディレクトリ８００内の
すべてのＤＯＳファイル名を出力する。図８のディレク
トリ例では、サーバは、クライアントがＤＯＳマシンを
利用中であり、その結果、ＵＮＩＸファイル名８１１、
８１３および８１５（すなわち、「ｒｅｓｕｍｅ」、
「ｍｅｅｔｉｎｇａｇｅｎｄａ」および「ｃｈｉｌｄ
ｈｏｏｄａｄｖｅｎｔｕｒｅｓ」）にそれぞれ対応す
るエントリ８２１、８２３および８２５に示されたＤＯ
Ｓ別名のみを出力していることを知る。または、前述の
アルゴリズムが利用された場合、サーバは、ＵＮＩＸフ
ァイル名８１１、８１３および８１５の、計算された別
名ファイル名等価物を生成することも可能である。例え
ば、前述のアルゴリズムを使用して、「空白を除去して
から最初の１１文字をＤＯＳの８．３形式にする」こと
により、ＵＮＩＸファイル名「ｒｅｓｕｍｅ」、「ｍｅ
ｅｔｉｎｇａｇｅｎｄａ」および「ｃｈｉｌｄｈｏｏ
ｄａｄｖｅｎｔｕｒｅｓ」に対してそれぞれＤＯＳフ
ァイル名「ｒｅｓｕｍｅ」、「ｍｅｅｔｉｎｇａ．ｇｅ
ｎ」および「ｃｈｉｌｄｈｏｏ．ｄａｄ」が生成され
る。明らかに、計算されたファイル名はそれぞれ、ディ
レクトリ８００のエントリ８０１、８０３および８０５
にａｌｔｎａｍｅ１（８３１，８３３および８３５）と
してすでに格納されている場合、サーバは単にこのファ
イル名のリストをクライアントに直接に出力することが
できる。テーブル８５０に示すように、各タイプのオペ
レーティングシステムとともに使用されるアルゴリズム
は、同じでも相違してもよいことは理解すべきである。
相違する場合、前述のように、システムは、ベース名に
付加されたセグメントからの情報を使用して適切なアル
ゴリズムを選択する。

【００５１】まずディレクトリ８００の別名ファイル名
（計算されたファイル名）のリストを取得することによ
って、クライアントコンピュータは所望のファイルを選
択してアクセスすることが可能となる。サーバは、クラ
イアントがＤＯＳマシンであることを知ると、ベース名
「ｃｈｉｌｄｈｏｏ．ｄａｄ」にプレフィクス「ｄｏｓ
＝」を付加し、ファイル名「ｄｏｓ＝ｃｈｉｌｄｈｏ
ｏ．ｄａｄ」を形成する。その場合、図５のステップ５
０５で、ファイルシステムドライバは、ファイル名から
「ｄｏｓ＝」プレフィクスを取り外し、ディレクトリ８
００内のすべての別名ファイル名を検索するために使用
されるベース名を生成する。（システムが、計算された
別名ファイル名技術を使用している場合、前述の図７の
ような手続きが続くことに注意。）ベース名「ｃｈｉｌ
ｄｈｏｏ．ｄａｄ」を使用して、サーバは、クライアン
トによって要求されているファイルとして、別名８１５
およびファイルエントリ８０５を探索する。エントリ８
０５はＵＮＩＸファイル名「ｃｈｉｌｄｈｏｏｄａｄ
ｖｅｎｔｕｒｅｓ」を有するため、クライアントは正し
いファイルに到達する。

【００５２】以上の本発明の説明は、プレフィクス付加
セグメント（例えば、「ｄｏｓ＝」はベース名へのプレ
フィクスである）を使用するものであるが、サフィクス
付加セグメント（例えば、「＠ｄｏｓ」はベース名のサ
フィクスである）またはプレフィクス／サフィクス組合
せ付加セグメントも利用可能である。さらに一般的に
は、クライアントコンピュータユーザ入力に応答して、
ユーザプログラムはシステムコールまたはその他の機構
によって、ユーザによって入力される後続の目的ファイ
ル名のファイル名フォーマットを指定することができ
る。すなわち、例えば、このようなシステムコールは、
所定時間（例えばセッション）中に、または、ユーザが
元のもしくは他のフォーマットを再指定するまで、ユー
ザによるすべてのファイル名アクセスに利用されるファ
イル名フォーマットを識別する。このような構成によっ
て、ユーザは、個々のファイル名アクセスごとにではな
くセッションごとにフォーマットを変更することが可能
となる。

【００５３】アプリケーションまたはファイルシステム
固有のシステムコール（例えばｉｏｃｔｌ）は、ある名
前空間から他の名前空間にファイル名を変換するように
構成することができる。例えば、このような機構は、Ｕ
ＮＩＸファイル名を入力として受け取り、マッピングさ
れたＭＳ−ＤＯＳファイル名を返す。このような機構
は、本発明の原理の直接の応用例である。

【００５４】

【発明の効果】以上述べたごとく、本発明によれば、相
異なるオペレーティングシステムを使用しているクライ
アントコンピュータから、それぞれのオペレーティング
システムの方式によるファイル名フォーマットによっ
て、サーバコンピュータのデータファイルにアクセスす
ることが実現される。

【図面の簡単な説明】

【図１】本発明が利用可能なサーバコンピュータを含む
クライアント／サーバネットワークのブロック図であ
る。

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

【図３】本発明の説明で使用するさまざまな用語を定義
する図である。

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

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

【図６】第１の参照ストラテジを実現する流れ図であ
る。

【図７】第２の参照ストラテジを実現する流れ図であ
る。

【図８】別名（エイリアス）を使用するディレクトリの
論理構造の図である。

【図９】ファイル名を計算する一般的なアルゴリズムの
リストである。

【符号の説明】

１００サーバコンピュータ１０２クライアントコンピュータ１０３クライアントコンピュータ１０４ローカルエリアネットワーク（ＬＡＮ）１０５ＵＮＩＸオペレーティングシステム１１０クライアントプログラム１１２リダイレクタ１１３ネットワークソフトウェア１２０ユーザレベル１２１ユーザプログラム１２２ライブラリ１２３サーバプログラム１３０カーネルレベル１３１システムコールインタフェース１３２ファイルシステムドライバ１３３プロセス制御サブシステム１３６バッファ１３８キャラクタＩ／Ｏデバイスドライバ１４０ハードウェアレベル１４１ブロックＩ／Ｏデバイス１４２キャラクタＩ／Ｏデバイス１８０ハードディスク２００ｉノード２２０物理ファイルシステム２２１ブートブロック２２２スーパーブロック２２３ｉノードリスト２２４データブロック３１０パス名

Claims

【特許請求の範囲】

【請求項１】事前に格納された複数のデータファイル
のうちの任意のファイルにアクセスするコンピュータベ
ースのファイル装置において、相異なるファイル名フォーマットを使用してフォーマッ
トされた少なくとも２つのファイル名によって識別され
るデータファイルを格納する手段（８００）と、ユーザによって入力された目的ファイル名に対応する前
記装置によって利用されるファイル名フォーマットを識
別するユーザリクエストを受け取る手段（４０２）と、前記目的ファイル名に一致するファイル名を有するデー
タファイルを探索するために、前記格納手段にアクセス
し、前記識別されたファイル名フォーマットを利用した
ファイル名をチェックする手段（図６）とからなること
を特徴とするファイル装置。
【請求項２】前記ユーザリクエストが、付加セグメン
トおよびベース名を有する目的ファイル名を含み、前記
付加セグメントのうちの少なくとも１つが前記ベース名
のファイル名フォーマットを識別するために使用され、
前記ベース名は一致するファイル名を有するデータファ
イルを探索するために使用されることを特徴とする請求
項１の装置。
【請求項３】前記少なくとも２つのファイル名が、デ
フォルトファイル名および少なくとも１つの別名ファイ
ル名を含むことを特徴とする請求項２の装置。
【請求項４】第１のファイル名が第１のコンピュータ
オペレーティングシステムに対応するフォーマットを利
用してフォーマットされ、第２のファイル名が、第２の
コンピュータオペレーティングシステムに対応するフォ
ーマットを使用して前記第１ファイル名から導出される
ことを特徴とする請求項２の装置。
【請求項５】前記第１および第２ファイル名が相異な
るフォーマットを利用し、各フォーマットは、ＵＮＩ
Ｘ、ＭＡＣＩＮＴＯＳＨ、ＮＴＷＩＮＤＯＷＳ、ＯＳ
／２、ＰＥＮＰＯＩＮＴ、およびＭＳ−ＤＯＳオペレー
ティングシステムを含む群から選択される相異なるコン
ピュータオペレーティングシステムに対応することを特
徴とする請求項４の装置。
【請求項６】前記付加セグメントがコンピュータオペ
レーティングシステムを識別することを特徴とする請求
項２の装置。
【請求項７】少なくとも１つのファイルが第１および
第２ファイル名によって識別され、この第２ファイル名
はこの第１ファイル名から所定のアルゴリズムを使用し
てフォーマットされることを特徴とする請求項２の装
置。
【請求項８】事前に格納された複数のデータファイル
のうちの任意のファイルにアクセスするコンピュータベ
ースのファイル装置において、第１フォーマットを使用してフォーマットされたファイ
ル名を使用して識別されるデータファイルを格納する手
段（８００）と、付加セグメントおよびベース名（少なくとも１つの付加
セグメントはベース名の第２フォーマットを識別する）
を有する目的ファイル名を含むユーザリクエストを受け
取る手段（４０２）と、前記第２フォーマットに対応するフォーマット依存一致
アルゴリズムを利用して、前記格納されたデータファイ
ルのうちの１つと前記ベース名を照合し、一致したデー
タファイルにアクセスする手段（図７）とからなること
を特徴とするファイル装置。
【請求項９】前記照合アクセス手段が、前記第１フォーマットを使用してベース名をフォーマッ
トする手段と、前記第１フォーマットを使用してフォーマットされた前
記ベース名に一致する格納されたファイル名を識別する
ために前記格納手段にアクセスする手段とを有すること
を特徴とする請求項８の装置。
【請求項１０】前記照合アクセス手段は、格納された
ファイル名が前記第２フォーマットを使用してフォーマ
ットされている場合に、前記ベース名に一致する格納さ
れたファイル名を識別するために前記格納手段にアクセ
スする手段を有することを特徴とする請求項８の装置。
【請求項１１】事前に格納された複数のデータファイ
ルのうちの任意のファイルにアクセスするコンピュータ
ベースのファイル装置を動作させる方法において、相異なるファイル名フォーマットを使用してフォーマッ
トされた少なくとも２つのファイル名によって識別され
るデータファイルを格納するステップ（８００）と、ユーザによって入力された目的ファイル名に対応する前
記装置によって利用されるファイル名フォーマットを識
別するユーザリクエストを受け取るステップ（４０２）
と、前記目的ファイル名に一致するファイル名を有するデー
タファイルを探索するために、前記格納されたデータフ
ァイルにアクセスし、前記識別されたファイル名フォー
マットを利用したファイル名をチェックするステップ
（図６）とからなることを特徴とするファイルアクセス
方法。
【請求項１２】前記ユーザリクエストが、付加セグメ
ントおよびベース名を有する目的ファイル名を含み、前
記付加セグメントのうちの少なくとも１つが前記ベース
名のファイル名フォーマットを識別するために使用さ
れ、前記ベース名はそれに一致するファイル名を有する
データファイルを探索するために使用されることを特徴
とする請求項１１の方法。
【請求項１３】前記少なくとも２つのファイル名が、
相異なるフォーマットを利用する第１および第２のファ
イル名を含み、各フォーマットは、ＵＮＩＸ、ＭＡＣＩ
ＮＴＯＳＨ、ＮＴＷＩＮＤＯＷＳ、ＯＳ／２、ＰＥＮ
ＰＯＩＮＴ、およびＭＳ−ＤＯＳオペレーティングシス
テムを含む群から選択される相異なるコンピュータオペ
レーティングシステムに対応することを特徴とする請求
項１２の方法。
【請求項１４】事前に格納された複数のデータファイ
ルのうちの任意のファイルにアクセスするコンピュータ
ベースのファイル装置を動作させる方法において、第１フォーマットを使用してフォーマットされたファイ
ル名を使用して識別されるデータファイルを格納するス
テップ（８００）と、付加セグメントおよびベース名（少なくとも１つの付加
セグメントはベース名の第２フォーマットを識別する）
を有する目的ファイル名を含むユーザリクエストを受け
取るステップ（４０２）と、前記第２フォーマットに対応するフォーマット依存一致
アルゴリズムを利用して、前記格納されたデータファイ
ルのうちの１つと前記ベース名を照合するステップ（図
７）と、一致したデータファイルにアクセスするステップとから
なることを特徴とするファイルアクセス方法。
【請求項１５】前記照合ステップが、前記第１フォーマットを使用してベース名をフォーマッ
トするステップと、前記第１フォーマットを使用してフォーマットされた前
記ベース名に一致する格納されたファイル名を識別する
ために前記格納されたデータファイルにアクセスするス
テップとを有することを特徴とする請求項１４の方法。
【請求項１６】前記照合ステップは、格納されたファ
イル名が前記第２フォーマットを使用してフォーマット
されている場合に、前記ベース名に一致する格納された
ファイル名を識別するために前記格納されたデータファ
イルにアクセスするステップを有することを特徴とする
請求項１４の方法。