JP2006350829A - ファイルバージョン管理装置及び方法とプログラム - Google Patents

Abstract

【課題】リモートアクセス環境等において、履歴データを保存する装置の提供。
【解決手段】バージョン管理装置は、要求パケット応答パケットを取得しパケット内に含まれている処理要求および応答結果を抽出し、データ更新処理動作に相当するアクセスパターンに合致しているか照合するファイルアクセス検証部と、要求パケットに含まれる処理要求がどのユーザにより要求されたものなのかを検証するためにユーザ情報を管理するユーザ管理部と、ファイルアクセス検証部でアプリケーションによるファイルのデータ更新処理に相当する処理パターンに相当する操作が実行されたことを契機として、バージョン管理用のファイルの作成操作を制御するバージョン制御部と、ファイルアクセス検証部、ユーザ管理部、バージョン制御部が動作するに当たって必要となる動作設定情報を保持する設定情報管理部を備えている。
【選択図】図２

Description

本発明は、ファイルバージョン管理装置及び方法とプログラムに関する。本発明に係るファイルバージョン管理装置は、コンピューティング環境におけるデータの共有装置である、ネットワーク接続型のファイル格納装置に付加する装置に適用して好適とされる。本発明に係るファイルバージョン管理装置は、ファイル格納装置に格納されたファイルのデータが、複数のクライアントマシンにより更新されることにより生じるバージョン違いを管理する装置に適用して好適とされる。

＜既存のファイル管理ストレージ装置について＞
複数のクライアントコンピュータで生成したファイルを、ネットワークを介することで複数のクライアントマシン間で共有するサーバストレージ装置として、ＮＡＳ（Network Attached Storage）やファイルサーバなどがある。

サーバ装置は、ＮＦＳ（Network File System）プロトコルやＣＩＦＳ（Common Internet File System）プロトコルといった、汎用のクライアント装置が業界標準としてサポートしているファイルアクセスプロトコルに対応しており、装置導入の際、ユーザが特別なソフトウェアやハードウェアをクライアントに追加しなくても、サーバ装置を利用できるようになっている。また、ユーザは、クライアント上に実装されているファイルマネージャなどを使うことにより、ＮＦＳプロトコルやＣＩＦＳプロトコルを介して、クライアントマシンのローカルファイルシステムに格納されているファイルと同様に、サーバ装置内のファイルにアクセスすることが可能となっている。

サーバストレージ装置に一旦格納されたファイルは、クライアントマシンから、ＮＦＳプロトコルやＣＩＦＳプロトコルを用いて、データの更新を実施することが可能となっている。しかし、更新されたデータの保存がサーバストレージ装置で完了した後は、クライアントは、データ更新前の状態のファイルに再びアクセスすることができない。

したがって、ユーザによる操作ミスや他ユーザによる予期しないデータ更新に伴って、ユーザが必要とするデータが消失してしまった場合には、ユーザが必要とするデータを取り出すことができなくなる、といった問題があった。

＜既存のファイルバージョン管理システムについて＞
このような問題を解決するために、
・データの変更履歴に連動して、複数のバージョンのファイルを保存するストレージ装置や、
・ある瞬間でのファイルの状態を定期的に保存しておき、その瞬間に保存したファイルデータを時系列で並べて配置してクライアントに提供する「スナップショット」と呼ばれる機能をもったストレージ装置、
等が提案されている。

データの変更履歴に連動して複数のバージョンのファイルを保存するストレージ装置は、一般に、ストレージ装置に既に格納されているファイルに対して、
・該ファイルのデータをダウンロードすることにより取得する機能、および、
・データの更新が完了したファイルをアップロードすることにより、既に格納されているファイルのデータと置き換える機能、
をクライアントに提供している。

ストレージ装置は、クライアントからのデータのアップロード操作をファイルのバージョン更新の契機として判断し、既にストレージ装置に格納されているアップロード前のデータを削除せずに、アップロードされたデータと共にアップロード履歴をインデックス化して保存しておくことにより、データの更新履歴に連動した複数のバージョンのファイルのデータを管理することが可能となっている。

しかし、データ更新履歴に連動したダウンロード、アップロードの操作は、ストレージ装置固有のアプリケーション、インターフェース、もしくはプロトコルを用いて行われるため、ストレージ装置に保存されたファイルは、一般のＮＡＳやファイルサーバに保存されているファイルとは異なり、クライアントからは、ファイルマネージャを通して、クライアントのローカルファイルと同様に扱うことができない、という問題があった。

この問題により、ユーザは、ストレージ装置に格納したファイルを編集する際には、クライアントのローカルファイルの操作とは別のアプリケーションやインターフェースを使って実行しなければならない、という煩わしさがあった。

一方、スナップショット機能を持ったストレージ装置は、一般に、ストレージ管理者がスケジューリング、もしくは直接投入したスナップショットコマンドを契機として、コマンド投入時点でのデータを、後々クライアントによりデータ更新操作があったとしても、変更せずに別途保存しておくことで、コマンド実行を時系列と関連付けてインデックス化した複数のバージョンのデータを保存しておくことが可能となっている。

これにより、ユーザは、スナップショットコマンドが投入された時間を目安として、過去のバージョンのファイルのデータへアクセスすることが可能となっている。

しかし、スナップショットを用いたファイルのバージョン作成は、ユーザのファイルの編集操作と連動して行われるわけではない。このため、ユーザが意図した状態のファイルを保存しておくことができず、ユーザは必要とするデータに必ずしもアクセスできない、という問題があった。

このようなファイルのバージョン管理システムにおける問題に対する解決策として、非特許文献１では、既存のファイルサーバと、クライアントマシンのネットワーク間に、特殊なネットワーク・ブリッジ装置を設置し、ブリッジ装置内でＮＦＳプロトコルのパケットの更新に関する操作情報を抽出して、ブリッジ装置内の記憶領域へ更新データを反映させつつ、ファイルのバージョン管理を行う装置（ファイル更新履歴保存システム）が提案されている。このシステムは、クライアントとサーバ間のパケットを監視し、ファイルの更新履歴を保存するものである。この装置（システム）を用いることにより、従来、特殊なインターフェースしか活用できなかったファイルバージョン管理システムにおけるクライアントマシン上での使い勝手の悪さの問題と、クライアントの更新動作に連動していないスナップショットによるファイルのバージョン管理における更新履歴データとしての不完全性を解決することができる。

種村,新城,板野,千葉「ネットワークの監視技術を用いたファイル更新履歴保存システムの実現」 情報処理学会論文誌 コンピューティングシステム Vol.44 No.SIG10 （2003）.

ファイルサーバなどを用いて複数のクライアント間でデータを共有するような環境において、ファイルのバージョン管理を目的として、クライアント側で標準のファイルアクセスプロトコルに対応した既存のインターフェースを用い、また、クライアント側の更新処理に連動させたファイルのバージョン管理を実施することを考えた場合、上記非特許文献１のような、標準ファイルアクセスプロトコルのすべての更新要求を抽出し、また更新要求に連動して、複数バージョンのファイルを作成することは有効な手段である。

しかしながら、ファイルサーバに転送される更新処理を全て履歴として残したとしても、全てのファイルの履歴データがユーザにとって有用なものになり得るとは限らない。例えば、あるアプリケーションでは、あるファイルを生成、もしくは更新する際、ファイルの更新データを反映させた最終形態のファイルを生成する前に、一時的にデータを保存しておくための一時ファイルを作成する場合がある。一時ファイルは、アプリケーションにとっては意味のあるファイルであるが、所望のファイルが生成もしくはデータが保存された後は、アプリケーションによって自動的に削除されてしまうため、ユーザにとって、意識的にアクセスすることはないファイルといえる。

