JPH1031612A - 高度ファイル・サーバ - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】 いくつかの異なるオペレーティング・システ
ムを使用しているコンピュータを含むネットワークのユ
ーザが、相互のファイルに容易にアクセスできるように
する。 【解決手段】 ホスト・コンピュータ１００の固有のネ
ームスペースからのファイル名と、このファイルに割り
当てられたファイル・システムの「インノード」番号か
ら、特定のアルゴリズムによって、合法で意味のあるフ
ァイル名を作り出すようにする。。必要な予備情報はた
とえばＵＮＩＸであればｇｅｔｄｅｎｔｓ（２）システ
ム呼出で求められる。クライアントのオペレーティング
・システムが特定のファイル名についてサポートできな
い場合は合法的となるように・フライでさらに計算がさ
れる。たとえば、ＵＮＩＸの「ｌｏｎｇｆｉｌｅｎａｍ
ｅ」「１２３４」の組からＤＯＳのために「ｌｏｎｇ１
２３４」が生成される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータ・シ
ステムの分野に関し、特にコンピュータ・システムの共
有ファイルにアクセスするための装置および方法に関す
る。

【０００２】

【従来の技術、及び、発明が解決しようとする課題】コ
ンピュータ・オペレーティング・システムは、「ファイ
ル名」によりコンピュータ・システムに記憶されている
ファイルにアクセスする。この場合ファイル名は、一般
に特定の命名規則に従ったものでなければならない。少
なくとも、上記の命名規則は、使用できる文字および一
つのファイル名で使用できる文字の最大数を指定してい
る。さらに、あるオペレーティング・システムは、特定
のファイル名の書式を指定している場合がある。例え
ば、マイクロソフト社のＭＳ−ＤＯＳオペレーティング
・システムは、ファイル名に使用できる文字を、アルフ
ァベット（Ａ−Ｚ）、数字（０−９）およびいくつかの
記号（例えば、「．」、「＿」、「−」等）に限定して
いるし、一方、ファイル名に含まれる文字の数を１−８
個の文字および０−３個の拡張子、例えば、「ＡＵＴＯ
ＥＸＥＣ．ＢＡＴ」のように限定している。この書式
は、よく「８．３」書式と呼ばれる。一方、ＡＴ＆Ｔの
ＭＰ−ＲＡＳ ＵＮＩＸオペレーティング・システム
は、スラッシュ文字「／」を除く２５５文字までのファ
イル名をサポートしている。

【０００３】いずれにせよ、あるオペレーティング・シ
ステムは、他のオペレーティング・システムと比較する
と制限が厳しいので、例えば、ファイル名がすべての有
効な文字を２５５バイトの長さまで含むことができるウ
ィンドウズＮＴのようにより制限が緩やかなオペレーテ
ィング・システムに対しては、いつでも、有効なファイ
ル名を付けることができるが、一方そのファイル名はＭ
Ｓ−ＤＯＳのようなより制限の厳しいオペレーティング
・システムには無効である。

【０００４】いくつかの異なるオペレーティング・シス
テムを実行しているコンピュータが、同時にファイルに
アクセスする場合があるネットワーク・オペレーティン
グ・システムにおいては、異なるファイルの命名に対す
る制限が問題になる。一例をあげると、ウィンドウズＮ
Ｔのユーザが、共有ファイル・システム上に「１９９５
ＤｅｐａｒｔｍｅｎｔＢｕｄｇｅｔ」という名前のファ
イルを作ろうとすると、ＭＳ−ＤＯＳのユーザは、その
ように命名されたファイルにアクセスすることはできな
い。何故なら、そのようなファイルは、ＭＳ−ＤＯＳの
８．３ファイル名書式に適合していないからである。

