JP2004334479A

JP2004334479A - 複数の名前空間に対応したｉｄ変換システム及び方法

Info

Publication number: JP2004334479A
Application number: JP2003128848A
Authority: JP
Inventors: Yasushi Shimono; 靖史下野
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2003-05-07
Filing date: 2003-05-07
Publication date: 2004-11-25

Abstract

【課題】異なるシステム間でファイルシステムを共有可能とするＩＤ変換システムと方法の提供。
【解決手段】データ処理装置２０は、ＩＤ変換用ファイルシステム２３に、登録された名前空間、クライアント側の名前空間、及び、ファイルシステムの名前空間を登録しておき、クライアント１０からの要求を受けたデータ処理装置２０はクライアントからの変換前のＩＤ、クライアント情報、アクセス対象のファイルシステム情報をもとにＩＤ変換用ファイルシステム上のクライアント側の名前空間に定義があるか否か、ＩＤ変換用ファイルシステム上のファイルシステム側の名前空間に定義があるか否かを調べ、入力された変換前のＩＤをもとに、クライアント側の名前空間に問い合わせて前記ＩＤから名前に変換し、前記ＩＤから変換された名前をもとに、ファイルシステム側の名前空間に問い合わせて名前からＩＤに変換し、変換されたＩＤを、クライアントに返却する。
【選択図】図４

Description