以上のように、上記非特許文献１で提案されている技術を活用した場合、ファイルアクセスプロトコルの更新処理に関する全ての要求を抽出して、ファイルシステム全体のファイルデータに対して、無条件で履歴データを残してしまうため、一時ファイルのような、ユーザが意図してアクセスすることのないデータまでもが、履歴データとして残ってしまい、履歴データを格納するストレージ資源を無駄に浪費する、といった課題があった。

したがって、本発明の目的は、バージョン作成動作を意識することなく履歴データをストレージに保存し、その際、ストレージ領域の浪費を回避する装置を提供することにある。

本発明は、上記目的を達成するにあたり、ユーザにとって意味のあるファイルについてのみ履歴データを自動的に作成して保存することで、効率的なストレージの運用を実現可能とする装置及び方法とプログラムを提供することにある。

前記課題を解決するために、本発明は、ファイルへのアクセスのコマンド・コンテキスト（例えばコマンド要求、該要求の応答等のシーケンス）を解析し、コマンド・コンテキストが予め定められた所定のパターンと一致しているか照合し、前記所定のパターンに一致したものである場合、前記所定のパターンに応じて、バージョン管理用の情報を作成するようにしたものである。

本発明は、ＮＦＳプロトコルやＣＩＦＳプロトコルを用いてファイルサーバやＮＡＳへアクセスするような、通常のリモートファイルアクセス環境に適用した場合において、アプリケーションの所定のファイル更新処理動作に連動したファイルアクセスパターンを抽出することで、ユーザにとって、履歴として残しておく価値のあるファイルのみの履歴データをファイルとして残す。

本発明は、クライアントマシンからＮＦＳプロトコルやＣＩＦＳプロトコルを用いて送信されるアクセス要求を解析する機能と、解析結果に連動したファイルのバージョン管理機能をもったファイルサーバを備えるか、もしくは、既存のファイルサーバの前段に、前記解析機能とバージョン管理機能と、ファイルアクセスプロトコルのパケットをクライアントマシンとファイルサーバ間で中継する機能をもったスイッチ装置を用いる。

本発明において、ファイルのバージョン管理機能は、ファイルサーバの管理者によって、予め登録されたアプリケーションの更新処理動作に連動したファイルアクセスパターンに、ファイルアクセスのパケットから抽出した操作要求、および操作結果が該当しているかを検証する手段と、アプリケーションによるファイルの更新動作処理パターンと合致したファイルアクセスパケットを取得した際に、バージョン管理用ファイルを作成する手段を備える。

本発明の別のアスペクトに係る方法は、ファイルへのアクセスのコマンド・コンテキストを解析し、前記コマンド・コンテキストが前記ファイルのバージョン管理用ファイル作成の契機となる所定のパターンに対応したものであるか判定する工程と、前記コマンド・コンテキストがバージョン管理用ファイルの作成の契機となる所定のパターンに対応したものである場合、前記ファイルのバージョン管理用ファイルを作成し保存する工程と、を含む。

本発明において、ファイルのバージョンを自動管理するバージョン管理装置が、ファイルの処理の要求パケットを取得し、前記要求パケットの処理要求内容が予め登録されているパターンと一致しているか判定し、一致している場合、処理要求内容の情報を記憶する第１の工程と、
前記バージョン管理装置が、前記要求パケットに対する応答パケットを取得し、前記第１の工程で記憶されている処理要求内容とから、前記ファイルのバージョン管理用ファイル作成の契機の条件と一致する処理結果であるか判定し、一致した場合、処理要求が完了した旨を登録する第２の工程と、
前記バージョン管理装置が、前記第１と第２の工程を、前記バージョン管理用ファイル作成の契機となる全ての処理が完了するまで繰り返し、記憶しておいた要求内容に基づきバージョン管理用ファイルを作成する第３の工程と、
を含むようにしてもよい。

本発明のさらに別のアスペクトに係るコンピュータ・プログラムは、バージョン管理用ファイルを自動作成するためのプログラムであって、ファイルへのアクセスのコマンド・コンテキストを解析し、前記コマンド・コンテキストが前記ファイルのバージョン管理用ファイル作成の契機となる所定のパターンに対応したものであるか判定する処理と、前記コマンド・コンテキストがバージョン管理用ファイルの作成の契機となる所定のパターンに対応したものである場合、前記ファイルのバージョン管理用ファイルを作成し保存する処理と、をコンピュータに実行させるプログラムよりなる。該コンピュータ・プログラムは、コンピュータで読み出し可能な記録媒体等に記録され、コンピュータで主記憶に読み出し実行することで、上記各処理が実現される。

本発明を適用したファイルサーバもしくはスイッチ装置を用いることにより、ファイルのバージョン管理専用のインターフェースを利用しない、ＮＦＳプロトコルやＣＩＦＳプロトコルなどを活用した、標準のリモートファイルアクセス環境において、ユーザはバージョン作成動作を意識することなく、履歴データが保存されることで利便性が向上するとともに、ユーザにとって意味のあるファイルについてのみ該ファイルの履歴データが自動的に作成されるため、履歴データ保存用のストレージ領域を浪費することなく、効率的なストレージの運用を実現することができる。

次に、本発明を実施する最良の形態のシステム構成について図面を参照して説明する。図１は、本実施形態におけるシステム構成を示している。本実施の形態では、少なくとも1台以上のクライアント１００と、ＮＦＳプロトコルやＣＩＦＳプロトコルによるファイルアクセスサービスを提供する少なくとも1台以上のサーバ２００と、クライアント１００とサーバ２００の間でファイルのバージョン管理を実施するバージョン管理装置３００と、を備えている。各装置は、ＬＡＮ（Local Area Network）などのローカルネットワーク１に接続されており、ローカルネットワーク１を介して相互に通信することが可能となっている。

サーバ２００は、ファイルシステム２０１および記憶装置２０２を備えており、ＮＦＳプロトコルやＣＩＦＳプロトコルを介して、外部の装置から送信されたファイルアクセス要求を受けて、ファイルシステム２０１で管理されている記憶装置２０２に格納されているデータを外部の装置へ提供する。

バージョン管理装置３００は、クライアント１００より特定のファイルアクセスプロトコルを用いて送信されたサーバ２００向けの全ての要求を中継して、サーバ２００へ転送すると共に、該要求に対して、サーバ２００により送信されたクライアント１００向けの全ての応答を中継して、クライアント１００へ転送する。

したがって、クライアント１００は、クライアント１００で稼動するアプリケーションを利用するユーザの操作に従い、サーバ２００に格納されているファイルのデータにアクセスする必要がある場合には、特定のファイルアクセスプロトコルによるアクセス要求を、バージョン管理装置３００へ送信することで、サーバ２００に格納されているファイルのデータにアクセスすることができる。

ネットワーク１と他の装置との接続方法は、クライアント１００とサーバ２００間でやり取りされるファイルアクセスパケットが、バージョン管理装置３００によって中継できるような構成であれば、図１の接続方法のみによらず、クライアント１００とサーバ２００用のネットワークセグメントを別々に構築し、どちらのセグメントにも接続したバージョン管理装置３００によって、前記ネットワークセグメント間でパケットを転送させるなどの接続方法としても良い。

図２は、図１のバージョン管理装置３００の構成の一例を示したものである。バージョン管理装置３００は、ファイルアクセス検証部３０１と、ユーザ管理部３０２と、バージョン制御部３０３と、設定情報管理部３０４を備えている。