【０００５】上記のような共有ファイル・システム・ネ
ットワーク環境におけるこのような問題に対する誰でも
思いつく解決法をとった場合、コンピュータのユーザは
ファイル名規則の最小公倍数に適合するファイル名をつ
くらなければならない。すなわち、最も制限の厳しい規
則を、通常はＭＳ−ＤＯＳの８．３ファイル名書式規則
である、共通ファイルおよびディレクトリを有する各サ
ポート・オペレーティング・システムに適用しなければ
ならない。

【０００６】よりよい解決法は、各ファイルが、各ネー
ムスペースに一つの名前を持っている「ネームスペース
表」を使用する方法である。例えば、ウィンドウズＮＴ
のファイル・システム（ＮＴＦＳ）は、１９９４年マイ
クロソフト出版社出版のヘレン・カスター著の「ウィン
ドウズＮＴファイル・システムの内幕」、ＩＳＢＮ−５
５６１５−６６０−Ｘ、６９−７２ページに記載されて
いるように、各ファイルに対して、２５５バイトまでの
長さの長いファイル名と、ＭＳ−ＤＯＳ式の８．３書式
のファイル名の両方を使用している。同様に、ノベルの
「ポ−タブル・ネットウェア」は、ＯＳ／２およびマッ
キントッシュ・オペレーティング・システムに対する追
加のネームスペースをサポートしている、ユーザ・レベ
ルでファイルを管理している。

【０００７】しかし、この解決法は、ＵＮＩＸ環境に対
しては満足できるものではない。何故なら、システム上
の各ファイルに対して、ＭＳ−ＤＯＳ式のファイル名の
静的記録を保管しておかなければならないからである。
他のファイル・システムが、離れた場所で、もっと制限
の厳しいオペレーティング・システムを使用しているユ
ーザも参照できる、ＮＦＳ（ネットワーク・ファイル・
システム）と一緒に、ＵＮＩＸ上で使用されている可能
性がある場合には、保管しておかなければならない情報
量は膨大なものになり、管理することができなくなる。

【０００８】

【課題を解決するための手段】それ故、本発明の一つの
目的は、種々のオペレーティング・システムを使用して
いるコンピュータのネットワーク間で、ファイルを共有
することができるもっと簡単な方法を提供することであ
る。本発明の他の目的は、ネットワークのユーザ・オペ
レーティング・システムの種々の命名方法に対応する複
数の静的ファイル名記録の保管を軽減および／または必
要としないようにすることである。

【０００９】本発明は、コンピュータ・ネットワークの
ユーザ間で共有しているコンピュータ用の一意のファイ
ル名を計算する方法を提供する。上記のネットワーク
は、ホスト・オペレーティング・システムと、このホス
ト・オペレーティング・システムとは異なるユーザ・オ
ペレーティング・システムを使用している少なくとも一
台のユーザ・コンピュータを使用しているホスト・コン
ピュータに、ファイル・サーバを含む。上記方法は、上
記のファイル・サーバから、ファイルに対する上記ホス
ト・コンピュータに固有のファイル名を提供するステッ
プと；上記ファイル・サーバによって、上記ファイルに
指定されたインノード番号にアクセスするステップと；
上記の一意のファイル名が上記ユーザ・オペレーティン
グ・システムに対して有効である場合に、上記の一意の
ファイル名を作るために、上記ファイル名と上記インノ
ード番号とを組み合わせるステップを特徴としている。

【００１０】

【発明の実施の形態】本発明は、種々のオペレーティン
グ・システムを使用しているコンピュータを含むネット
ワークのユーザが、共有の他のファイルに容易にアクセ
スすることができる装置および方法に関する。意味のあ
るファイル名は、ホスト・コンピュータの「固有の」ネ
ームスペースからのファイル名と、このファイルに割り
当てられたホスト・コンピュータのファイル・システム
からの一意のインノード番号、すなわち、他の一意のフ
ァイル特性の両方を組み合わせることによって作られ
る。