【０００１】
【発明の属する技術分野】
本発明は、情報処理システムに関し、特に、異なる環境化でのファイルシステムの共用化に適用して好適とされるＩＤ変換方法とシステムに関する。
【０００２】
【従来の技術】
あるコンピュータから別のコンピュータ上に存在するファイルシステムにアクセスする場合において、クライアント側のＩＤ（識別情報）と、ファイルシステム側のＩＤを一意に対応させる処理は、クライアント側のＩＤの所有者である実世界のユーザ（人間）が、そのファイルの所有者であることを保障する、という意味において、必要不可欠である。
【０００３】
上記のような異なるコンピュータ上のファイルシステムにアクセスする機能は、Ｍｉｃｒｏｓｏｆｔ社製Ｗｉｎｄｏｗｓ（登録商標）（ＣＩＦＳ［ＣｏｍｍｏｎＩｎｔｅｒｎｅｔＦｉｌｅＳｙｓｔｅｍ］）やＵＮＩＸ（登録商標）（ＮＦＳ［ＮｅｔｗｏｒｋＦｉｌｅＳｙｓｔｅｍ］）で標準的に実装されている。これらは、それぞれ、Ｗｉｎｄｏｗｓ（登録商標）やＵＮＩＸ（登録商標）システムの世界に閉じた実装がなされており、その意味で、ＩＤの一意性は、それなりに、保障されている。しかしながら、Ｗｉｎｄｏｗｓ（登録商標）−ＵＮＩＸ（登録商標）間で、ファイルシステムを共有する機能はどちらにも無い。さらに、両者とも、クライアントの環境やＮＦＳサーバの運用環境に大きく依存してしまう。
【０００４】
また、Ｓａｍｂａｓｕｉｔｅ（Ｓａｍｂａ−− ＡＷｉｎｄｏｗｓ（登録商標）ＳＭＤ［ＳｅｒｖｅｒＭｅｓｓａｇｅＢｌｏｃｋＰｒｏｔｏｃｏｌ］／ＣＩＦＳｆｉｌｅｓｅｒｖｅｒｆｏｒＵＮＩＸ（登録商標）；Ｓａｍｂａｓｕｉｔｅ−−ＵＮＩＸ（登録商標）用にＳＭＤをインプリメントしたプログラム集）のように、Ｗｉｎｄｏｗｓ（登録商標）−ＵＮＩＸ（登録商標）間でのファイルシステム共有を実現するものもある。しかし、Ｓａｍｂａでは、ファイルシステム側のＩＤを管理するのに、ＵＮＩＸ（登録商標）の伝統的な／ｅｔｃ／ｐａｓｓｗｄファイルを用いている。そのため、Ｓａｍｂａで公開しているファイルシステムをＮＦＳで共有しようとすると、ファイルシステム側のＩＤを二重管理することになる事態に陥ってしまう。これは、ＮＦＳでは、ＩＤ管理にＮＦＳ専用ファイルやＮＩＳサーバを利用するためである。
【０００５】
【発明が解決しようとする課題】
以上のように、従来のシステムにおいては、以下のような問題点がある。
【０００６】
・Ｗｉｎｄｏｗｓ（登録商標）（ＣＩＦＳ）やＮＦＳだけでは、Ｗｉｎｄｏｗｓ（登録商標）−ＵＮＩＸ（登録商標）間でファイルシステムを共有できない。
【０００７】
・クライアントやサーバのローカルな環境に大きく依存する。
【０００８】
・Ｗｉｎｄｏｗｓ（登録商標）−ＵＮＩＸ（登録商標）間でファイルシステムを共有するときのＩＤ管理が煩雑である。
【０００９】
したがって、本発明の目的は、例えばＷｉｎｄｏｗｓ（登録商標）−ＵＮＩＸ（登録商標）間等異なるＯＳ（オペレーティングシステム）間でファイルシステムを共有可能とするＩＤ変換方法及びシステムと装置を提供することにある。
【００１０】
また本発明の他の目的は、クライアントやサーバのローカルな環境に大きく依存することのないＩＤ変換方法及びシステムと装置を提供することにある。
【００１１】
さらに本発明のさらに別の目的は、例えばＷｉｎｄｏｗｓ（登録商標）−ＵＮＩＸ（登録商標）間でファイルシステムを共有するときのＩＤ管理の煩雑さを解消するＩＤ変換方法及びシステムと装置を提供することにある。
【００１２】
【課題を解決するための手段】
前記目的を達成する本発明の１つのアスペクトに係る方法は、クライアント側のＩＤから前記クライアントがアクセスするファイルシステムのＩＤへの変換を、少なくとも１つのデータ処理装置によって行う方法であって、前記データ処理装置のＩＤ変換用ファイルシステムに、登録された名前空間、クライアントがどの名前空間に属するかという情報を定義する、クライアント側の名前空間、及び、どのファイルシステムがどの名前空間に属するＩＤ情報を持つかという情報を定義する、ファイルシステム側の名前空間を登録しておき、前記データ処理装置は、以下のステップを含む。
（ａ）前記データ処理装置は、クライアントからのファイルアクセスに関する情報として変換前のＩＤ、クライアント情報、アクセス対象のファイルシステム情報を受け取る。
前記データ処理装置が、前記ＩＤ変換用ファイルシステムを参照して、前記クライアントがアクセス対象のファイルシステムにアクセスできる設定がなされているか調べる。
（ｂ）前記データ処理装置は、アクセス許可の設定がなされている場合、入力された変換前のＩＤをもとに、クライアント側の名前空間に属するＩＤを、名前に変換する。
（ｃ）前記データ処理装置は、前記ＩＤから変換された名前をもとに、ファイルシステム側の名前空間に属するＩＤに変換する。
（ｄ）前記データ処理装置は、変換されたＩＤを、前記クライアントに返却する。
【００１３】
本発明において、前記ＩＤ変換用ファイルシステムには、前記登録された名前空間、前記クライアント側の名前空間、及び、前記ファイルシステム側の名前空間が、ディレクトリ形式で登録される構成としてもよい。
【００１４】
本発明に係る方法において、前記データ処理装置は、ＩＤ変換用の設定上でアクセス許可があるか判断するにあたり、入力されたクライアント情報をもとに、前記ＩＤ変換用ファイルシステム上のクライアント側の名前空間に定義があるか否かを調べるとともに、アクセス対象のファイルシステム情報をもとに、前記ＩＤ変換用ファイルシステム上のファイルシステム側の名前空間に定義があるか否かを調べるようにしてもよい。前記クライアントは、前記ＩＤ変換用ファイルシステムから返却されたＩＤにてファイルアクセスを行う。
【００１５】
本発明の他のアスペクトに係るシステムは、クライアント側のＩＤから前記クライアントがアクセスするファイルシステムのＩＤへの変換を行うＩＤ変換システムであって、登録された名前空間、クライアントがどの名前空間に属するかという情報を定義する、クライアント側の名前空間、及び、どのファイルシステムがどの名前空間に属するＩＤ情報を持つかという情報を定義する、ファイルシステム側の名前空間を記憶するＩＤ変換用ファイルシステムと、クライアントからのファイルアクセスに関する情報として変換前のＩＤ、クライアント情報、アクセス対象のファイルシステム情報を受け取る手段と、前記ＩＤ変換用ファイルシステムを参照して、前記クライアントのアクセス対象のファイルシステムへのアクセス許可の設定の有無を調べる手段と、アクセス許可の設定がなされている場合、入力された変換前のＩＤをもとに、クライアント側の名前空間に属するＩＤを、名前に変換する手段と、前記ＩＤから変換された名前をもとに、ファイルシステム側の名前空間に属するＩＤに変換する手段と、変換されたＩＤを、前記クライアントに返却する手段と、を備えている。
【００１６】
【発明の実施の形態】
本発明の好適な発明の実施の形態について以下に説明する。本発明は、あるコンピュータから別のコンピュータ上に存在するファイルシステムにアクセスする場合に、クライアントであるユーザが、Ｗｉｎｄｏｗｓ（登録商標）、ＮＩＳ、ローカルなパスワードファイル等のどのような名前空間に属していても、ユーザの識別子（以下、「ユーザＩＤ」という）とファイルシステム側のファイルの識別子（「ファイルのＩＤ」という）との一意性を保障するためのＩＤ（識別情報）変換機構を提供する。
【００１７】
本発明は、クライアントと通信接続するデータ処理装置が、ＩＤ変換用ファイルシステムに、前記ＩＤ変換用ファイルシステムには、登録された名前空間ディレクトリの配下に名前空間が定義され、クライアント側の名前空間ディレクトリの配下に、クライアントがどの名前空間に属するかという情報が定義され、及び、ファイルシステム側の名前空間ディレクトリの配下に、どのファイルシステムがどの名前空間に属するＩＤ情報を持つかという情報が定義され、前記ＩＤ変換用ファイルシステムのルートディレクトリのもとに、前記登録された名前空間、前記クライアント側の名前空間、及び、前記ファイルシステム側の名前空間の各ディレクトリが登録されている。
【００１８】
クライアントから、変換前のＩＤ、クライアント情報、アクセス対象のファイルシステム情報を入力し、入力されたクライアント情報をもとに、ＩＤ変換用ファイルシステム上のクライアント側の名前空間に定義があるか否かを調べるとともに、アクセス対象のファイルシステム情報をもとに、前記ＩＤ変換用ファイルシステム上のファイルシステム側の名前空間に定義があるか否かを調べることで、クライアントによるアクセス対象のファイルシステムへのアクセス許可の設定がなされているか否かを調べる。ＩＤ変換用ファイルシステムの設定上で、当該ファイルシステムへのアクセス許可の設定がなされている場合、入力された変換前のＩＤをもとに、クライアント側の名前空間に問い合わせて前記ＩＤから名前に変換し、前記ＩＤから変換された名前をもとに、ファイルシステム側の名前空間に問い合わせて名前からＩＤに変換し、変換されたＩＤを、クライアントに返却する。前記クライアントは、前記ＩＤ変換用ファイルシステムから返却されたＩＤにてファイルアクセスを行う。
【００１９】
本発明の実施の形態において、クライアントとファイルシステムは、同一又は異なる名前空間に属するものとされる。
【００２０】
本発明の実施の形態において、クライアントとファイルシステムの名前空間の定義は、クライアントおよびファイルシステムから独立させており、前記ＩＤ変換用ファイルシステムで管理する。
【００２１】
本発明の実施の形態において、ＩＤ又は名前の変換にあたり、名前空間に対応する検索モジュールに変換要求が発せられ、前記検索モジュールが名前空間記憶部を検索することで、クライアント側の名前空間に属するＩＤを名前に変換する。また、名前空間に対応する検索モジュールに変換要求が発せられ、前記検索モジュールが名前空間記憶部を検索し、名前空間に変換された名前をもとに、ファイルシステム側の名前空間に属するＩＤに変換する。
【００２２】
本発明の実施の形態において、前記ファイルシステム側の名前空間の定義情報の中に、名前を変換するルールを定義しておき、前記ルールを参照して変換を行うようにしてもよい。このルールは、前記クライアント側の名前を、ファイルシステムの名前空間の名前に変換する名前変換ルールよりなる。
【００２３】
本発明の実施の形態において、ＩＤ変換、又は名前の変換結果はキャッシュとして保持され、変換要求に対する応答がキャッシュされている場合、キャッシュから取得し、キャッシュされていない場合に、該当する変換を行うようにしてもよい。
【００２４】
本発明の実施の形態において、変換が失敗した場合、エラー情報がキャッシュとして保持するようにしてもよい。
【００２５】
かかる構成の本発明によれば、あるユーザの作成したファイルが確かにそのユーザの作成したファイルであるということを、全てのユーザに保障できる。
【００２６】
図１は、本発明の原理を説明するための図である。ユーザとファイルシステムは、それぞれ、必ず、ある名前空間に属することとする。ユーザとファイルシステムが同じ名前空間に属することも、許可される。図１に示す例では、名前空間Ｃは、ユーザ側とファイルシステム側のそれぞれに存在している。
【００２７】
逆の言い方をすると、ユーザもファイルシステム上のファイルも、それぞれが所有するＩＤが、実際は誰に与えられたものであっても、どこかの名前空間に属することを強要される。このように、強制的に名前空間を割り当てることで、「どのユーザが、どのファイルシステム（のファイル）にアクセスしたのか」を明確に定義することができる。
【００２８】
この定義は、本発明のシステム内で、閉じて行われる。つまり、名前空間の定義を、クライアントおよびサーバのマシンから独立させる。
【００２９】
このように、本発明によれば、名前空間の定義を、クライアントおよびサーバのマシンから独立させることで、従来の手法のように、暗黙のうちに、名前空間が決定されるのではなく、ユーザのＩＤやファイルのＩＤがどの名前空間において管理されているかが明確化される。このため、各マシンの管理者やユーザは、自らの所属を、明確に意識できる。
【００３０】
また、図１からわかることとして、一つファイルシステムに、複数の名前空間からアクセスできることも、本発明の特徴の一つである。図１に示す例では、名前空間Ｃのファイルシステムは、名前空間Ｂと名前空間Ｃのユーザからのアクセスが許可され、名前空間Ｄのファイルシステムは、名前空間Ａと名前空間Ｃのユーザからのアクセスが許可される設定とされている。
【００３１】
さらに、名前空間の種類（Ｗｉｎｄｏｗｓ（登録商標）、ＮＩＳなど）にも、依存しない（この点については後述する）。
【００３２】
図２は、本発明における名前空間の定義方法とその割り当て方法を説明するための図である。図２に示されるように、それぞれの情報は、「ＩＤ変換用ファイルシステム」上において、ルートディレクトリのもとに、ディレクトリツリー構造として保存される。「ＩＤ変換用ファイルシステム」は、本発明のシステムが取り扱う、全ての名前空間を定義する「登録された名前空間」ディレクトリ、その中でクライアントの属する名前空間を定義する「クライアント側の名前空間」ディレクトリ、同じくファイルシステムの属する名前空間を定義する「ファイルシステム側の名前空間」ディレクトリから構成される。そして「ＩＤ変換用ファイルシステム」において、これらの名前空間の情報は一元的に定義・管理される。
【００３３】
このように、ファイルシステムという一般的な構造を用いることで、従来の変換方式では不可能であった（人間にも、内部機能の実装においても）、直感的な操作を可能としていることも、本発明の特徴の一つである。
【００３４】
図２を参照して、さらに詳細に説明する。名前空間は、図２における「登録された名前空間」ディレクトリ配下に定義される。図２では、４つの名前空間（ＮＩＳ［ＮｅｔｗｏｒｋＩｎｆｏｒｍａｔｉｏｎＳｅｒｖｉｃｅ］Ａ，ＮＩＳＢ，ＰＤＣ［ＰｒｉｍａｒｙＤｏｍａｉｎＣｏｎｔｒｏｌｌｅｒ］Ａ，ＦｉｌｅＢ）が定義されているが、名前空間は、ＮＩＳでも、ドメインコントローラでも、あるいは変換情報が格納されたファイルであってもよい。なお、ＮＩＳはＵＮＩＸ（登録商標）システム間でシステム構成情報、ユーザ情報を共有する目的で用いられ、Ｗｉｎｄｏｗｓ（登録商標）ＮＴ４．０のＰＤＣに対応している。
【００３５】
次に、図２における「クライアント側の名前空間」ディレクトリ配下に、どのクライアントがどの名前空間に属するか、という情報が定義される。ここで定義されないクライアントは、どのファイルシステムにもアクセスできない。
【００３６】
本明細書中で、「クライアント」とは、
・アクセス主体である単体のユーザ（あるいはグループ、以下同じ）であってもよいし、
・一つの計算機上の全てのユーザであってもよいし、
・あるネットワーク上の全てのユーザであってもよいし、
・あるドメイン上の全てのユーザであってもよい。
【００３７】
重要なことは、アクセスしてくるユーザを特定することである。
【００３８】
そして、図２における「ファイルシステム側の名前空間」ディレクトリ配下に、どのファイルシステム（のファイル）がどの名前空間に属するＩＤを持ちうるか、という情報が定義される。「ファイルシステム側の名前空間」ディレクトリ配下に定義されないファイルシステムには、どのクライアントからも、アクセスできない。
【００３９】
図２が示されていることがらは、「クライアント側の名前空間」ディレクトリに定義のあるクライアントから、「ファイルシステム側の名前空間」ディレクトリに定義のあるファイルシステムに対してのみアクセスが許可される、ということである。ただし、どちらも「登録された名前空間」ディレクトリに定義された名前空間を用いなければならない。
【００４０】
図３は、本発明の一実施の形態におけるＩＤ変換手順を説明するための流れ図である。図３を参照して、本発明の一実施の形態におけるＩＤ変換動作の一例を説明する。
【００４１】
ステップＡ１にて、ファイルアクセスに関連する、各種情報（変換前ＩＤ、クライアント情報、アクセス対象ファイルシステム情報）が、ＩＤ変換用ファイルシステムに入力される。
【００４２】
ステップＡ１にて、ＩＤ変換用設定検索処理を行う。すなわち、クライアント情報をもとに、ＩＤ変換用ファイルシステム上の「クライアント側の名前空間」に定義があるかを調べ、アクセス対象ファイルシステム情報をもとに、ＩＤ変換用ファイルシステム上の「ファイルシステム側の名前空間」に定義があるかを調べる。
【００４３】
ステップＡ２から、クライアント情報が「クライアント側の名前空間」に定義されており、且つ、ファイルシステム情報が「ファイルシステム側の名前空間」に定義されており、アクセス許可があることがわかると、入力されたＩＤをもとに、ステップＡ３にて、クライアント側の名前空間に問い合わせてＩＤから名前に変換する。クライアント側の名前空間への問い合わせとして、例えば、後述するように、名前空間に対応するＩＤ変換モジュールにＩＤの変換要求を行い、ＩＤ変換モジュールが名前空間記憶部を検索して名前に変換し、変換結果を応答として返す処理が行われる。
【００４４】
次に、ステップＡ４にて、ＩＤから変換された名前をもとに、ファイルシステム側の名前空間に問い合わせて、名前からＩＤに変換する。ファイルシステム側の名前空間への問い合わせとして、例えば、後述するように、名前空間に対応するＩＤ変換モジュールにＩＤの変換要求を行い、ＩＤ変換モジュールが名前空間記憶部を検索して名前に変換し、変換結果を応答として返す処理が行われる。
【００４５】
そして、ステップＡ５にて、最終的に得られたＩＤをクライアントに返却する。
【００４６】
以上の、ステップからわかるように、本発明においては、名前をベースとしてＩＤ変換を行う。言い換えれば、クライアント側の名前空間と、ファイルシステム側の名前空間の両方に同じ名前のあるユーザは、同一ユーザであると定義する。図１の説明で、複数の名前空間から一つのファイルシステムにアクセスでき、しかも、名前空間の種類に依存しないと記載した理由は、これである。すなわち、「ＩＤは名前空間の数だけ定義があるが、名前は基本的に実世界に依存する」という暗黙の了解を前提として、ＩＤを一対一に対応付けることで、ＩＤの一意性を保障している。
【００４７】
本発明の一実施の形態の特徴をまとめると、以下のようになる。
【００４８】
・ユーザとファイルシステムを、必ず、ある名前空間に属すると定義することで、従来技術のように、暗黙のうちに、名前空間が決定されるのではなく、ユーザのＩＤやファイルのＩＤがどの名前空間において管理されているかが、明確化される。このため、各マシンの管理者やユーザは、自らの所属を明確に意識できる。
【００４９】
・ユーザやファイルシステムが属する名前空間は、どのように定義されてもよいし、それぞれの名前空間は何によって管理されてもよい。つまり、名前空間の組み合わせは、何にも依存しない。
【００５０】
かかる柔軟な構造により、本発明の一実施の形態によれば、以下のような作用効果を奏する。
【００５１】
・あるユーザとファイルシステムの組み合わせにおいて、ユーザの属する名前空間とファイルシステムが属する名前空間の間に依存関係が無くなる。例えば、従来技術では難しかった、ＮＩＳドメインに属するユーザと、Ｗｉｎｄｏｗｓ（登録商標）ドメインに属するユーザとが、同じファイルシステムを共有することも、単純な設定だけで可能となる。
【００５２】
・複数の名前空間から、一つのファイルシステムにアクセスすることも可能である。
【００５３】
・ＩＤ変換機構として、「ＩＤ変換用ファイルシステム」を新たに用いている。ファイルシステムを、ＩＤ変換に利用するという考え方は、従来には、無く（本発明が全く新規に導入）、これにより、名前空間の定義などにおいて、直感的な操作が可能となる。
【００５４】
【実施例】
本発明を適用した具体例をなすいくつかの実施例について図面を参照して以下に説明する。図４は、本発明に係るシステムの一実施例を説明するための図であり、システム構成を機能ブロックとして表したものである。図４において、等価な機能ブロックには、Ｂで始まる同一の符号が付されている。図４を参照すると、データ処理装置Ｘ（２０）は、クライアントＡ（１０_２）、クライアントＢ（１０_１）と、インターネット等の通信ネットワークを介して通信接続する。また、データ処理装置Ｘ（２０）は、データ処理装置Ａ（３０_１）、データ処理装置Ｂ（３０_２）と、ネットワークを介して通信接続する。
【００５５】
機能Ｂ１（２１）は、クライアントからの「ＩＤ変換要求」を受け付け、変換結果をクライアントに返却する処理を行う機能ブロックであり、リモートファイルアクセスのサーバ機能である。機能Ｂ１（２１）は、一般的には、公知のＳａｍｂａ（ＣＩＦＳ）（２１_１）や、ＮＦＳモジュール（２１_２）としてユーザ空間やカーネル空間に実装される。
【００５６】
機能Ｂ２（論理部）（２２）は、機能Ｂ１から、ＩＤ変換要求を受けると、機能Ｂ３（２３）を経由して機能Ｂ４（２５）に変換要求を出し、機能Ｂ４（２５）から機能Ｂ３（２３）を介して得られた変換結果を機能Ｂ１（２１）に返却する機能ブロックである。
【００５７】
機能Ｂ３（２３）は、前述した「ＩＤ変換用ファイルシステム」に対応しており、変換の設定情報を保持したり、変換処理の媒介をなす機能ブロックである。変換処理の媒介は、図４において、機能Ｂ３（２３）上のＩＤ変換ファイル（２４）として示されているが、変換の成否にかかわらず、変換結果は、機能Ｂ３（２３）上に、キャッシュとして残される。よって、キャッシュが残っていれば、機能Ｂ２（２２）は、そのキャッシュに格納される情報を機能Ｂ１（２１）に返却すればよいし、キャッシュが残っていなければ、機能Ｂ３を介して、新たに、機能Ｂ４（２５）に変換要求が出される。
【００５８】
機能Ｂ４（２５）は、機能Ｂ５（３０）に、ＩＤまたは名前を渡して、変換結果を問い合わせ、返却された変換結果を、機能Ｂ３（２３）上のファイル（２４）に反映する機能ブロックである。機能Ｂ４（２５）は名前空間毎に設けられている。図４に示す例では、機能Ｂ４（２５）として、名前空間Ａ、Ｂに対応して、変換要求等の交渉を行うネゴシエータＡ、Ｂが設けられている。
【００５９】
機能Ｂ５（「ＩＤ検索モジュール」、あるいは「ＩＤ検索デーモン」ともいう）（３０）および機能Ｂ６（名前空間記憶部）（３１）は、ＩＤ変換を行う機能ブロックである。具体的には、機能Ｂ５（３０）は、機能Ｂ４（２５）から渡されたＩＤまたは名前を、機能Ｂ６（３１）から検索し、変換結果を、機能Ｂ４（２５）に返却する。機能Ｂ５（３０）および機能Ｂ６（３１）は、通常、ＮＩＳサーバ、ドメインコントローラ、ＬＤＡＰ（ＬｉｇｈｔｗｅｉｇｈｔＤｉｒｅｃｔｏｒｙＡｃｃｅｓｓＰｒｏｔｏｃｏｌ）サーバなどとして実装される。また、機能Ｂ６（３１）は、ＵＮＩＸ（登録商標）の／ｅｔｃ／ｐａｓｓｗｄのようなファイルとしても存在しうる。ただし、この場合、機能Ｂ６（３１）単体では、ＩＤ検索できないため、機能Ｂ５（３０）は、機能Ｂ４（２５）に統合される。
【００６０】
図４では、機能Ｂ５および機能Ｂ６は、機能Ｂ１〜Ｂ４とは異なるデータ処理装置３０上に実装されている例として示されているが、同じデータ処理装置２０内に存在してもよいことは勿論である。
【００６１】
本実施例において、特筆すべき点として、機能Ｂ４（２５）は、名前空間（機能Ｂ５および機能Ｂ６）毎に存在するが、機能Ｂ３（および機能Ｂ２）とのインターフェースは、変わらない、ということである。
【００６２】
これにより、本実施例においては、名前空間（機能Ｂ５および機能Ｂ６）の新規追加・削除に対して、他の機能ブロックを修正することなく、機能Ｂ４を追加・削除するだけで、対処することが可能となる。これは、本実施例において、名前をベースとしたＩＤ変換を行うようにした結果である。
【００６３】
以下に、図４、図５、図６を用いて、本発明の一実施例の動作について説明する。ただし、「クライアント」とは、前述したとおり、一人以上のユーザ（またはグループ）であればよい。
【００６４】
最初に、クライアントから機能Ｂ１に対して、ＩＤ変換要求が出される。これをもとに、機能Ｂ１（２１）は、渡されたＩＤ・クライアントの位置情報・アクセス対象であるファイルシステムの位置情報を機能Ｂ２（２２）に渡す（ステップＣ１）。
【００６５】
機能Ｂ２（２２）は、渡された情報をもとに、機能Ｂ３（２３）上の定義情報を検索し、クライアントが対象ファイルシステムにアクセスできる設定がなされているかを調べる（ステップＣ２）。検索は、図２の「登録された名前空間」、「クライアント側の名前空間」、「ファイルシステム側の名前空間」の各ディレクトリに対して行われる。設定が不足している場合、機能Ｂ２（２２）は、機能Ｂ１（２１）に対して、「アクセスが許可されていない」としてエラーを返す（ステップＣ１０）。この時点でのエラーは、そもそも要求を出したクライアントには、ファイルシステムへのアクセス権限が無いことを示す。
【００６６】
ステップＣ２で設定が完全になされていることがわかると、機能Ｂ２（２２）は、まず機能Ｂ３（２３）の「クライアント側の名前空間」として定義された名前空間を、「登録された名前空間」ディレクトリ（図２参照）から検索し（ステップＣ３）、機能Ｂ３上に、ＩＤ変換ファイル（２４）を新たに作成して、機能Ｂ４（２５）に対して変換要求を出す（ステップＣ４）。
【００６７】
機能Ｂ４（２５）は、機能Ｂ３（２３）を介して、変換前のＩＤを受け取り、機能Ｂ５（３０）（ＩＤ変換デーモン３０）に対して、変換要求を出す。機能Ｂ５（３０）は、変換要求を受けると、機能Ｂ６（３１）から渡されたＩＤを検索する。検索が成功すれば、機能Ｂ４（２５）に、変換後の、変換前ＩＤに対応する名前を返し、一方、検索に失敗すれば、機能Ｂ５（３０）は、機能Ｂ４（２５）に対しエラーを返す（ステップＣ４、Ｃ５）。
【００６８】
機能Ｂ４（２５）は、返却された情報を調べて（ステップＣ５）、エラーであれば、即座に機能Ｂ３（２３）の当該ＩＤ変換ファイル（２４）にエラー情報を書き込む。機能Ｂ２２（２２）は、これを受けて機能Ｂ１（２１）にエラーを返す（ステップＣ１０）。
【００６９】
この時点でのエラーは、クライアントとして要求を出してきたユーザが（管理者が設定したであろう）「クライアントの名前空間」として定義された名前空間に存在しなかったという意味であり、運用の不備、設定ミス、あるいは不正アクセスがあった、などの可能性を示唆している。
【００７０】
一方、検索が成功し、機能Ｂ５（３０）が機能Ｂ４（２５）に対して、変換後の名前を返却すると、機能Ｂ４（２５）は、その返却結果を、当該ＩＤ変換ファイル（２４）に書き込む。
【００７１】
以上の処理は、要求を出したクライアントのＩＤが、少なくとも「クライアント側の名前空間」として定義された名前空間には存在することを示す。
【００７２】
次に、機能Ｂ２（２２）は、機能Ｂ４（２５）から変換が成功したという情報を受けると、変換結果である名前をもとに、今度は、機能Ｂ３のＩＤ変換用ファイルシステム（２３）の「ファイルシステム側の名前空間」として定義された名前空間を、「登録された名前空間」ディレクトリから検索し、「登録された名前空間」ディレクトリに、ＩＤ変換ファイル（２４）のキャッシュが残っているかどうかを調べる（ステップＣ６、ステップＣ７）。キャッシュが残っていない場合、機能Ｂ５（３０）に変換要求を発する。
【００７３】
以降の処理手順は、上記のＩＤから名前に変換する手順とほぼ同様であり、違いは、変換方向がＩＤから名前か、名前からＩＤか、という一点のみである。つまり、変換要求の内容は異なっても、処理手順としては同一となる。そして、エラーの持つ意味も同様となる。
【００７４】
ステップＣ８にて変換が成功したことが確定すると、機能Ｂ２（２２）は、機能Ｂ１（２１）に、「ＩＤ変換成功」として結果を返す（ステップＣ９）。この意味するところは、クライアントのＩＤが示すユーザは、「ファイルシステム側の名前空間」として定義された名前空間にも存在する、ということである。言い換えれば、クライアントのＩＤが示すユーザは、対象ファイルシステムへのアクセス権を持つことを示している。
【００７５】
以上、本発明の実施例の動作の原理を説明したが、以下に具体的な例をあげる。
【００７６】
図６において、ユーザは、名前空間Ａに属し、ファイルシステムは、名前空間Ｂに属している。ユーザは、「ＩＤ５００」を持ち、ファイルシステム上のファイルにアクセスを試みている。ここで、各名前空間は、全て定義済みであるとする。
【００７７】
図６において、ユーザがアクセスを試みると（ステップＣ１）、まず名前空間の定義が行われているかが調べられる（ステップＣ２）。図６では、名前空間は全て定義済みなので、次に、ＩＤを名前に変換すべく、名前空間Ａに、変換要求が出される（ステップＣ３、Ｃ４）。
【００７８】
名前空間Ａでは、「ＩＤ５００」は、名前「ｕｓｅｒＡ」と等価であるため、「ＩＤ５００」は、「ｕｓｅｒＡ」という名前に変換される。
【００７９】
変換が成功したので（ステップＣ５）、次に名前からＩＤに変換すべく、名前空間Ｂに変換要求が出される（ステップＣ６、Ｃ７）。名前空間Ｂでは名前「ｕｓｅｒＡ」は、「ＩＤ６００」と等価であるため、名前「ｕｓｅｒＡ」は「ＩＤ６００」に変換される。
【００８０】
名前からＩＤへの変換が成功したので（ステップＣ８）、最終的に得られた「ＩＤ６００」という値が、クライアントに返却される（ステップＣ９）。
【００８１】
この結果、クライアント側のユーザはファイルシステムへのアクセス権を入手することとなる。
【００８２】
以上、クライアント側のＩＤをファイルシステム側のＩＤに変換する処理について説明したが、この処理は、実世界で次の意味を持つ。
【００８３】
・対象となるファイルシステムへのアクセス権限チェック
・対象となるファイルシステム上へのファイル作成権限チェック
・対象となるファイルシステム上のファイルの削除権限チェック
【００８４】
つまり、以上に記述された処理が成功することは、上記権限を持つことを意味する。
【００８５】
次は、上記とは逆の処理として、ファイルシステム側のＩＤをクライアント側のＩＤに変換する処理について説明する。
【００８６】
「ファイルシステム側のＩＤをクライアント側のＩＤに変換する」という処理は、これまで述べてきた処理と全く反対方向の処理であるが、処理手順は、同様である。違いは、
・変換前ＩＤが、クライアント側のものか、ファイルシステム側のものか、という点、
・変換後ＩＤが、クライアント側のものか、ファイルシステム側のものか、
という点の二点である。
【００８７】
ＩＤ変換という観点から見れば、変換前と変換後のＩＤがどちらに属していようと、処理としては、全く同様となる。
【００８８】
次に、ファイルシステム側のＩＤをクライアント側のＩＤに変換する処理は、実世界でどのような意味を持つのかについてみると、以下のようなものとなる。
・対象となるファイルシステム上のファイルの閲覧権限チェック
【００８９】
つまり、「ファイルシステム側のＩＤをクライアント側のＩＤに変換する」処理が成功することは、上記のとおり、ファイルの閲覧権限を持つことを意味する。
【００９０】
以上説明したように、本発明によれば、以下の効果を奏する。
【００９１】
・異なる名前空間に属するそれぞれのユーザ・グループのＩＤをシームレスに変換できる（ＵＮＩＸ（登録商標）−ＵＮＩＸ（登録商標）でも、Ｗｉｎｄｏｗｓ（登録商標）−ＵＮＩＸ（登録商標）でも）。
【００９２】
・名前空間を指定するので、ファイルシステムにアクセスするユーザ・グループと、ファイルの所有者を明確に定義できる。
【００９３】
・名前空間を指定するので、ファイルシステムにアクセスできるユーザ・グループを容易に限定できる。
【００９４】
・ファイルシステム側のＩＤが一つに定まるので、複数の名前空間に同一ユーザが属する場合でも、ファイルの所有者を一意に決定できる。
・名前空間の新規追加・削除が容易である（図４の機能Ｂ４を追加・削除するだけでよい）。
【００９５】
本発明は、クライアント側の名前空間とファイルシステム側の名前空間を明確に定義し、両者のＩＤを名前をベースに対応付けることで、ＩＤの一意性を保障している。しかし、名前空間が異なれば、全く同じユーザ名が二つの名前空間に存在する確率は高くない。完全に名前が一致するユーザの数が少なければ、ファイルシステムにアクセスできるユーザの数も少なくなるので、利便性に欠ける。しかし、逐一、名前空間を修正することは、運用として、管理者の手間が膨大に膨れ上がるという可能性も考えられる。
【００９６】
この問題は、クライアント側の名前空間に属するＩＤを名前に変換した時点で、次にファイルシステム側の名前空間に属するＩＤを検索する前に、名前を変換する機能を、本発明に追加することで、回避可能である。
【００９７】
図７に示すように、「ファイルシステム側の名前空間」の定義の中に、新たに「名前を変換するルール」を定義する。また、図４の機能Ｂ２（論理部）に、このルールを参照できる機能を追加する。
【００９８】
図７を用いて、一例を説明する。図７に示す例では、二つの名前変換ルールが追加されている。ただし、ここでは、「クライアント」とは、あるユーザの集合を表す。
【００９９】
１．「クライアントＡのｕｓｅｒＡは、ファイルシステムＡにおいてはｕｓｅｒＢとして扱われる」
【０１００】
２．「クライアントＢの全てのユーザは、ファイルシステムＡにおいてはａｎｏｎｙｍｏｕｓｕｓｅｒ（不特定ユーザ）として扱われる」
【０１０１】
一つ目のルールは、クライアントＡの「ｕｓｅｒＡ」という名前のユーザが、ファイルシステムＡにアクセスする場合は、まず、「ｕｓｅｒＢ」という名前に変換され、次に、「ｕｓｅｒＢ」という名前が「ファイルシステム側の名前空間」においてＩＤに変換されることを示す。
【０１０２】
二つ目のルールは、クライアントＢからのどのユーザも、ファイルシステムＡでは「ａｎｏｎｙｍｏｕｓｕｓｅｒ」（アノニマス・ユーザ）として扱われる。つまり、クライアントＢからはファイルシステムＡに対してａｎｏｎｙｍｏｕｓ（アノニマス）アクセスのみが許可されることを意味する。どのようなルールを定義するかで、さまざまなアクセスパターンをユーザに与えることができる。
【０１０３】
図７に示した例以外にも、「一度「ファイルシステム側の名前空間」において名前からＩＤに変換し、失敗したらルールを適用する」というルールを用いてもよい。これは、「ファイルシステム側の名前空間」に存在しないユーザにも、ファイルシステムへのアクセスを許可する、ということを意味する。これにより、「ファイルシステム側の名前空間」に存在しないユーザには、ａｎｏｎｙｍｏｕｓ（アノニマス）アクセスを許す、という運用が可能となる。
【０１０４】
ルールを定義する場所が、「クライアント側の名前空間」の定義の中ではない理由は、この機能は、あくまでファイルシステム側の名前空間が主体であり、ファイルシステムへアクセスするユーザに対して、適用されるべきものだからである。逆に、クライアント側の名前空間に対して名前変換ルールを定義しても、複数のファイルシステム側の名前空間に変換後のルールを逐一設定しなければならず、意味が無い。
【０１０５】
次に、本発明の実施例の変形例について説明する。ある名前空間において、ＩＤと名前の組み合わせは、それほど頻繁に変更されることはない。よって、ある程度の期間においては、同じＩＤは、同じ名前に変換されるし、その逆もまた然りである。
【０１０６】
図４に示した本実施例では、クライアントから変換要求が出される度に、毎回機能Ｂ２から、機能Ｂ４に対して変換要求を出しているが、前述のようなＩＤの変更頻度を考慮すると、処理として効率化の点で、改善の余地がある。
【０１０７】
そこで、本実施例の変形例では、図４の機能Ｂ３「ＩＤ変換用ファイルシステム」上に生成されるＩＤ変換ファイルを、キャッシュとして扱う。つまり、ＩＤ変換ファイル２４は、一度生成されると、使用された後も、機能Ｂ３上に残り続けることとする。ある変換要求が、既に一度変換され、キャッシュされたＩＤまたは名前に対してのものであれば、機能Ｂ２は、機能Ｂ４に要求を出すことなく、機能Ｂ３上にキャッシュされたＩＤ変換ファイルを参照するだけでよい。つまり、本実施例の変形例によれば、機能Ｂ４、機能Ｂ５、機能Ｂ６におけるＩＤまたは名前の検索処理を、バイパスすることができる。このため、ＩＤ変換処理時間が、大きく短縮される。
【０１０８】
名前空間において、機能Ｂ３上にキャッシュされたＩＤや名前が変更された場合には、該当するキャッシュを削除してしまえば、再度、機能Ｂ２は、機能Ｂ４に対してＩＤ変換要求を出す。
【０１０９】
また、ある変換要求が失敗すれば、キャッシュにはエラー情報が書き込まれる。エラー情報を持つキャッシュを放置すれば、以降の変換要求は、即座に失敗するが、当該キャッシュを削除すれば、再度、機能Ｂ４に変換要求が出されるようになる。その時点で、以前変換に失敗したＩＤや名前が、名前空間に登録されていれば、再度出された要求は成功するかもしれない。成功するしないにかかわらず、再度の変換要求の結果も、またキャッシュされる。
【０１１０】
キャッシュを削除するタイミングは、名前空間においてキャッシュされたＩＤまたは名前が変更された時点や変換結果がエラーであることが確定した時点などに設定してもよい。あるいは、定期的（例えば、１日毎）に削除するようにしてもよい。
【０１１１】
図８は、本実施例で追加された処理手順を説明するための流れ図である。図４及び図８を参照して、本実施例の動作について説明する。以下では、図８において、図５の流れ図との相違点を主に説明し、同一処理手順の説明は適宜省略する。
【０１１２】
「クライアント側の名前空間」にてＩＤから名前に変換する場合、機能Ｂ２は、まず機能Ｂ３上にキャッシュが存在するかどうかを調べる（ステップＤ４）。
【０１１３】
キャッシュが存在していれば、キャッシュされた情報がエラーであるかどうかを調べて（ステップＤ５）、エラーであれば即座にＩＤ変換は失敗であるとして、エラーがクライアントに返却される（ステップＤ１８）。
【０１１４】
キャッシュされた情報が以前変換に成功したものを示していれば、「クライアント側の名前空間」にてＩＤから名前の変換に成功したこととなるので、その変換結果である名前に対して名前変換ルールが定義されているかどうかを調べる（ステップＤ６、ステップＤ１５）。
【０１１５】
名前変換ルールが定義されていなければ、変換結果である名前を使用して「ファイルシステム側の名前空間」においてＩＤへの変換を試みる（ステップＤ７）。名前変換ルールが定義されていれば、ルールに従って名前を変換し（ステップＤ１６）、変換された名前でＩＤへの変換を試みる（ステップＤ７）。
【０１１６】
「ファイルシステム側の名前空間」において、名前からＩＤに変換する処理も、基本的には、上述した手順と同様に、キャッシュの有無、名前変換ルールの定義の有無を調べて、変換処理を進める。
【０１１７】
図７、図８、図９を用いて、以下に具体的な例に即して説明する。ただし、図７の名前変換ルールにおける「ｃｌｉｅｎｔＡ」は、図９における「名前空間Ａ」に対応し、図７の名前変換ルールにおける「ｆｉｌｅｓｙｓｔｅｍＡ」は、図９における「名前空間Ｂ」に対応するものとする。
【０１１８】
図９において、ユーザは名前空間Ａに属し、ファイルシステムは名前空間Ｂに属している。ユーザは「ＩＤ５００」を持ち、ファイルシステム上のファイルにアクセスを試みている。ここで、各名前空間は、全て定義済みであるとする。
【０１１９】
図９において、ユーザがアクセスを試みると（図８のステップＤ１）、まず名前空間の定義が行われているかが調べられる（図８のステップＤ２）。図９では、名前空間は全て定義済みであるため、次に、ＩＤを名前に変換すべく、機能Ｂ３上に、キャッシュが存在するかどうかを調べる（図８のステップＤ４）。
【０１２０】
キャッシュが存在し、かつ、キャッシュにある情報は、変換成功を示すものであるとすると、キャッシュから変換後の名前である「ｕｓｅｒＡ」が得られるため、次に、変換後の名前に対して、名前変換ルールが定義されているかどうかを調べる。
【０１２１】
図７に示すとおりに、名前変換ルールが定義されているとすると、「ｕｓｅｒＡ」という名前は、ルール「ｕｓｅｒＡｏｎｃｌｉｅｎｔＡｉｓ．．．」というルールに該当することがわかる（図８のステップＤ６、ステップＤ１５）。
【０１２２】
よって、該当するルールに従って、名前「ｕｓｅｒＡ」は、「ｕｓｅｒＢ」へと変換される（図８のステップＤ１６）。
【０１２３】
これ以降は、キャッシュが調べられること（図８のステッＤ８、Ｄ９）を除いては、前記実施例で説明した処理手順と同様である。ただし、名前からＩＤへの変換には、名前変換ルールに基づき、「ｕｓｅｒＢ」という名前が使用される。
【０１２４】
以上本発明を上記実施例に即して説明したが、本発明は、上記実施例の構成にのみ限定されるものでなく、本発明の原理の範囲内で当業者であればなし得るであろう各種変形、修正を含むことは勿論である。
【０１２５】
【発明の効果】
以上説明したように、本発明によれば、あるコンピュータから別のコンピュータ上に存在するファイルシステムにアクセスする場合に、クライアントであるユーザが、例えばＷｉｎｄｏｗｓ（登録商標）・ＮＩＳ・ローカルなパスワードファイル等のどのような名前空間に属していても、ユーザ側のＩＤとファイルシステム側のファイルのＩＤとの一意性を保障するためのＩＤ変換機構を提供している。このため、本発明によれば、あるユーザとファイルシステムの組み合わせにおいて、ユーザの属する名前空間とファイルシステムが属する名前空間の間に依存関係が無くなり、異なるドメインに属するユーザが、同じファイルシステムを共有することも、単純な設定だけで可能となる。
【０１２６】
本発明によれば、複数の名前空間から、一つのファイルシステムにアクセスすることも可能である。
【０１２７】
また、本発明によれば、ＩＤ変換機構として、ＩＤ変換用ファイルシステムを新たに用いており、名前空間の定義などにおいて、直感的な操作が可能となる。
【０１２８】
本発明によれば、異なる名前空間に属するそれぞれのユーザ・グループのＩＤをシームレスに変換できる。
【０１２９】
本発明によれば、名前空間を指定するので、ファイルシステムにアクセスするユーザ・グループと、ファイルの所有者を明確に定義できる。
【０１３０】
本発明によれば、名前空間を指定するので、ファイルシステムにアクセスできるユーザ・グループを容易に限定できる。
【０１３１】
本発明によれば、ファイルシステム側のＩＤが一つに定まるので、複数の名前空間に同一ユーザが属する場合でも、ファイルの所有者を一意に決定できる。本発明によれば、名前空間の新規追加・削除が容易である。
【図面の簡単な説明】
【図１】本発明を説明するための模式図である。
【図２】本発明の一実施の形態におけるＩＤ変換用ファイルシステムのディレクトリ構成を示す図である。
【図３】本発明の一実施の形態の動作を説明するための流れ図である。
【図４】本発明の一実施例のシステムの機能構成を示した図である。
【図５】本発明の一実施例の動作を説明するための流れ図である。
【図６】本発明の一実施例の具体例を説明するための流れ図である。
【図７】本発明の別の実施例をＩＤ変換用ファイルシステムのディレクトリ構成を示す図である。
【図８】本発明の別の実施例の動作を説明するための流れ図である。
【図９】本発明の別の実施例の具体例を説明するための流れ図である。
【符号の説明】
１０クライアント
２０データ処理装置
２１ＣＩＦＳモジュール（ＮＦＳモジュール）
２２論理部
２３ＩＤ変換用ファイルシステム
２４変換用ファイル
２５ナビゲータＡ（Ｂ）
３０データ処理装置
３１記憶装置