ファイルアクセス検証部３０１は、クライアント１００から送られる要求パケット、およびサーバ２００から送られる応答パケットを取得し、それぞれのパケットの内に含まれている処理要求および応答結果を抽出する。そして、処理要求、応答結果が、クライアント１００で稼動するアプリケーションによるファイルのデータ更新処理動作に相当するアクセスパターンに合致しているか否か照合する。アクセスパターン情報は、設定情報管理部３０４の記憶部３０５に記憶されているが、本発明はかかる構成に制限されるものでなく、ファイルアクセス検証部３０１内の記憶部（不図示）に配設してもよいことは勿論である。また、特に制限されないが、アクセスパターン情報は、更新処理動作を、ｉｆ ｔｈｅｎ ｅｌｓｅ形式の規則で規定しておき、ファイルアクセス検証部３０１は、該規則に基づき、データ更新処理動作であるか否かを判定するようにしてもよい。

ユーザ管理部３０２は、クライアント１００から送られる要求パケットに含まれる処理要求が、どのユーザにより要求されたものであるかを検証するために、ファイルアクセスプロトコルごとに定められた形式で、ユーザ情報を管理しておく。

バージョン制御部３０３は、ファイルアクセス検証部３０１において、クライアント１００で稼動するアプリケーションによるファイルのデータ更新処理に対応する処理パターンに相当する操作が実行されたことを契機として、新たなバージョン管理用のファイル（「バージョンファイル」と略記される）の作成操作を制御する。

設定情報管理部３０４には、ファイルアクセス検証部３０１、ユーザ管理部３０２、バージョン制御部３０３のそれぞれが動作するに当たって、必要とする（参照する）動作設定情報が格納されている。

バージョン管理装置３００の構成については、図１に示すとおり、サーバ３００とは別の装置として構成する他に、バージョン管理装置３００内の各機能部をサーバ２００内部に組み込んだ構成としても良い。

＜バージョンファイルの格納方法について＞
次に、バージョン管理機能を特に持たない一般のファイルサーバやＮＡＳ装置をサーバ２００として使った場合における、バージョン管理装置３００による、サーバ２００へのバージョンファイルの格納方法について説明する。

図３は、サーバ２００へのバージョンファイルの格納例を示したものである。まず、クライアント１００が、一般にファイルアクセスを行う通常ファイルデータ格納領域４００の他に、バージョン管理用のファイルを格納するバージョンファイルデータ格納領域４０１を、サーバ２００のファイルシステム２０１もしくは記憶装置２０２から新たに作成したファイルシステム内、もしくはサーバ２００とは別のサーバ上に作成する。

サーバ２００にて、ディレクトリＡ４０２が共有ディレクトリとして、クライアントに対して公開されていた場合、バージョン管理装置３００により、ディレクトリＡ４０２に相当するディレクトリＡ’４０６を、バージョンファイルデータ格納領域４０１へ作成する。

バージョンファイルデータ格納領域４０１のディレクトリＡ’４０６には、サーバ２００内にバージョンファイルデータ格納領域４０１を作成する場合においては、ディレクトリＡ４０２の共有名と競合しないように、ディレクトリＡ４０２とは異なる名前を付与して、一般のクライアントへは、読み出し専用となる共有ディレクトリとしてアクセスできるように公開する。

ディレクトリＡ４０２配下のオブジェクトについては、新たにバージョンファイルが作成される際に、バージョン管理装置３００によって、バージョンファイル格納先までのパス上のオブジェクトのみが、バージョンファイルデータ格納領域４０１に作成される。バージョン管理装置３００は、バージョンファイル格納先までのパス上のオブジェクトがディレクトリであった場合、図３の例のように、通常ファイルデータ格納領域４００のディレクトリＣ４０４と同名のディレクトリＣ４０７を作成し、配下のオブジェクトがファイルであった場合、つまりバージョンファイルの作成元のファイルである場合には、通常ファイルデータ格納領域４００のファイルＤ４０５のファイル名に、バージョン管理装置３００固有の特殊ワードや符号を付けるなどしたディレクトリ名のディレクトリＤ’４０８を作成する。

ディレクトリＤ’４０８には、ファイルＤ４０５の更新履歴データ管理用のバージョンファイル４０９には、
・バージョンファイルの作成日時、
・バージョン作成の契機となった操作を実行したユーザ名、
・世代管理用のバージョン数が、
ファイル名に付加されて保存される。例えばファイル名として、"0007_200502281224_yamakawa.doc"等である。このうち"0007"はバージョン数、"200502281224"は作成日時、"yamakawa"は更新ユーザ名である。

以上のように、バージョンファイルデータ格納領域４０１において、通常ファイルデータ格納領域４００と同等のディレクトリパス上にバージョンファイルの格納領域を配置し、クライアント１００へ公開することで、クライアント１００を利用するユーザは、通常ファイルデータ格納領域４００に格納されているファイルのパス名を頼りに、バージョンファイルデータ格納領域４０１から、前記ファイルの過去の世代のデータに容易にアクセスすることが可能となる。

なお、図３に示したようなバージョンファイルの格納手法は、図１に示すように、バージョン管理装置３００がスイッチ装置として実装され、サーバ２００に、ＮＦＳプロトコルやＣＩＦＳプロトコルを持つ既存のファイルサーバを配置した場合での一例であり、サーバ２００に既にバージョン管理用のデータ格納機能がある場合は、その機能に準じた格納方法を流用しても良い。

＜バージョンファイルの作成条件について＞
次に、バージョン管理装置３００における、バージョンファイルを作成するための条件について説明する。バージョン管理装置３００は、バージョンファイル作成のための契機を判定するために、クライアント１００とサーバ２００の間でやり取りされるファイルアクセスプロトコルのパケットを受け取り、そのパケットを各々に転送する際に、予め管理者により登録されたクライアント上で稼動するアプリケーションのファイル更新処理パターンと一致するようなアクセスパターンが発生したか否かを監視する。

アプリケーションのファイル更新処理パターンとは、単純にプロトコル上に定義されたすべての更新処理を抽出するのではなく、ユーザにとってバージョンファイルを残す意味のあるファイルへの更新処理を抽出することを目的とする。

したがって、ユーザがデータを更新して、意識的に更新データをストレージ上に保存した際に発生する特徴的なアクセスパターンを、バージョンファイル作成のための条件とする必要がある。

以下、ユーザが特定のアプリケーションを利用して更新したデータを保存する際に発生する場合における更新処理パターン例を示す。

例１） 文書作成アプリケーションにおけるデータ保存動作
文書作成アプリケーションには、ユーザによって未保存の更新データや編集先のファイル本体のデータの損失を防ぐために、
・保存処理されていない編集中のファイルのデータを一時的に保存しておくための一時ファイル（１）、および、
・データ更新前のデータを一時的に保存しておくための一時ファイル（２）
を作成する機能を具備したものが利用されている。

このようなアプリケーションでは、アプリケーションごとに特徴をもったファイル名の一時ファイルが作成され、ユーザがデータの保存操作を実行すると、ＲＥＮＡＭＥ処理などにより、一時ファイル（１）のデータが編集先のファイルのデータとして置き換えられ、更新データが編集先のファイルに反映される。

したがって、ユーザが、前記のような文書作成アプリケーション利用環境では、バージョン管理装置３００にて、
・「一時ファイル（１）」もしくは「一時ファイル（２）」のファイルの生成処理と、
・「一時ファイル（１）」から「編集先ファイル」への更新データの反映処理と、
を抽出することができれば、ユーザのデータの保存動作に連動したバージョンファイル作成の契機とすることができる。