【００１１】図１は、コンピュータおよび本発明の動作
を説明する際に役に立つそのオペレーティング・システ
ムのブロック図である。本明細書の各図の各品目または
ブロックには、関連参照番号がついている。最初の数字
はその品目が最初に表示された図面の番号である。（例
えば、１１０は、図１に表示されているし、５０１は図
５に表示されている。） 図１は、高度のアーキテククチャ階層図を使用している
ＵＮＩＸ（Ｒ）オペレーティング・システム１１０の制
御の下で動作するコンピュータ・システム１００であ
る。階層図は、ユーザ・レベル１２０、カーネル・レベ
ル１３０、およびハードウェア・レベル１４０を含む。
ユーザ・レベル１２０は、ユーザ１０１がディスク１８
０上に記憶されている物理的ファイルへのファイル・シ
ステム・ドライバ１３２を通して、ファイル・システム
にアクセスすることができるようにするインタフェース
である。

【００１２】ユーザ・レベル１２０は、ユーザ・プログ
ラム１２１およびライブラリ１２２を含む。ＡＴ＆Ｔの
ＵＮＩＸシステム用の高度サーバは、ネットワーク・コ
ンピュータを、ＵＮＩＸオペレーティング・システムを
使用しているコンピュータによって管理されているファ
イル、プリンタおよび他の資源にアクセスさせるユーザ
・プログラムの一例である。ハードウェア・レベル１４
０は、オペレーティング・システム１１０に、コンピュ
ータ１００が必要とする基本的なサービスを提供する。
カーネル・レベル１３０は、ハードウェア・レベル１４
０と直接相互に作用し、ユーザ・プログラム１２１に共
通のサービスを提供し、ユーザ・プログラムをハードウ
ェアのイディオシンクレイシスから分離する。このシス
テムを一組の階層と見れば、オペレーティング・システ
ムは、ユーザ・プログラムからのその独立性を強調する
ために、普通システム・カーネル１３０、または単にカ
ーネルと呼ばれる。ユーザ・プログラムは、このプログ
ラム用のハードウェアから独立しているので、異なるハ
ードウェア上で動作しているＵＮＩＸシステム間で容易
に移動させることができる。ＵＮＩＸオペレーティング
・システムの周知の一般的な説明は、モーリス Ｊ．バ
ッハ著の「ＵＮＩＸオペレーティング・システムの設
計」という本の第２章に記載されている。

【００１３】システム呼出インタフェース１３１は、ユ
ーザ・レベル１２０（ユーザ・プログラム１２１とユー
ザ・ライブラリ１２２）とカーネル・レベル１３０との
境界となっている。システム呼出インタフェースは、ユ
ーザ・プログラム機能呼出をＵＮＩＸオペレーティング
・システム呼出に変換する。オペレーティング・システ
ム呼出はＣプログラムの普通の機能呼出に類似してい
て、ライブラリはこれらの機能呼出を、オペレーティン
グ・システムを周知の方法で入力する際に必要なプリミ
ティブにマップする。一組のオペレーティング・システ
ム呼出は、ファイル・システム・ドライバ１３２と相互
に作用する呼出、およびプロセス制御サブシステム１３
３と相互に作用する呼出を含む。ファイル・システム・
ドライバ１３２は、ファイルを管理し、ファイル・スペ
ースを割り当て、ファイルへのアクセスを制御し、ユー
ザ用のデータを検索する。プロセスは、（読み書きのた
めにファイルを開くための）ｏｐｅｎ呼出、（ファイル
の属性を問い合わせるための）ｃｌｏｓｅ、ｒｅａｄ、
ｗｒｉｔｅ、ｓｔａｔ呼出、（ファイルの所有者の記録
を変更する）ｃｈｏｗｎ呼出、（ファイルのアクセス許
可を変更する）ｃｈｍｏｄ呼出のような、特定の組のシ
ステム呼出を通して、ファイル・システム・ドライバ１
３２と相互に作用する。ファイル・システム・ドライバ
１３２は、カーネルと二次記憶装置との間のデータの流
れを規制するバッファ１３６を使用して、ファイル・デ
ータにアクセスする。バッファ機構は、カーネルへまた
はカーネルからのデータ移送を開始するために、ブロッ
クＩ／Ｏ装置ドライバ１３７と相互に作用する。デバイ
ス・ドライバ１３４は、周辺装置の動作を制御するカー
ネル・モジュ−ルである。ブロックＩ／Ｏドライバ１４
１は、ランダム・アクセス記憶装置であり、別の場合に
は、、それらのデバイス・ドライバ１３７は、自らをシ
ステムの残りの装置に対してランダム・アクセス記憶装
置のように見せかける。例えば、テープ・ドライバによ
り、カーネルはテープ・ユニットをランダム・アクセス
記憶装置のように取り扱うことができる。ファイル・シ
ステムは、またバッファ機構を通さずに、「生」すなわ
ち、文字Ｉ／Ｏデバイス・ドライバ１３８と直接相互に
作用する。文字Ｉ／Ｏ装置１４２と呼ばれることもある
生装置は、ブロック装置ではないすべての装置を含む。

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