Claims

クライアント側のＩＤ（識別情報）から前記クライアントがアクセスするファイルシステムのＩＤへの変換を、少なくとも１つのデータ処理装置によって行う方法であって、
前記データ処理装置のＩＤ変換用ファイルシステムに、
登録された名前空間、
クライアントがどの名前空間に属するかという情報を定義する、クライアント側の名前空間、及び、
どのファイルシステムがどの名前空間に属するＩＤ情報を持つかという情報を定義する、ファイルシステム側の名前空間、
のそれぞれの情報を登録しておき、
前記データ処理装置は、クライアントからのファイルアクセスに関する情報として変換前のＩＤ、クライアント情報、アクセス対象のファイルシステム情報を受け取る第１のステップと、
前記データ処理装置が、前記ＩＤ変換用ファイルシステムを参照して、前記クライアントがアクセス対象のファイルシステムにアクセスできる設定がなされているか調べる第２のステップと、
前記データ処理装置は、アクセス許可の設定がなされている場合、入力された変換前のＩＤをもとに、クライアント側の名前空間に属するＩＤを、名前に変換する第３のステップと、
前記データ処理装置は、前記ＩＤから変換された名前をもとに、ファイルシステム側の名前空間に属するＩＤに変換する第４のステップと、
前記データ処理装置は、変換されたＩＤを、前記クライアントに返却する第５のステップと、
を含む、ことを特徴とするＩＤ変換方法。
前記ＩＤ変換用ファイルシステムには、
登録された名前空間ディレクトリの配下に名前空間が定義され、
クライアント側の名前空間ディレクトリの配下に、クライアントがどの名前空間に属するかという情報が定義され、及び、
ファイルシステム側の名前空間ディレクトリの配下に、どのファイルシステムがどの名前空間に属するＩＤ情報を持つかという情報が定義され、
前記ＩＤ変換用ファイルシステムのルートディレクトリのもとに、前記登録された名前空間、前記クライアント側の名前空間、及び、前記ファイルシステム側の名前空間の各ディレクトリが登録されている、ことを特徴とする請求項１記載のＩＤ変換方法。
前記第２のステップが、前記データ処理装置が、入力された前記クライアント情報をもとに、前記ＩＤ変換用ファイルシステム上のクライアント側の名前空間に定義があるか否かを調べるステップと、
入力された前記アクセス対象のファイルシステム情報をもとに、前記ＩＤ変換用ファイルシステム上のファイルシステム側の名前空間に定義があるか否かを調べるステップと、
を含む、ことを特徴とする請求項１記載のＩＤ変換方法。
前記クライアントは、前記ＩＤ変換用ファイルシステムから返却されたＩＤにて前記ファイルシステムのアクセスを行う、ことを特徴とする請求項１記載のＩＤ変換方法。
前記第３のステップでは、前記データ処理装置と同一又は別のデータ処理装置上において、名前空間に対応する検索モジュールに変換要求が発せられ、前記検索モジュールが名前空間記憶部を検索することで、クライアント側の名前空間に属するＩＤを名前に変換する、ことを特徴とする請求項１記載のＩＤ変換方法。
前記第４のステップでは、前記データ処理装置と同一又は別のデータ処理装置において、名前空間に対応する検索モジュールに変換要求が発せられ、前記検索モジュールが名前空間記憶部を検索し、名前空間に変換された名前をもとに、ファイルシステム側の名前空間に属するＩＤに変換する、ことを特徴とする請求項１記載のＩＤ変換方法。
前記クライアントとファイルシステムの名前空間の定義は、前記ＩＤ変換用ファイルシステムで管理され、前記クライアントおよび前記ファイルシステムから独立している、ことを特徴とする請求項１記載のＩＤ変換方法。
前記ファイルシステム側の名前空間の定義情報の中に、名前を変換するルールを定義しておき、前記ルールを参照して変換を行う、ことを特徴とする請求項１記載のＩＤ変換方法。
前記クライアント側の名前を、ファイルシステムの名前空間の名前に変換するルールである、ことを特徴とする請求項８記載のＩＤ変換方法。
ＩＤ変換、又は名前の変換結果はキャッシュとして保持され、
変換要求に対する応答がキャッシュされている場合、キャッシュから取得し、キャッシュされていない場合に、該当する変換を行う、ことを特徴とする請求項１又は８記載のＩＤ変換方法。
変換が失敗した場合、エラー情報がキャッシュとして保持される、ことを特徴とする請求項１記載のＩＤ変換方法。
クライアント側のＩＤ（識別情報）から前記クライアントがアクセスするファイルシステムのＩＤへの変換を行うＩＤ変換システムであって、
登録された名前空間、
クライアントがどの名前空間に属するかという情報を定義する、クライアント側の名前空間、及び、
どのファイルシステムがどの名前空間に属するＩＤ情報を持つかという情報を定義する、ファイルシステム側の名前空間、
のそれぞれの情報を記憶するＩＤ変換用ファイルシステムと、
クライアントからのファイルアクセスに関する情報として変換前のＩＤ、クライアント情報、アクセス対象のファイルシステム情報を受け取る手段と、
前記ＩＤ変換用ファイルシステムを参照して、前記クライアントのアクセス対象のファイルシステムへのアクセス許可の設定の有無を調べる手段と、
アクセス許可の設定がなされている場合、入力された変換前のＩＤをもとに、クライアント側の名前空間に属するＩＤを、名前に変換する手段と、
前記ＩＤから変換された名前をもとに、ファイルシステム側の名前空間に属するＩＤに変換する手段と、
変換されたＩＤを、前記クライアントに返却する手段と、
を含む、ことを特徴とするＩＤ変換システム。
前記ＩＤ変換用ファイルシステムには、
登録された名前空間ディレクトリの配下に名前空間が定義され、
クライアント側の名前空間ディレクトリの配下に、クライアントがどの名前空間に属するかという情報が定義され、及び、
ファイルシステム側の名前空間ディレクトリの配下に、どのファイルシステムがどの名前空間に属するＩＤ情報を持つかという情報が定義され、
前記ＩＤ変換用ファイルシステムのルートディレクトリのもとに、前記登録された名前空間、前記クライアント側の名前空間、及び、前記ファイルシステム側の名前空間の各ディレクトリが登録されている、ことを特徴とする請求項１２記載のＩＤ変換システム。
前記アクセス許可の設定の有無を調べる手段が、
入力された前記クライアント情報をもとに、前記ＩＤ変換用ファイルシステム上のクライアント側の名前空間に定義があるか否かを調べる手段と、
入力された前記アクセス対象のファイルシステム情報をもとに、前記ＩＤ変換用ファイルシステム上のファイルシステム側の名前空間に定義があるか否かを調べる手段と、
を含む、ことを特徴とする請求項１２記載のＩＤ変換システム。
前記クライアントは、前記ＩＤ変換用ファイルシステムから返却されたＩＤにてファイルアクセスを行う、ことを特徴とする請求項１２記載のＩＤ変換システム。
名前空間に対応した検索モジュールと、
名前空間記憶部と、
を備え、
ＩＤから名前への変換要求をうけた前記検索モジュールは、前記名前空間記憶部を検索することで、クライアント側の名前空間に属するＩＤを名前に変換する、ことを特徴とする請求項１２記載のＩＤ変換システム。
名前空間に対応した検索モジュールと、
名前空間記憶部と、
を備え、
名前空間に対応する検索モジュールに変換要求が発せられ、前記検索モジュールが名前空間記憶部を検索し、名前空間に変換された名前をもとに、ファイルシステム側の名前空間に属するＩＤに変換する、ことを特徴とする請求項１２記載のＩＤ変換システム。
前記クライアントとファイルシステムの名前空間の定義は、前記ＩＤ変換用ファイルシステムで管理され、前記クライアントおよび前記ファイルシステムから独立している、ことを特徴とする請求項１２記載のＩＤ変換システム。
前記ＩＤ変換用ファイルシステムにおいて、前記ファイルシステム側の名前空間の定義情報の中に、名前を変換するルールを定義しておき、
前記ルールを参照して、変換を行う手段を備えている、ことを特徴とする請求項１２記載のＩＤ変換システム。
前記クライアント側の名前を、ファイルシステムの名前空間の名前に変換するルールである、ことを特徴とする請求項１８記載のＩＤ変換システム。
ＩＤ変換、又は名前の変換結果はキャッシュとして保持され、
変換要求に対する応答がキャッシュされている場合、キャッシュから取得し、キャッシュされていない場合に、該当する変換を行う、ことを特徴とする請求項１２又は１９記載のＩＤ変換システム。
変換が失敗した場合、エラー情報がキャッシュとして保持される、ことを特徴とする請求項１２記載のＩＤ変換システム。
少なくとも１つのクライアントと通信接続するデータ処理装置を備え、
前記データ処理装置は、少なくとも第１乃至第４の機能ブロックを有し、
前記第１の機能ブロックは、クライアントからのＩＤ（識別情報）変換要求を受け付け、ＩＤ変換要求を前記第２の機能ブロックに出力し、前記第２の機能ブロックからの変換結果を前記クライアントに返却し、
前記第２の機能ブロックは、前記第１の機能ブロックからＩＤ変換要求を受けると、ＩＤ変換用ファイルシステムをなす前記第３の機能ブロックを経由して前記第４の機能ブロックに変換要求を出し前記第４の機能ブロックから前記第３の機能ブロックを介して得られた変換結果を、前記第１の機能ブロックに返却し、
前記第３の機能ブロックは、変換の設定情報を保持するとともに、変換を媒介し、登録された名前空間、クライアント側の名前空間、及び、ファイルシステムの名前空間をそれぞれディレクトリ形式で、ＩＤ変換用ファイルシステムにて、保持し、かつ、変換ファイルをキャッシュとして保持し、
前記第４の機能ブロックは、前記データ処理装置又は前記データ処理装置の別の前記データ処理装置に設けられている第５の機能ブロックに対して、ＩＤまたは名前を渡して、変換結果を問い合わせ、前記第５の機能ブロックから返却された変換結果を、前記第３の機能ブロック上の前記変換ファイルに反映し、
前記第５の機能ブロックは、前記第４の機能ブロックから渡されたＩＤまたは名前を、前記第５の機能ブロックによってアクセスされる記憶装置の名前空間記憶部から検索し、変換結果を、前記第４の機能ブロックに返却する、
ことを特徴とするＩＤ変換装置。
前記第２の機能ブロックは、前記クライアントから入力された、変換前のＩＤ、クライアント情報、アクセス対象のファイルシステム情報をもとに、前記ＩＤ変換用ファイルシステム上のクライアント側の名前空間に定義があるか否かを調べるとともに、アクセス対象のファイルシステム情報をもとに、前記ＩＤ変換用ファイルシステム上のファイルシステム側の名前空間に定義があるか否かを調べ、ＩＤ変換用の設定上でアクセス許可がある場合、前記第２の機能ブロックは、入力された変換前のＩＤをもとに、前記第３の機能ブロックのクライアント側の名前空間として定義された名前空間を、登録された名前空間ディレクトリから検索し、前記第３の機能ブロック上に、ＩＤ変換ファイルを新たに作成し、前記第４の機能ブロックに対して変換要求を出す、ことを特徴とする請求項２３記載のＩＤ変換装置。
前記第４の機能ブロックは、前記第３の機能ブロックを介して、変換前のＩＤを受け取り、前記第５の機能ブロックに対して、変換要求を出し、
前記第５の機能ブロックは、変換要求を受けると、前記第６の機能ブロックから渡されたＩＤを検索し、検索が成功すれば、前記第４の機能ブロックに、変換後の、変換前ＩＤに対応する名前を返し、一方、検索に失敗すれば、前記第５の機能ブロックは、前記第４の機能ブロックにエラーを返し、
前記第４の機能ブロックは、返却された情報を調べ、エラーであれば、前記第３の機能ブロックの当該ＩＤ変換ファイルにエラー情報を書き込み、前記第３の機能ブロックは、これを受けて前記第１の機能ブロックにエラーを返し、
検索が成功し、前記第５の機能ブロックが前記第４の機能ブロックに対して、変換後の名前を返却すると、前記第４の機能ブロックは返却結果を、前記ＩＤ変換ファイルに書き込み、
前記第２の機能ブロックは、前記第４の機能ブロックから変換が成功したという情報を受けると、変換結果である名前をもとに、ファイルシステム側の名前空間として定義された名前空間を、登録された名前空間ディレクトリから検索し、登録された名前空間ディレクトリに、ＩＤ変換ファイルのキャッシュが残っているかどうかを調べ、名前からＩＤを求め、キャッシュが残っていない場合、前記第２の機能ブロックは、入力された名前をもとに、前記第３の機能ブロックのクライアント側の名前空間として定義された名前空間を、登録された名前空間ディレクトリから検索し、前記第３の機能ブロック上に、ＩＤ変換ファイルを新たに作成し前記第４の機能ブロックに対して変換要求を出す、ことを特徴とする請求項２３記載のＩＤ変換装置。
前記ＩＤ変換用ファイルシステム内の前記ファイルシステム側の名前空間の定義情報の中に、前記クライアント側の名前を、ファイルシステムの名前空間の名前に変換するルールを備え、
前記ルールを参照して変換を行う手段を備えている、ことを特徴とする請求項２３記載のＩＤ変換装置。
前記第３の機能ブロックにおいて、ＩＤ変換ファイルが、キャッシュとして管理され、
前記第２の機能ブロックは、クライアント側のＩＤから名前に変換する場合、及び、ファイルシステム側の名前からＩＤに変換する場合に、前記第３の機能ブロックにキャッシュの有無を調べ、キャッシュが存在し、その内容がエラーでない場合、キャッシュされている内容を変換結果として扱う、ことを特徴とする請求項２３記載のＩＤ変換装置。