バージョンファイル作成の際は、前記更新データ反映処理後、データ更新前のデータが格納されている一時ファイル（２）を、アプリケーションによる削除要求が実行される前に旧バージョンのバージョンファイルとして、ファイルバージョンデータ格納領域に格納すればよい。

これにより、前記文書作成アプリケーションで作成される全てのファイルをバージョン作成対象とすることができる。

図４に、文書作成アプリケーションの具体例として、Microsoft社製品 Office Word（登録商標）を使って更新データを保存する場合の処理パターンを示す。

Microsoft Office Wordでは、ユーザによる更新データの保存動作実行時に、
・更新データを全て反映させた最新の状態のデータを持つ一時ファイル（１）、および
・更新前のデータを含まない更新データ保存前の状態のデータを持つ一時ファイル（２）
を作成する。

前記一時ファイルのファイル名は、いずれも"〜WRL****.tmp"（"****"は任意の数字）と、特徴的なファイル名を持つ。

まず、ユーザが編集先のファイルを開き、アプリケーションを使ってデータを編集した（Ｓｔｅｐ１）後、ユーザが更新データの保存操作を実行すると、編集先ファイルと同一ディレクトリ内に、一時ファイル（１）（"〜WRL****.tmp"）が作成される（Ｓｔｅｐ２）。

さらに、編集先ファイルを同一ディレクトリ上に一時ファイル（２）として、ＲＥＮＡＭＥし（Ｓｔｅｐ３）、一時ファイル（１）を編集先ファイル名で、ＲＥＮＡＭＥする（Ｓｔｅｐ４）。

Ｓｔｅｐ４のＲＥＮＡＭＥの完了後、一時ファイル（２）を削除する（Ｓｔｅｐ５）ことで保存処理が完了する。

以上の一連のアプリケーションによる更新データの保存処理パターンから、以下の２つの処理が実行されたことを確認することで、バージョンファイル作成のための契機と、バージョンファイル作成元となるファイルとを特定することができる。

１）「編集先ファイル名」から「一時ファイル（２）名」へのＲＥＮＡＭＥ処理。
２）「一時ファイル（１）名」から「編集先ファイル名」へのＲＥＮＡＭＥ処理。

上記２つのＲＥＮＡＭＥ処理は、ＲＥＮＡＭＥ元、ＲＥＮＡＭＥ先のファイル名に特徴的なパターンや拡張子が含まれており、前記アプリケーションによって実行されたことを容易に判断することができる。

以上のことから、バージョンファイル作成の契機として、上記２つのＲＥＮＡＭＥ処理が実行されたことを契機とし、バージョンファイル作成元として一時ファイル（２）を設定することが可能となる。

また、一時ファイル（２）は、Ｓｔｅｐ４の終了後、削除されてしまうため、バージョン管理装置３００は、Ｓｔｅｐ４の動作が完了したことを示す応答パケットを取得し、クライアント１００へ前記パケットを転送する前に、一時ファイル（２）のデータをコピーしてバージョンファイルの作成処理を完了させる。

例２） ファイルの上書き保存動作
コピー先に存在するファイルと同名のファイルを、ファイルマネージャなどにより、上書きする操作も同様に、ユーザによる更新データの保存処理と捉えることができる。

前記操作がユーザにより行われた場合、まず、クライアントからのファイルのＣＲＥＡＴＥ要求が送信され、その要求の応答において、ファイル名重複のエラーがサーバより返答される。

該エラーにより、ファイルマネージャなどのアプリケーションを介して、上書きの実行可否をユーザが選択し、ユーザが上書きを許可した場合、
・ＣＩＦＳプロトコルでは、データ更新用のＯＰＥＮ要求の後、ＷＲＩＴＥ要求がクライアントから送信され、
・ＮＦＳプロトコルでは、ＷＲＩＴＥ要求がクライアントから送信され、
コピー元のファイルのデータが更新データとして、コピー先のファイルへ保存される。

従って、バージョン管理装置３００にて、ＣＲＥＡＴＥ要求の応答におけるファイル名重複エラーと、その後のＯＰＥＮ要求、もしくは、ＷＲＩＴＥ要求をあわせて抽出することができれば、ファイルの上書き保存操作に連動したバージョンファイル作成の契機とすることができる。

バージョンファイル作成の際は、
・ＣＩＦＳプロトコルであれば、ＯＰＥＮ要求が成功した後、ＷＲＩＴＥ要求が実行される前に、
・ＮＦＳプロトコルであれば、ＷＲＩＴＥ要求が送信された際に、
前記コピー元のファイルを旧バージョンのバージョンファイルとして、ファイルバージョンデータ格納領域に格納すればよい。

バージョン管理装置３００では、以上の２つの例のように、
・アプリケーションのデータ保存時に発生するアクセスパターンと、
・バージョンファイルの作成手順と、
を設定情報管理部３０４の記憶部３０５（図２参照）に予め登録しておき、前記パターンと手順を基に、
・バージョンファイルの作成契機の判断と、
・バージョンファイル作成動作の制御、
を実行する。

＜バージョンファイル管理装置への事前設定情報について＞
次に、バージョン管理装置３００を稼動させてサービスを開始する前にバージョン管理装置３００内に設定すべき項目について列挙する。

バージョン管理装置３００では、サービスを行うにあたって必要となる設定情報は、設定情報管理部３００に格納される。

設定情報管理部３０４に格納される前記設定情報は、
・バージョン管理対象のサーバ２００のＩＰアドレス、もしくはコンピュータ名と、
・クライアントに公開されているディレクトリの共有名と、
・クライアント上で稼動するアプリケーションの保存動作に連動してバージョンファイルを作成するための各種条件と、
が含まれる。

前記条件に関しては、前述の例のように、
・対応させるアプリケーションの動作に従ったアクセス要求、および応答結果、
・その操作要求に該当するファイル名のキーワード、
・対応するプロトコル、
・バージョンファイルを作成する際に必要となる、バージョンファイルの格納先、および、バージョンファイルのデータのコピー元の取得方法など、
それぞれの環境に合った条件が設定される。

さらに、図１のような構成においては、バージョン管理装置３００は、バージョン管理装置３００からサーバ２００に対して、スーパーユーザ権限で、データのコピーやバージョンファイルの作成を実行するため、設定情報管理部３０４へサーバ２００のスーパーユーザのアカウント情報を登録しておく。

以上、設定情報管理部３０４に全ての設定登録作業を行った後、バージョン管理装置３００によるサービスを開始する。

＜ＣＩＦＳプロトコル環境におけるバージョンファイルの作成手順＞
次に、ＣＩＦＳプロトコル利用環境において、図１、図２の構成、および図３のバージョンファイルの格納方法を採用した場合における各種手順について説明する。

＜ファイルアクセスパケットの転送手順＞
まず、バージョン管理装置３００によるファイルアクセスパケットの転送手順について説明する。

バージョン管理装置３００によるサービスの開始後、クライアント１００は、バージョン管理装置３００を経由してサーバ２００にアクセスすることとなる。

バージョン管理装置３００は、サーバ２００に相当するコンピュータ名をクライアントへ提供することで、クライアント１００から本来はサーバ２００向けとなるファイルアクセスパケットを取得することが可能となる。

クライアント１００から送信されたＣＩＦＳプロトコルのパケットがバージョン管理装置３００に到着すると、ファイルアクセス検証部３０１へパケットが転送される。