【００１５】プロセスを制御するためのある種のシステ
ム呼出は、下記のものを含む。すなわち、（新しいプロ
セスを生成する）ｆｏｒｋ呼出、（実行中のプロセス上
にプログラムのイメージを重ね書きする）ｅｘｅｃ呼
出、（プロセスの実行を終了する）ｅｘｉｔ呼出、（す
でにフォークされたプロセスの終了とプロセスの実行を
同期させる）ｗａｉｔ呼出、（プロセスに割り当てられ
たメモリの大きさを制御する）ｂｒｋ呼出、および（例
外的な事象に応じてプロセスを制御する）ｓｉｇｎａｌ
呼出である。

【００１６】すでに説明したように、コンピュータ１０
０を使用して、ユーザはディスク１８０上に記憶されて
いるファイルにアクセスすることができる。「ファイ
ル」は一つまたはそれ以上のデータ・ストリームを含む
ことができ、オーナーおよび許可および他の属性および
一つまたはそれ以上のファイル名を持っている論理的情
報対象と考えれば、もっともその実体に近い。データ・
ストリームは、コンピュータ上の任意の他のデータ・ス
トリームとは無関係に、延長または短縮することができ
るデータ・バイトの独立したシーケンスであると考えれ
ば、最もその実体に近い。それ故、下記の動作はファイ
ルの動作である。すなわち、ファイル名のつけ替え、リ
ンク、所有者の変更、グループ所有者の変更、およびモ
ードの変更である。下記の動作はデータ・ストリームの
動作である。すなわち、読み取り、書き込み、および
（データ・ストリームの一部の）ロックである。

【００１７】図１、図２および図３を一緒に参照しなが
ら、ファイル・システムの概要を説明する。各ファイル
には、一つまたはそれ以上のパス名３１０がつけられて
いる。３１０に示すように、パス名は区切り文字（／）
で区切られているファイル名（例えば、ホーム）を含
む。ファイルの内部での表現は、ファイル・データのデ
ィスク・レイアウトおよびファイル・オーナー、アクセ
ス許可およびアクセス時間のような他の情報の説明を含
むインノードによって与えられる。インノードという用
語、用語インデックス・ノードを短縮したもので、一般
にＵＮＩＸシステムに関する文献で使用される。各ファ
イルは一つのインノードを持っているが、いくつかのパ
ス名を持つことができ、それらすべてはインノードにマ
ップされる。各パス名はリンクと呼ばれる。プロセスが
パス名でファイルを参照すると、カーネルは一回でパス
名を一つのファイル名構成部分に分解し、そのプロセス
がパスのディレクトリをサーチする許可を持っているか
どうかをチェックし、最後にファイルに対するインノー
ドを検索する。例えば、プロセスが「ｏｐｅｎ（／ｈｏ
ｍｅ／ｊｑｐ）」という呼出を行った場合には、カーネ
ルは、「／ｈｏｍｅ／ｊｑｐ」に対するインノードを検
索する。３１５で示すように、すべてのパス名に対する
「ファイル・システム・ツリー」はスラッシュ
（「／」）で始まり、パス名がファイル・システム・ツ
リーの「ルート」に関連していることを示す。パス名
「／ｈｏｍｅ／ｊｑｐ／ｍｅｍｏｉｒｓ」の連続してい
る構成部分の名称に接続しているブランチを辿っていく
と、パス名全体を指定できるが、「ｈｏｍｅ／ｍｅｍｏ
ｉｒｓ」の場合はそうはならない。パス名はルートから
始める必要はなく、パス名の最初のスラッシュを省略し
て、実行中のプロセスの「現在のディレクトリ」に関連
させて指定することもできる。それ故、現在のディレク
トリ「／ｈｏｍｅ」から始まる場合、パス名「ｂｉｎ」
は、その省略しないパス名が「／ｈｏｍｅ／ｂｉｎ」で
あるファイルを指定する。