ファイルアクセス検証部３０１は、転送されたパケット内から、要求された処理情報を抽出して、設定情報管理部３０４に登録されているバージョンファイル作成のための契機となる処理パターンに、処理情報が一致しているか否かを検証する。

検証の後、バージョン管理装置３００は、後述の処理パターン一致の有無に従った処理を実施した後、要求パケットをサーバ２００へ転送し、応答パケットを待つ。

サーバ２００からの応答パケットがバージョン管理装置３００に到着すると、応答パケットは、ファイルアクセス検証部３０１へ転送される。

ファイルアクセス検証部３０１は、応答パケット内の応答結果を抽出し、バージョンファイル作成のための契機となるパターンの要求処理に対する応答であるかを確認した後、後述のパターン一致の有無に従った処理を実施した後、クライアント１００へ応答パケットを転送する。

＜ユーザ名の管理＞
ＣＩＦＳプロトコルでは、ユーザのログイン、ログオフの実行を伴うセッションを確立し、そのセッションのみ有効なユーザＩＤを用いて、ユーザの識別を実行している。

バージョン管理装置３００は、どのユーザの操作を契機として作成されたバージョンファイルであるかを、バージョンファイルのファイル名の一部として登録する必要があるため、ユーザＩＤとユーザ名の関連付けができなければならない。

バージョン管理装置３００は、この関連付けを実施するにあたって、ログイン、ログオフ操作と連動してユーザ名とユーザＩＤの関連付け処理を行う。

クライアント１００からバージョン管理装置３００に送られ、ファイルアクセス検証部３０１へ転送された要求パケットのうち、抽出された要求処理情報内の処理要求が、ユーザのログイン処理であった場合は、要求処理情報内に含まれるログインユーザ名を抽出し、要求処理を識別するためのＩＤとログインユーザ名を関連付けて、ユーザ管理部３０２へ登録した後、前記要求パケットをサーバ２００へ転送する。

さらに、サーバ２００からバージョン管理装置３００に送られ、ファイルアクセス検証部３０１へ転送された応答パケットのうち、ログイン要求処理のＩＤと一致する応答情報に含まれる応答結果が、ログイン成功を表していた場合、ファイルアクセス検証部３０１は、応答結果内に含まれる、本ログイン中のみ有効となるユーザＩＤを抽出し、ユーザ管理部３０２に登録されているログインユーザ名と関連付けて、ユーザ管理部３０２へ保存した後、応答パケットを、クライアント１００へ転送する。

応答結果がログイン失敗を表していた場合は、要求パケット取得時にユーザ管理部３０２に登録した、ログインユーザ名や要求処理のＩＤを削除した後、応答パケットをクライアント１００へ転送する。

同様にして、要求処理情報内の処理要求が、ユーザのログオフ処理であった場合には、要求情報内に含まれるユーザＩＤを抽出し、要求処理を識別するためのＩＤと共にユーザ管理部３０２へユーザＩＤを登録した後、サーバ２００へ要求パケットを転送する。

サーバ２００からバージョン管理装置３００に送られ、ファイルアクセス検証部３０１へ転送された応答パケットのうち、ログオフ要求処理のＩＤと一致する応答情報に含まれる応答結果が、「ログオフ成功」を表していた場合、ファイルアクセス検証部３０１は、先ほど登録したユーザＩＤと一致するログインユーザ名とユーザＩＤを、ユーザ管理部３０２から削除した後、クライアント１００へ応答パケットを転送する。

応答結果が、「ログオフ失敗」を表していた場合には、要求パケット取得時にユーザ管理部３０２に登録した、ユーザＩＤや要求処理のＩＤを削除した後、応答パケットをクライアント１００へ転送する。

以上の手順に従い、クライアント１００とサーバ２００間で中継するパケットのうち、ログイン、ログオフ処理に伴う、ユーザ名、ユーザＩＤの関連付けを行うことで、バージョン管理装置３００では、ユーザＩＤから容易にユーザ名を抽出することが可能となる。

＜バージョンファイル作成手順＞
図５は、バージョン管理装置３００のファイルアクセス検証部３０１においてバージョンファイル作成の契機となる処理パターンと一致した際のバージョン管理装置３００によるバージョンファイルの作成手順を示す流れ図である。図１及び図５を参照して、本発明の一実施例におけるバージョンファイルの作成手順を説明する。

バージョン管理装置３００は、クライアント１００からバージョン管理装置３００に送られた処理要求パケットを取得する（ステップＳ１００）。

処理要求パケットは、ファイルアクセス検証部３０１へ転送され、要求処理情報が抽出され解析される。処理要求パケットの内容が予め定められたパターン（設定情報管理部３０４に登録されているバージョンファイル作成の契機となる処理パターン）に一致しているか否かのチェックが行われる（ステップＳ１０１）。

抽出された要求処理情報内の処理要求が、設定情報管理部３０４に登録されているバージョンファイル作成の契機となる処理パターンと一致した場合（ステップＳ１０１のＹＥＳ分岐）、処理要求内容の情報をファイルアクセス検証部３０１の記憶部に保存する。より詳細には、操作ファイルのパス名、操作要求のＩＤ、ユーザＩＤ、コマンド名を抽出して、ファイルアクセス検証部３０１内の記憶部に処理要求エントリとして保存する（ステップＳ１０２）。その後、処理要求パケットをサーバ２００へ転送する。

バージョン管理装置３００のファイルアクセス検証部３０１は、サーバ２００からの応答パケットのうち、要求の応答に該当するサーバ２００からの応答パケットを、操作要求のＩＤを手がかりにして抽出し、サーバ２００からの応答結果が、バージョンファイル作成の契機となる処理パターンと一致しているかチェックする（ステップＳ１０３）。バージョンファイル作成の契機となる処理パターンと一致していることが確認された場合（ステップＳ１０３のＹＥＳ分岐）、処理要求が成功したことをファイルアクセス検証部３０１内の記憶部に登録する（ステップＳ１０４）。そして、前記要求エントリに、応答結果が処理パターンを満たしたことを示すフラグを付けた後、応答パケットを、クライアント１００へ転送する。

一方、応答結果が、バージョンファイル作成の契機となる処理パターンと一致していないことが確認された場合には（ステップＳ１０３のＮＯ分岐）、前記要求エントリに含まれる要求時に登録したデータを削除し（ステップＳ１０７）、応答パケットをクライアント１００へ転送する。

バージョンファイル作成の契機となる全ての処理が完了していない場合（ステップＳ１０５のＮＯ分岐）、ステップＳ１００に戻り、処理要求パケットの取得待ちとなる。

バージョンファイル作成の契機となる全ての処理が完了した場合（バージョンファイル作成の契機となる条件が満たされた場合）（ステップＳ１０５のＹＥＳ分岐）、バージョンファイル作成ルール、ファイルアクセス検証部３０１で保存していた要求内容に基づき、バージョン制御部３０３は、バージョンファイルを作成する（ステップＳ１０６）。

このように、前記要求エントリに、既に実行された操作要求を、一時的に登録しておき、関連する操作要求を同一の要求エントリに追加して、バージョンファイル作成のための契機となる処理パターンと、操作要求、および応答結果がすべて一致した場合に、ファイルアクセス検証部３０１は、要求エントリに保存されているユーザＩＤと一致するユーザ名をユーザ管理部３０２から検索して、ユーザ名を取得すると共に、設定情報管理部３０４に登録されている設定情報を基に、該要求エントリから、バージョンファイル作成のコピー元となるファイルのパス名を取得する。

ファイルアクセス検証部３０１は、パス名から、バージョンファイル作成のコピー先のパス名をバージョンファイルデータ格納領域４０１でのバージョンファイルの格納方法に従って生成し、ユーザ名、コピー元となるファイルのパス名と共に、バージョン制御部３０３へ転送する。

バージョン制御部３０３は、ファイルアクセス検証部３０１から取得したコピー元となるファイルパス名を基に、サーバ２００から、該パス名に格納されている通常ファイルデータ格納領域４００上のファイルのデータおよび属性情報を取得する。同様に、ファイルアクセス検証部３０１から取得したコピー先となるパス名を基に、バージョンファイルデータ格納領域４０１へ新たなバージョンファイルを作成して、前記データ、および属性をコピーする。

バージョンファイルを作成する際、既存のバージョンファイルが作成されていず、コピー先までのディレクトリが存在していない場合には、バージョン制御部３０３は、前記ディレクトリのデータを生成した後に、バージョンファイルを作成する。

また、ステップＳ１０６のバージョンファイル作成の際に、バージョン制御部３０３は、バージョンファイル作成前の最新のバージョンファイルのバージョン数を、バージョンファイル格納先のディレクトリ上に存在するバージョンファイルのファイル名から取得し、ファイルアクセス検証部３０１から取得したユーザ名と、バージョンファイルを作成した日時、および、取得したバージョン数に「１」を加えたバージョン数を並べてファイル名として付与する。

バージョンファイルの作成が完了した後、バージョン制御部３０３から、ファイルアクセス検証部３０１へ、バージョンファイル作成完了通知を行い、ファイルアクセス検証部３０１は、前記バージョンファイルに関連する要求エントリを削除する（ステップＳ１０８）。

＜要求処理がバージョンファイル作成の契機となる処理パターン、もしくはログイン、ログオフ処理と一致しない場合＞
なお、バージョン管理装置３００のファイルアクセス検証部３０１において、要求処理がバージョンファイル作成の契機となる処理パターン、もしくはログイン、ログオフ処理のどの処理とも一致しない場合には、バージョン管理装置３００は、要求パケットをそのままサーバ２００へ転送する。

同様にして、応答パケットについても、バージョンファイル作成の契機となる処理パターンに一致しないものについては、バージョン管理装置３００は、応答パケットをそのままクライアント１００へ転送する。

＜ＮＦＳプロトコル環境におけるバージョンファイルの作成手順＞
ＮＦＳプロトコル利用環境におけるバージョンファイルの作成手順は、ＣＩＦＳプロトコルと同様に、実施することができるが、ユーザ管理部３０２におけるユーザ名の管理方法と、バージョン制御部３０３におけるファイルの作成手順が異なる。

ＮＦＳプロトコルでは、ログイン、ログオフに伴うセッション管理手段が備えられていないため、特定のユーザからの操作要求は、全て同一のユーザＩＤが付与される。従って、ＮＩＳ（Network Information Service）サーバや、サーバ２００内に格納されているユーザ名とユーザＩＤの対応テーブルを、予めバージョン管理装置３００のユーザ管理部３０２へ登録しておく必要がある。

また、ＮＦＳプロトコルでは、ファイル操作は、パス名ではなく、「ファイルハンドル」と呼ばれるＮＦＳ固有の識別子を用いて行われるため、バージョンファイルのコピー元、もしくはコピー先のパス名をパケットから一意に取得できない。従って、バージョンファイル作成の際には、バージョンファイルに関連する親ディレクトリから公開ディレクトリまでのパス名を、バージョンファイル作成の操作対象となっているファイルのファイルハンドルから導く操作が必要となる。この操作は、ファイルハンドル＋ファイル名「..」により、親ディレクトリのファイルハンドルを取得し、親ディレクトリのファイルハンドルを使って、ディレクトリエントリを取得して、取得したファイルハンドルを持つディレクトリ名を探索する操作を公開ディレクトリに達するまで実行することである。

以上本発明を上記実施例に即して説明したが、本発明は上記実施例の構成にのみ限定されるものでなく、本発明の範囲内で当業者であればなし得るであろう各種変形、修正を含むことは勿論である。

本発明の一実施例のバージョン管理システムの構成例を示す図である。 本発明の一実施例のバージョン管理装置の構成を示す図である。 本発明の一実施例におけるバージョンファイルの格納例を示す図である。 本発明の一実施例における文書作成アプリケーションにおける更新データ保存時の動作手順を示す図である。 本発明の一実施例におけるバージョンファイルの作成手順を示す流れ図である。

符号の説明

１ ローカルネットワーク
１００ クライアント
２００ サーバ
２０１ ファイルシステム
２０２ 記憶装置
３００ バージョン管理装置
３０１ ファイルアクセス検証部
３０２ ユーザ管理部
３０３ バージョン制御部
３０４ 設定情報管理部
３０５ 記憶部
４００ 通常ファイルデータ格納領域
４０１ バージョンファイルデータ格納領域
４０２ ディレクトリＡ
４０３ ディレクトリＢ
４０４ ディレクトリＣ
４０５ ファイルＤ
４０６ ディレクトリＡ’
４０７ ディレクトリＣ
４０８ ディレクトリＤ’
４０９ バージョンファイル群

Claims (29)

1. ファイルのアクセスに関するコマンド・コンテキストを解析し、前記コマンド・コンテキストが前記ファイルのバージョン管理用情報の作成の契機となる所定のパターンに対応したものであるか判定する手段と、
   前記コマンド・コンテキストがバージョン管理用情報の作成の契機となる所定のパターンに対応したものである場合、前記ファイルのバージョン管理用情報を作成する手段と、
   を備えたことを特徴とするバージョン管理装置。
2. ファイルアクセスのうちデータ保存アクセス動作のパターンを予め登録しておく記憶手段と、
   ファイルに対して為されたファイルアクセス要求を解析して前記パターンと照合し、前記パターンに照合したファイルアクセスを抽出することで、バージョン管理用ファイルを作成する制御を行う制御手段と、
   を備えたことを特徴とするバージョン管理装置。
3. 前記記憶手段には、データ保存時に発生するアクセスのパターンと、バージョン管理用ファイルの作成の手順とが予め登録されており、
   前記制御手段は、ファイルに対して為されたファイルアクセス要求を解析し、前記パターンと前記手順を基に、前記バージョン管理用ファイルの作成の契機を判断し前記バージョン管理用ファイルの作成動作を制御する、ことを特徴とする請求項２記載のバージョン管理装置。
4. 請求項１乃至３のいずれか一に記載のバージョン管理装置において、
   クライアントより送信されたサーバ向けのファイルアクセス要求を中継して前記サーバへ転送すると共に、前記要求に対して前記サーバにより送信された前記クライアントへの応答を前記クライアントへ転送するスイッチ装置として機能し、
   前記バージョン管理装置は、クライアントとサーバ間でやり取りされる要求及び応答を監視し、前記ファイルアクセス要求が前記パターンと一致するか照合する、ことを特徴とするバージョン管理装置。
5. 前記クライアント上で稼動するアプリケーションのファイル更新処理パターンを、バージョン管理用ファイル作成のための契機として記憶する記憶手段と、
   前記クライアントと前記サーバの間でやり取りされるファイルアクセスプロトコルのパケットを受け取り、
   前記パケットをあて先のサーバまたはクライアントに転送する際に、バージョン管理用ファイル作成のための契機として予め登録されているファイル更新処理パターンと一致するアクセスパターンが発生したか否かを監視し、
   前記ファイル更新処理パターンと一致するアクセスパターンの発生を検出した場合、バージョン管理情報を作成する手段と、
   を備えたことを特徴とする請求項４記載のバージョン管理装置。