【００１８】プロセスが新しいファイルを生成する場
合、ファイル・システム・ドライバ１３２は、そのファ
イルに未使用のインノードを割り当てる。インノード
は、以下に簡単に説明するように、物理的ファイル・シ
ステム２２０のセクション２２３に記憶されるが、ファ
イル・システム・ドライバ１３２は、ファイルを操作す
る際、上記インノードをインコア・メモリ・インデック
ス・ノード表に読み込む。ＵＮＩＸシステムは、通常は
ディスクのようなブロック装置上に正規のファイルおよ
びディレクトリを持っている。一つのインストレーショ
ンは、それぞれが一つまたはそれ以上のファイル・シス
テムを含んでいる数個の物理的ディスク・ユニットを持
つことができる。ファイル・システム２２０は、それぞ
れがシステムの実行に従って、５１２、１０２４、２０
４８または５１２バイトの任意の倍数を含む一連の論理
ブロックの形に形成されている。５１２の倍数は、慣習
的に使用されているもので、５１２バイトのブロックに
する必然的な理由は何もない。物理的ファイル・システ
ムは、図２に２２０で示した物理的構造を持つことがで
きる。（ある種のファイル・システムには一つしかな
い）ブート・ブロック２２１は、ファイル・システムの
先頭、通常第一セクタにあり、オペレーティングシステ
ムをブートまたは初期化するために、コンピュータに読
み込まれるブートストラップ・システム・コードを含む
ことができる。システムをブートするにはブート・ブロ
ック２２１は一つだけあればいいのだが、各ファイル・
システムは、（恐らくは空の）ブート・ブロックを持つ
ことができる。スーパー・ブロック２２２は、ファイル
・システムの状態、すなわち、その大きさ、記憶するこ
とができるファイルの数、ファイル・システム上の自由
スペースの場所、および他の情報を記述している。イン
ノード・リスト２２３は、ファイル・システムでスーパ
ー・ブロックの後に続くインノードのリストである。ア
ドミニストレータは、ファイル・システムを構成すると
きに、インノード・リスト２２３の大きさを指定する。
ファイル・システム・ドライバ１３２は、インデックス
により、インノードのインノードのリスト２２３を参照
する。一つのインノードが、ファイル・システムのルー
ト・インノードである。ルート・インノードとは、それ
によって、ファイル・システムのルート・ディレクトリ
構造が、数量システム呼出の実行の後でアクセスするこ
とができるインノードである。データ・ブロック２２４
は、インノード・リストの終わりから始まり、データ・
ストリーム（すなわち、ファイル・データ）の内容を保
持している。割り当てられたデータ・ブロックはファイ
ルのデータ・ストリームの実際のデータを含み、ファイ
ル・システムの一つ、そしてただ一つのファイルに属す
ことができる。