6. クライアントより送信されたサーバ向けのファイルアクセス要求を受け、前記クライアントへの応答を返すサーバ装置において、
   請求項１乃至３のいずれか一に記載のバージョン管理装置を備えたことを特徴とするサーバ装置。
7. クライアントより予め定められた所定のファイルアクセスプロトコルを用いて送信されたサーバ向けの要求を中継して前記サーバへ転送すると共に、前記要求に対して前記サーバにより送信された前記クライアントへの応答を中継して前記クライアントへ転送するバージョン管理装置であって、
   前記クライアントから送られる要求パケットと、前記サーバから送られる応答パケットを取得し、取得した要求パケットと、応答パケットにそれぞれ含まれている処理要求と応答結果を抽出し、前記クライアントで稼動するアプリケーションによるファイルのデータ更新処理動作に相当するアクセスパターンに合致しているかを照合するファイルアクセス検証部と、
   前記クライアントから送られる要求パケットに含まれる処理要求がどのユーザにより要求されたものなのかを検証するために、前記所定のファイルアクセスプロトコルに対応した形式で、ユーザ情報を記憶管理するユーザ管理部と、
   前記ファイルアクセス検証部において、前記クライアントで稼動するアプリケーションによるファイルのデータ更新処理に相当するパターンに相当する操作が実行されたことを契機として、バージョン管理用ファイルの作成操作を制御するバージョン制御部と、
   前記ファイルアクセス検証部、前記ユーザ管理部、前記バージョン制御部が動作するに当たって参照される動作設定情報を格納しておく設定情報管理部と、
   を備えている、ことを特徴とするバージョン管理装置。
8. 前記設定情報管理部には、前記クライアントで実行するアプリケーションによる前記サーバにおけるデータ保存時に発生するアクセスパターンと、バージョンファイルの作成手順とが予め登録されており、
   前記パターンと前記手順を基に、バージョン管理用ファイルの作成契機の判断と、バージョン管理用ファイルの作成動作の制御が行われる、ことを特徴とする請求項７記載のバージョン管理装置。
9. 前記バージョン制御部は、前記サーバの通常ファイルデータ格納領域の他に、バージョン管理用ファイルを格納するバージョンファイルデータ格納領域を、所定のファイルシステムに作成し、
   前記バージョンファイルデータ格納領域において、前記通常ファイルデータ格納領域と同等のディレクトリパス上に、バージョン管理用ファイルの格納領域を配置し、
   前記クライアントからは、前記通常ファイルデータ格納領域に格納されているファイルのパス名に基づき、前記バージョン管理用ファイルデータ格納領域から、前記ファイルの過去の世代のデータにアクセス自在とされている、ことを特徴とする請求項８記載のバージョン管理装置。
10. 前記バージョン制御部は、前記サーバの通常ファイルデータ格納領域の他に、バージョン管理用のファイルを格納するバージョン管理用ファイルデータ格納領域を所定のファイルシステムに作成し、
    前記バージョン管理用ファイルデータ格納領域には、ファイルの更新履歴データ管理用のバージョン管理用ファイルが、バージョン管理用ファイルの作成日時、バージョン作成の契機となった操作を実行したユーザ名、世代管理用のバージョン数が、ファイル名に付加されて保存される、ことを特徴とする請求項８記載のバージョン管理装置。
11. 前記サーバにおいて、あるディレクトリが共有ディレクトリとして、前記クライアントに対して公開されている場合に、前記ディレクトリに相当するディレクトリを、前記バージョン管理用ファイルデータ格納領域へ作成し、
    前記バージョン管理用ファイルデータ格納領域の前記ディレクトリには、前記通常ファイルデータ格納領域の前記ディレクトリの共有名と競合しない名前が付与され、前記クライアントには、読み出し専用となる共有ディレクトリとしてアクセスできるように公開され、
    前記通常ファイルデータ格納領域の前記ディレクトリの前記共有ディレクトリ配下のオブジェクトについては、新たにバージョン管理用ファイルが作成される際に、バージョン管理用ファイル格納先までのパス上のオブジェクトが、前記バージョン管理用ファイルデータ格納領域に作成され、
    前記バージョン管理用ファイル格納先までのパス上のオブジェクトがディレクトリであった場合、前記通常ファイルデータ格納領域のディレクトリと同名のディレクトリが作成され、配下のオブジェクトがファイルであった場合には、前記通常ファイルデータ格納領域のファイルのファイル名に、バージョン管理装置固有の情報を付加したディレクトリ名のディレクトリが作成され、
    前記ディレクトリには、前記ファイルの更新履歴データ管理用のバージョン管理用ファイルが、バージョン管理用ファイルの作成日時、バージョン作成の契機となった操作を実行したユーザ名、世代管理用のバージョン数が、ファイル名に付加されて保存される、ことを特徴とする請求項１０記載のバージョン管理装置。
12. 前記クライアントが文書作成アプリケーションを実行し、
    前記バージョン管理装置において、前記文書作成アプリケーションは、ユーザによって未保存の更新データや編集先のファイル本体のデータの損失を防ぐために、保存処理されていない編集中のファイルのデータを一時的に保存しておくための第１の一時ファイル、および、データ更新前のデータを一時的に保存しておくための第２の一時ファイルを作成する機能を具備し、
    前記第１の一時ファイル又は前記第２の一時ファイルのファイルの生成処理と、
    前記第１の一時ファイルから編集先ファイルへの更新データの反映処理を抽出し、ユーザのデータの保存動作に連動したバージョン管理用ファイル作成の契機とし、
    バージョン管理用ファイルの作成の際に、前記更新データの反映処理の後、データ更新前のデータが格納されている第２の一時ファイルを、アプリケーションによる削除要求が実行される前に、旧バージョンのバージョン管理用ファイルとして、前記ファイルバージョンデータ格納領域に格納し、
    前記文書作成アプリケーションで作成される全てのファイルを、バージョン管理用作成対象とする、ことを特徴とする請求項８記載のバージョン管理装置。
13. ファイル作成要求の応答におけるファイル名重複エラーと、その後のオープン要求、もしくは、ライト要求をあわせて抽出した場合、ファイルの上書き保存操作に連動したバージョン管理用ファイル作成の契機とする、ことを特徴とする請求項８記載のバージョン管理装置。
14. バージョン管理用ファイル作成の際に、
    前記１のファイルアクセスプロトコルでは、オープン要求が成功した後、ライト要求が実行される前に、又は、
    別のファイルアクセスプロトコルでは、ライト要求が送信された際に、
    前記コピー元のファイルを旧バージョンのバージョン管理用ファイルとして、ファイルバージョンデータ格納領域に格納する、ことを特徴とする請求項８記載のバージョン管理装置。
15. 前記設定情報管理部には、
    バージョン管理対象のサーバのアドレス、もしくはコンピュータ名と、
    クライアントに公開されているディレクトリの共有名と、
    クライアント上で稼動するアプリケーションの保存動作に連動してバージョン管理用ファイルを作成するための条件が含まれることを特徴とする請求項８記載のバージョン管理装置。