【００１９】本発明の好適な実施例の場合には、ＵＮＩ
Ｘオペレーティング・システムを使用して動作する図１
のホスト・コンピュータ１００は、例えば、図４に示す
ように、ＭＳ−ＤＯＳのようなＵＮＩＸ以外のオペレー
ティング・システムを使用している種々の他のコンピュ
ータ４２０−４５０とネットワークを構成している。本
発明を、ＵＮＩＸおよびＭＳ−ＤＯＳオペレーティング
・システムを参照しながら説明してきたが、開示の方法
のコンセプトは、当業者なら理解できるように、ＯＳ／
２およびマッキントッシュのような他のオペレーティン
グ・システムにも、同様に適用できることを理解された
い。

【００２０】異なるオペレーティング・システムを使用
しているコンピュータ（４２０、４３０、４４０、４５
０）でファイルを参照し、アクセスする場合には、ホス
ト・コンピュータの「固有の」ネームスペースからのフ
ァイル名と、そのファイルに割り当てられたホスト・コ
ンピュータのファイル・システムからの「インノード」
番号の両方を組み合わせて、合法で意味のあるファイル
名を作るために、明示のネームスペース表を保守するの
ではなく、アルゴリズムが使用される。上記アルゴリズ
ムを適用するのに必要な予備的情報は、どちらかといえ
ば容易に入手することができる。何故なら、ホスト・コ
ンピュータのファイル名およびインノード番号は、「ｇ
ｅｔｄｅｎｔｓ（２）］という周知のＵＮＩＸオペレー
ティングシステムの呼出によって変換されるからであ
る。そのオペレーティング・システムが特定のファイル
名をサポートしていないクライアント・コンピュータ
は、このファイル名がホスト・コンピュータ上のファイ
ル・システムにも、ファイルにも、実際に記憶されず、
それによりシステムに何等の追加情報を記憶する必要が
ない場合には、オン・ザ・フライで計算した特定のファ
イル名によって、特定のファイルの閲覧とアクセスの両
方を行う。長いファイル名だけではなく、長いファイル
名のマッピングを計算するためのインノード番号のよう
な、一意のファイル特性、または疑似の一意の特性を使
用することにより、クライアントが類似のファイル名
で、ファイルの大きなディレクトリを取り扱っている場
合には、非常に重要な結果として得られるファイル名の
一意性が改善される。

【００２１】一意のファイル名を計算するための例示と
してのアルゴリズムについて説明する。ＵＮＩＸを使用
しているサーバ・コンピュータと、図４に示すようにＭ
Ｓ−ＤＯＳを使用しているクライアント・コンピュータ
の場合を考えてみよう。例示の場合には、「ｌｏｎｇｆ
ｉｌｅｎａｍｅ」という共有ファイルは、ｇｅｔｄｅｎ
ｔｓ（２）オペレーティング・システム呼出によって報
告されたインノード１２３４を持っている。お分かりの
ことと思うが、「ｌｏｎｇｆｉｌｅｎａｍｅ」は、有効
なＭＳ−ＤＯＳファイル名ではない。何故なら、このフ
ァイル名は８．３書式ではないからである。

【００２２】図５に簡単なアルゴリズムのフローチャー
トを示す。最初のステップ５００において、アルゴリズ
ムを実行するかしないかを決定する。すなわち、例え
ば、ファイル名が特定のクライアントのオペレーティン
グ・システムに対して有効かどうかを判断するために、
ファイル名がチェックされる。有効である場合には、通
常の処理を行うことができる。有効でない場合には、本
発明のアルゴリズムが実行される。ファイル名のチェッ
クが行われた後の最初のステップ５１０においては、ク
ライアント・オペレーティング・システムに対して無効
な元来のファイル名から任意の文字が除去される。この
ファイル名はクライアント・オペレーティング・システ
ムが要求する長さおよび書式に合わせて短縮される（ス
テップ５２０）。次に、必要な場合には、特定のファイ
ルに対するインノード番号から切り取った文字を使用し
て、数個の文字が追加または重ね書きされる（ステップ
５３０）。簡単なインノード番号切り取りアルゴリズム
は、インノード番号モジュ−ラス１０００の３桁の小数
表示を短縮するためのものである。それ故、インノード
番号１２３４を持つ「ｌｏｎｇｆｉｌｅｎａｍｅ」の場
合には、ファイル名がろ過され「ｌｏｎｇｆｉｌｅ」に
短縮される。短縮されたインノード番号は、「２３４」
で、この「２３４」は、「ｌｏｎｇｆ２３４」を作るた
めに、「ｌｏｎｇｆｉｌｅ］の最後の三つの文字「ｉｌ
ｅ」の上に重ね書きされる。