16. 前記条件として、対応させるアプリケーションの動作に従ったアクセス要求、および応答結果、その操作要求に該当するファイル名のキーワード、対応するプロトコル、バージョン管理用ファイルを作成する際に必要となる、バージョン管理用ファイルの格納先、および、バージョン管理用ファイルのデータのコピー元の取得の少なくとも１つが含まれる、ことを特徴とする請求項１５記載のバージョン管理装置。
17. クライアントとサーバ間で中継するパケットのうち、ログイン、ログオフ処理に伴う、ユーザ名、ユーザＩＤを関連付けを行うことで、ユーザＩＤからにユーザ名を抽出する、ことを特徴とする請求項８記載のバージョン管理装置。
18. 前記クライアントから前記バージョン管理装置に送られ、前記ファイルアクセス検証部へ転送された要求パケットのうち、抽出された要求処理情報内の処理要求が、前記設定情報管理部に登録されているバージョン管理用ファイル作成の契機となる処理パターンと一致した場合、操作ファイルのパス名、操作要求のＩＤ、ユーザＩＤ、コマンド名を抽出して、前記ファイルアクセス検証部内に、処理要求エントリとして、それぞれの情報を関連付けて保存した後、要求パケットを前記サーバへ転送し、
    前記要求の応答に該当するサーバからの応答パケットを、要求のＩＤを基に抽出し、応答結果が、バージョン管理用ファイル作成の契機となる処理パターンと一致していることが確認された場合には、前記要求エントリに、応答結果が処理パターンを満たしたことを示すフラグを付けた後、応答パケットを、前記クライアントへ転送し、
    応答結果が、バージョン管理用ファイル作成の契機となる処理パターンと一致していないことが確認された場合は、前記要求エントリに含まれる要求時に登録したデータを削除した後、応答パケットをクライアントへ転送する、ことを特徴とする請求項８記載のバージョン管理装置。
19. 前記要求エントリに、既に実行された操作要求を一時的に登録しておき、関連する操作要求を同一の要求エントリへ追加し、バージョン管理用ファイル作成のための契機となる処理パターンと、操作要求、および応答結果が一致した場合に、前記ファイルアクセス検証部は、要求エントリに保存されているユーザＩＤと一致するユーザ名を、前記ユーザ管理部から検索して、ユーザ名を取得すると共に、前記設定情報管理部に登録されている設定情報を基に、前記要求エントリから、バージョン管理用ファイル作成のコピー元となるファイルのパス名を取得する、ことを特徴とする請求項１８記載のバージョン管理装置。
20. 前記ファイルアクセス検証部は、パス名から、バージョン管理用ファイル作成のコピー先のパス名を、前記バージョン管理用ファイル格納領域でのバージョン管理用ファイルの格納手順に従って生成し、ユーザ名、コピー元となるファイルのパス名と共に、前記バージョン制御部へ転送し、
    前記バージョン制御部は、前記ファイルアクセス検証部から取得したコピー元となるファイルパス名を基に、サーバから、該パス名に格納されている通常ファイルデータ格納領域上のファイルのデータおよび属性情報を取得し、前記ファイルアクセス検証部から取得したコピー先となるパス名を基に、バージョン管理用ファイルデータ格納領域へ新たなバージョン管理用ファイルを作成して、前記データ、および属性をコピーする、ことを特徴とする請求項８記載のバージョン管理装置。
21. バージョン管理用ファイルを作成する際、既存のバージョン管理用ファイルが作成されていず、コピー先までのディレクトリが存在していない場合には、前記バージョン制御部は、前記ディレクトリのデータを生成した後にバージョン管理用ファイルを作成する、ことを特徴とする請求項８記載のバージョン管理装置。
22. 前記バージョン制御部は、バージョン管理用ファイル作成の際に、バージョン管理用ファイル作成前の最新のバージョン管理用ファイルのバージョン数を、バージョン管理用ファイル格納先のディレクトリ上に存在するバージョン管理用ファイルのファイル名から取得し、前記ファイルアクセス検証部から取得したユーザ名と、バージョン管理用ファイルを作成した日時、および取得したバージョン数に１を加えたバージョン数を並べてファイル名として付与する、ことを特徴とする請求項８記載のバージョン管理装置。
23. バージョン管理用ファイルの作成完了後は、前記バージョン制御部から、前記ファイルアクセス検証部へ、バージョン管理用ファイル作成完了通知を行い、
    前記ファイルアクセス検証部は、前記バージョン管理用ファイルに関連する要求エントリを削除する、ことを特徴とする請求項２２記載のバージョン管理装置。
24. 前記ファイルアクセス検証部において、要求処理がバージョン管理用ファイル作成の契機となる処理パターンもしくはログイン、ログオフ処理のどの処理とも一致しない場合には、クライアントからの要求パケットをそのままサーバへ転送し、
    応答パケットについても、バージョン管理用ファイル作成の契機となる処理パターンに一致しないものについては、サーバからの応答パケットをそのままクライアントへ転送する、ことを特徴とする請求項８記載のバージョン管理装置。
25. ログイン、ログオフに伴うセッション管理手段を具備しないシステムに対応するため、ＮＩＳ（Ｎｅｔｗｏｒｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅ）サーバや前記サーバ内に格納されている、ユーザ名とユーザＩＤの対応テーブルが前記バージョン管理装置の前記ユーザ管理部に登録されている、ことを特徴とする請求項７記載のバージョン管理装置。
26. ファイル操作が、パス名ではなく、ファイルハンドルを用いて行われ、
    バージョン管理用ファイル作成の際に、バージョン管理用ファイルに関連する親ディレクトリから公開ディレクトリまでのパス名を、バージョン管理用ファイル作成の操作対象となっているファイルのファイルハンドルから導く操作が行われ、
    前記操作は、ファイルハンドル、ファイル名により、親ディレクトリのファイルハンドルを取得し、親ディレクトリのファイルハンドルを使って、ディレクトリエントリを取得し、取得したファイルハンドルを持つディレクトリ名を探索する操作を公開ディレクトリに達するまで実行する、ことを特徴とする請求項１５記載のバージョン管理装置。
27. ファイルへのアクセスのコマンド・コンテキストを解析し、前記コマンド・コンテキストが前記ファイルのバージョン管理用ファイル作成の契機となる所定のパターンに対応したものであるか判定する工程と、
    前記コマンド・コンテキストがバージョン管理用ファイルの作成の契機となる所定のパターンに対応したものである場合、前記ファイルのバージョン管理用ファイルを作成し保存する工程と、
    を含む、ことを特徴とするバージョン管理方法。
28. ファイルのバージョンを自動管理するバージョン管理装置が、ファイルの処理の要求パケットを取得し、前記要求パケットの処理要求内容が予め登録されているパターンと一致しているか判定し、一致している場合、処理要求内容の情報を記憶する第１の工程と、
    前記バージョン管理装置が、前記要求パケットに対する応答パケットを取得し、前記第１の工程で記憶されている処理要求内容とから、前記ファイルのバージョン管理用ファイル作成の契機の条件と一致する処理結果であるか判定し、一致した場合、処理要求が完了した旨を登録する第２の工程と、
    前記バージョン管理装置が、前記第１と第２の工程を、前記バージョン管理用ファイル作成の契機となる全ての処理が完了するまで繰り返し、記憶しておいた要求内容に基づきバージョン管理用ファイルを作成する第３の工程と、
    を含む、ことを特徴とするバージョン管理方法。
29. バージョン管理用ファイルを自動作成するためのプログラムであって、
    ファイルへのアクセスのコマンド・コンテキストを解析し、前記コマンド・コンテキストが前記ファイルのバージョン管理用ファイル作成の契機となる所定のパターンに対応したものであるか判定する処理と、
    前記コマンド・コンテキストがバージョン管理用ファイルの作成の契機となる所定のパターンに対応したものである場合、前記ファイルのバージョン管理用ファイルを作成し保存する処理と、
    をコンピュータに実行させるプログラム。

Images