【００２３】「ｌｏｎｇｆｉｌｅｎａｍｅ」ファイル
は、例えば、ＭＳ−ＤＯＳのＤＩＲコマンドによって、
「ｌｏｎｇｆ２３４」という計算された名前でＭＳ−Ｄ
ＯＳクライアントに報告され、計算された名前は、例え
ば、「ＰＲＩＮＴ ｌｏｎｇｆ２３４」のような、すべ
てのＭＳ−ＤＯＳコマンドで使用することができる。ホ
スト・コンピュータのファイル・サーバ・プログラム
は、二つの動作の処理、すなわち、ファイル名の報告お
よびファイル名へのアクセスを修正することによって、
上記変更を実行する。

【００２４】ファイル名をクライアント・コンピュータ
に報告するとき、サーバはファイル名がクライアント・
コンピュータのオペレーティング・システムに対して有
効かどうかを判断するために、各ファイルの名前を走査
する。名前がクライアント・コンピュータのオペレーテ
ィング・システムに対して有効である場合には、サーバ
はクライアント・コンピュータのオペレーティング・シ
ステムで有効であると同時に、ディレクトリで（疑似）
一意である上記アルゴリズムに従って、そのファイルに
対する名前を計算する。

【００２５】クライアントが、サーバ上のファイルにア
クセスするとき、クライアントは、サーバにクライアン
トのオペレーティング・システムの命名方法でファイル
名を渡す。上記の例においては、クライアントは、サー
バにＭＳ−ＤＯＳ８．３のファイル名を渡す。サーバ
は、このファイル名でファイルを発見しようとする。上
記の名前のファイルが存在しない場合には、サーバはそ
のファイル名は長いファイル名を８．３書式にマッピン
グした結果生成されたものであるとみなし、この長いフ
ァイル名を発見しようとする。サーバは、例えば、特定
ファイル名が上記の方法を使用して、８．３書式の名前
で発見されると考えられるディレクトリの各ファイル名
のマッピングを計算する。クライアントから受け取った
ファイル名は、結果として得られた名前と比較される。
一致する場合には、一致したものに対応する長いファイ
ル名が、クライアントが探している名前である。一致し
ない場合には、システムにファイルが存在しないと見な
される。すでに説明したように、本発明は、ＭＳ−ＤＯ
Ｓ以外のオペレーティング・システムを使用しているク
ライアントがアクセスしたファイルにも適用することが
できる。上記適用は、当業者なら理解できると思うが、
上記アルゴリズムを使用する類似の方法で行うことがで
きる。

【００２６】本発明が命名したファイルの一意性の確率
を高めるために、インノード関連の数値を含んでいる
が、このステップは、本発明にとって必ずしも必要でな
いことを理解されたい。本発明の他の好適な実施例の場
合には、必要に応じて、非合法の文字をホスト・ファイ
ル名から削除し、短縮している。必要な場合には、イン
ノード関連の数値を含むことができる。例えば、ＭＳ−
ＤＯＳオペレーティング・システム環境の場合には、フ
ァイル名「ｆｉｌｅ：２」は合法であるとは見なされな
い。なぜなら、コロンが使用されているからである。本
発明は、「：」文字を削除し、ファイル名をホスト・オ
ペレーティング・システムに対して合法的なものにする
ために、このファイルをすっきりと「ｆｉｌｅ２」また
は［ｆｉｌｅ＿２」に変換するか、他の何らかの有効な
置き換えを行う。

【００２７】さらに、本発明は、またホスト・オペレー
ティング・システムが、クライアントの装置のファイル
・システムよりもっと制限が厳しい場合に、異なるファ
イル命名パラメータの下で動作するコンピュータ装置
を、相互に接続するのに使用することができる。例え
ば、本発明を、マッキントッシュＣＤ−ＲＯＭと、ＭＳ
−ＤＯＳコンピュータとを接続するときに使用すること
ができる。（マッキントッシュのファイル名は最大３１
文字の長さにすることができることを思い出された
い。）本発明の他の類似の適用としては、ＵＮＩＸ Ｃ
Ｄ−ＲＯＭのＭＳ−ＤＯＳコンピュータでの使用、ウィ
ンドウズＮＴ／ウィンドウズ９５およびＵＮＩＸＣＤ−
ＲＯＭのマッキントッシュ・システムでの使用のような
類似の組み合わせ等がある。このような場合には、クラ
イアントのファイル名はホスト装置のオペレーティング
・システム上で使用できるように修正される。

【図面の簡単な説明】

【図１】 ホスト・コンピュータと、本発明の動作を説
明するのに役に立つそのオペレーティング・システムの
ブロック図である。

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

【図３】 本発明を説明する際に役に立つ種々の用語の
定義である。

【図４】 種々のオペレーティング・システムを使用し
ている、複数のユーザ・コンピュータに接続しているサ
ーバを持つ、ホスト・コンピュータを含むネットワーク
である。

【図５】 本発明の種々の動作の特徴を説明するための
フローチャートである。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 エレナ ネスベタエバ アメリカ合衆国 ニュージャージー州 07747 マタワン、レキシントン サーク ル 107

Claims (2)

【特許請求の範囲】
1. 【請求項１】 ホスト・オペレーティング・システムを
   使用しているホスト・コンピュータ（１００）と、上記
   ホスト・オペレーティング・システムとは異なるクライ
   アント・オペレーティング・システムを使用する場合が
   ある少なくとも一台のクライアント・コンピュータ・ネ
   ットワーク（４２０、４３０、４４０、４５０）のユー
   ザ間で共有しているコンピュータ・ファイル用の一意の
   ファイル名を計算する方法であって、 ファイル・サーバから、ファイル（２００）に対して、
   ホスト・コンピュータ（１００）固有のファイル名を命
   名するステップと、 上記ファイル・サーバによって、上記のファイルに割り
   当てられたインノード番号に、アクセスするステップ
   と、 一意のファイル名が、上記クライアント・オペレーティ
   ング・システムに対して有効なファイル名である場合
   に、一意のファイル名を作るために、上記ファイル名と
   上記のインノード番号とを、組み合わせるステップとを
   特徴とする方法。
2. 【請求項２】 上記のファイル・サーバを含み、ホスト
   ・オペレーティング・システムを使用しているホスト・
   コンピュータ（１００）と、上記ホスト・オペレーティ
   ング・システムとは異なるクライアント・オペレーティ
   ング・システムを使用する場合があるクライアント・コ
   ンピュータ（４２０、４３０、４４０、４５０）を含む
   コンピュータ・ネットワーク（１００、４２０、４３
   ０、４４０、４５０）のユーザ間で共有しているコンピ
   ュータ・ファイルを記憶するためのファイル・サーバ装
   置であって、 ファイル・サーバ装置から、ファイルに対して、ホスト
   ・コンピュータ（１００）固有のファイル名を命名する
   手段と、 上記ホスト・コンピュータによって上記ファイルに割り
   当てられたインノード番号に、アクセスするための手段
   と、 一意のファイル名が、上記クライアント・オペレーティ
   ング・システムに対して有効なファイル名である場合
   に、一意のファイル名を作るために、上記ファイル名
   と、上記のインノード番号とを組み合わせるための手段
   とを特徴とする装置。