(57)【要約】      （修正有）【課題】ファイルサーバとＣＭＳを統合することで、これらの課題を解決するシステム、方法とプログラムの提供。【解決手段】ファイルシステム１４へのアクセスを制御するファイルアクセスサーバ処理部１３と、データベース１８にてコンテンツを管理するＣＭＳサーバ処理部１７と、ファイルシステムとＣＭＳを連携させるＦＳ−ＣＭＳ連携処理部１９とを備え、クライアント１からのファイルシステム１４へのアクセスを検出し、操作イベントが発生すると、ＦＳ−ＣＭＳ連携処理部１９は、操作内容をＣＭＳサーバ処理部１７に通知し、データベースに操作内容を反映させ、クライアント１がＣＭＳアプリケーション１５を用いてＣＭＳサーバ処理部１７にアクセスし、ファイルに対する操作を行うと、ＦＳ−ＣＭＳ連携処理部１９を経由してファイルシステム１４にアクセスし、操作内容をＣＭＳサーバ処理部１７に通知してデータベース１８に操作内容を反映させる。【選択図】図２
2008040602.tif 000002
【特許請求の範囲】
【請求項１】
ファイルシステムへのアクセスを制御するファイルアクセスサーバ処理部と、
データベースにてコンテンツを管理するＣＭＳ（Ｃｏｎｔｅｎｔｓ  Ｍａｎａｇｅｍeｎｔ  Ｓｙｓｔｅｍ）サーバ処理部と、
前記ファイルアクセスサーバ処理部による前記ファイルシステムへのファイル操作が行われた場合、前記ファイルシステムへの操作内容を前記ＣＭＳサーバ処理部に通知し、前記操作内容を、前記ＣＭＳサーバ処理部で管理される前記データベースに反映させる制御を行うＦＳ−ＣＭＳ連携処理部と、
を備えている、ことを特徴とするファイルサーバ装置。
【請求項２】
請求項１記載のファイルサーバ装置において、
前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルサーバ装置が接続するクライアントのＣＭＳアプリケーションによるファイル操作を前記ファイルシステムへのファイル操作に変換した上で前記ファイルシステムに対して操作を行い、前記ファイルシステムに対する前記操作の内容を、前記ＣＭＳサーバ処理部に通知し、前記操作の内容を、前記ＣＭＳサーバ処理部で管理される前記データベースに反映させる制御を行う、ことを特徴とするファイルサーバ装置。
【請求項３】
請求項１記載のファイルサーバ装置において、
前記ファイルサーバ装置が接続するクライアントで実行されるＣＭＳアプリケーションのメニューページ上のファイル操作を選択するボタンのリンク先が、ＣＭＳアプリケーション本来の対応するページではなく、予め用意した別のページに設定され、前記ボタンの選択時、前記別のページに制御が移り、前記ＦＳ−ＣＭＳ連携処理部の対応するファイル操作の処理が実行されるように設定されており、
前記ＣＭＳアプリケーションのメニューページ上でファイル操作がなされた場合、前記ＦＳ−ＣＭＳ連携処理部により、前記ファイルシステムへのファイル操作が行われ、
さらに、前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルシステムに対して行った前記操作の内容を、前記ＣＭＳサーバ処理部に通知し、前記操作の内容を、前記ＣＭＳサーバ処理部で管理される前記データベースに反映させる制御を行う、ことを特徴とするファイルサーバ装置。
【請求項４】
前記ＦＳ−ＣＭＳ連携処理部は、前記ＣＭＳサーバ処理部のＡＰＩ（アプリケーションインタフェース）をコールすることで、前記ファイルシステムに為された前記操作の内容を、前記ＣＭＳサーバ処理部で管理される前記データベースに反映させる、ことを特徴とする請求項１乃至３のいずれか一に記載のファイルサーバ装置。
【請求項５】
前記データベースが、１行あたり、ファイル名と、分類コードと、ファイルの属性情報の列を少なくとも含み、
前記分類コードとして、ファイルの親ディレクトリのパス名を含み、
前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルシステムへの操作イベント発生時、前記操作の対象となるパス名とファイル名とを取得し、
ファイルの親ディレクトリを分類コードとして、前記ＣＭＳサーバ処理部のＣＭＳのコンテンツ操作用のＡＰＩをコールする、ことを特徴とする請求項４記載のファイルサーバ装置。
【請求項６】
前記データベースが、１行あたり、ファイル名と、分類コードと、ファイルの属性情報の列を少なくとも含み、
前記ＦＳ−ＣＭＳ連携処理部は、ファイルの親ディレクトリのパス名と分類コードとを対応付ける変換テーブルを含み、
前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルシステムへの操作イベント発生時、パス名とファイル名を取得し、親ディレクトリから前記変換テーブルを参照して分類コードを導き、
前記ＣＭＳサーバ処理部のＣＭＳのコンテンツ操作用のＡＰＩをコールする、ことを特徴とする請求項４記載のファイルサーバ装置。
【請求項７】
クライアントからのファイルシステムへのアクセスを制御するファイルアクセスサーバ処理部と、
データベースにてコンテンツを管理するＣＭＳ（Ｃｏｎｔｅｎｔｓ  Ｍａｎａｇｅｍeｎｔ  Ｓｙｓｔｅｍ）サーバ処理部と、
前記クライアントからの前記ファイルシステムへの操作イベントが発生した時、前記ＣＭＳサーバ処理部に通知して、前記ファイルシステムへの操作内容を、前記データベースに反映させ、
一方、前記ＣＭＳサーバ処理部が行う処理を、前記ファイルシステムに対する操作に変換して前記ファイルシステムに対して操作するＦＳ−ＣＭＳ連携処理部と、
を備えている、ことを特徴とするファイルサーバ装置。
【請求項８】
前記ＦＳ−ＣＭＳ連携処理部は、前記クライアントからの、前記ファイルシステムへのアクセスを、モニタリングアプリケーションインタフェースを通じて認識し、
前記クライアントからのアクセスにより、前記ファイルシステムに変更が加えられると、前記ＦＳ−ＣＭＳ連携処理部は、前記変更内容を、前記ＣＭＳサーバ処理部に通知し、
前記ＦＳ−ＣＭＳ連携処理部から前記通知を受けた前記ＣＭＳサーバ処理部では、前記データベースに前記変更内容を反映させ、
前記クライアントがＣＭＳアプリケーションを用いてファイルに対する操作を行うと、前記ＦＳ−ＣＭＳ連携処理部を経由して、前記ファイルシステムにアクセスし、前記ＣＭＳサーバ処理部では、前記データベースに、前記変更内容を反映させる、ことを特徴とする請求項７記載のファイルサーバ装置。
【請求項９】
前記ＣＭＳサーバ処理部で管理される属性を、前記ファイルシステムにおけるリンクに対応させる手段を備え、
前記クライアントにおいて、前記ファイルアクセスサーバ処理部対応のプロトコルにしか対応していないアプリケーションからも、前記ＣＭＳサーバ処理部をアクセス可能としてなる、ことを特徴とする請求項７記載のファイルサーバ装置。
【請求項１０】
検索ディレクトリ機能を備え、前記ＣＭＳサーバ処理部でのファイル検索を、前記クライアントにおいて前記ファイルアクセスサーバ処理部対応のプロトコルにしか対応していないアプリケーションからも利用可能としている、ことを特徴とする請求項７記載のファイルサーバ装置。
【請求項１１】
前記ＦＳ−ＣＭＳ連携処理部は、前記クライアントからの前記ファイルシステムの検索ディレクトリへのアクセスを、モニタリングアプリケーションインタフェースを通じて認識すると、前記検索ディレクトリ名の示す属性を備えているファイルを、前記ＣＭＳサーバ処理部に問い合わせ、
前記ＣＭＳサーバ処理部は、前記ＦＳ−ＣＭＳ連携処理部からの前記問い合わせを受けて、前記データベースを検索して、前記検索ディレクトリ名の示す属性を備えているファイルのリストを、前記ＦＳ−ＣＭＳ連携処理部に返し、
前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルのリストをもとに、前記ファイルシステムにリンクファイルを作成し、前記検索ディレクトリ名の示す属性をもつファイルが一覧となって見えるようにしてなる、ことを特徴とする請求項７記載のファイルサーバ装置。
【請求項１２】
前記検索ディレクトリからファイルがデリート（ＤＥＬＥＴＥ）された場合に、前記ファイルのデリート（ＤＥＬＥＴＥ）イベントに応じて、前記ファイルの実体をデリートする手段を備えている、ことを特徴とする請求項１０又は１１記載のファイルサーバ装置。
【請求項１３】
前記ＦＳ−ＣＭＳ連携処理部は、デリート（ＤＥＬＥＴＥ）イベントを契機として、ファイルの拡張属性とリンクを再設定する、ことを特徴とする請求項７、１０、１１のいずれか一に記載のファイルサーバ装置。
【請求項１４】
前記ＦＳ−ＣＭＳ連携処理部が、リネーム（ＲＥＮＡＭＥ）元のファイルと、リネーム（ＲＥＮＡＭＥ）先のファイルの情報を備えたリネーム（ＲＥＮＡＭＥ）テーブルと、
デリート（ＤＥＬＥＴＥ）イベントを保存するデリート（ＤＥＬＥＴＥ）テーブルと、
を備えている、ことを特徴とする請求項７、１０、１１のいずれか一に記載のファイルサーバ装置。
【請求項１５】
前記ＦＳ−ＣＭＳ連携処理部は、
前記ファイルシステムのファイルが更新されるときには、更新対象のファイルに関連付けて、リネーム（ＲＥＮＡＭＥ）イベントを保存するリネーム（ＲＥＮＡＭＥ）テーブルと、デリート（ＤＥＬＥＴＥ）イベントを保存するデリート（ＤＥＬＥＴＥ）テーブルと、を作成し、
前記ＤＥＬＥＴＥイベントのファイルが、前記ＲＥＮＡＭＥテーブルのＲＥＮＡＭＥ先ファイルとして存在するか否かをチェックし、
前記ＤＥＬＥＴＥイベントのファイルが前記ＲＥＮＡＭＥテーブルのＲＥＮＡＭＥ先ファイルとして存在した場合、ＲＥＮＡＭＥ元ファイルと同名なファイルが前記ファイルシステム上に存在するか否かをチェックし、
前記ＲＥＮＡＭＥ元ファイルと同名なファイルが前記ファイルシステム上に存在した場合には、アプリケーションの更新動作とみなし、拡張属性とリンクを再設定し、前記ＲＥＮＡＭＥテーブルと前記ＤＥＬＥＴＥテーブルから、前記ファイルに関するエントリを削除する、ことを特徴とする請求項７、１０、１１のいずれか一に記載のファイルサーバ装置。
【請求項１６】
ファイルアクセスアプリケーションと、ＣＭＳ（Ｃｏｎｔｅｎｔｓ  Ｍａｎａｇｅｍeｎｔ  Ｓｙｓｔｅｍ）アプリケーションを含むクライアントと、
前記クライアントと通信接続するファイルサーバ装置と、
を備え、
前記ファイルサーバ装置が、
ファイルシステムと、
前記クライアントからの前記ファイルシステムへのアクセスを制御するファイルアクセスサーバ処理部と、
データベースにてコンテンツを管理するＣＭＳサーバ処理部と、
前記ファイルシステムと前記ＣＭＳサーバ処理部とを連携させる制御を行うＦＳ−ＣＭＳ連携処理部と、
を備え、
前記ＦＳ−ＣＭＳ連携処理部は、
前記クライアントのファイルアクセスアプリケーションからの前記ファイルシステムへのアクセスを、モニタリングアプリケーションインタフェースを通じて認識し、
前記クライアントのファイルアクセスアプリケーションからの前記ファイルシステムへの操作イベントが発生した場合、前記ファイルシステムへの前記操作の内容を、前記ＣＭＳサーバ処理部で管理される前記データベースに反映させる制御を行い、
前記クライアントのＣＭＳアプリケーションによるファイル操作を、前記ファイルシステムに対する操作に変換し、前記ファイルシステムに対して操作を行うとともに、前記ファイルシステムへの前記操作の内容を、前記ＣＭＳサーバ処理部に通知し、前記ＣＭＳサーバ処理部で管理される前記データベースに反映させる制御を行う、ことを特徴とする、ファイルサーバを用いたコンテンツ管理システム。
【請求項１７】
前記ＦＳ−ＣＭＳ連携処理部は、前記クライアントからの前記ファイルシステムの検索ディレクトリへのアクセスを、モニタリングアプリケーションインタフェースを通じて認識すると、前記検索ディレクトリ名の示す属性を備えているファイルを前記ＣＭＳサーバ処理部に問い合わせ、
前記ＣＭＳサーバ処理部は、前記ＦＳ−ＣＭＳ連携処理部からの前記問い合わせを受けて、前記データベースを検索して、前記検索ディレクトリ名の示す属性を備えているファイルのリストを、前記ＦＳ−ＣＭＳ連携処理部に返し、
前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルのリストをもとに、前記ファイルシステムにリンクファイルを作成し、前記検索ディレクトリ名の示す属性をもつファイルが一覧となって見えるようにしてなる、ことを特徴とする、請求項１６記載のファイルサーバを用いたコンテンツ管理システム。
【請求項１８】
クライアントからのファイルシステムへのアクセスを制御するファイルアクセスサーバ処理と、データベースにてコンテンツを管理するＣＭＳ（Ｃｏｎｔｅｎｔｓ  Ｍａｎａｇｅｍeｎｔ  Ｓｙｓｔｅｍ）サーバ処理と、を連携させる方法であって、
前記クライアントのファイルアクセスアプリケーションから、前記ファイルシステムへの操作が行われた場合、前記ファイルシステムへの前記操作の内容を、前記ＣＭＳサーバ処理に通知し、前記操作の内容を前記ＣＭＳサーバ処理で管理される前記データベースに反映させる制御を行う、
ことを特徴とする、ファイルアクセスサーバ処理とＣＭＳサーバ処理の連携方法。
【請求項１９】
前記クライアントがＣＭＳアプリケーションをさらに含み、前記クライアントのＣＭＳアプリケーションによるファイル操作に対して、前記ファイルシステムに対する操作に変換し、前記ファイルシステムに対して操作を行うとともに、前記操作の内容を、前記ＣＭＳサーバ処理で管理される前記データベースに反映させる制御を行う、ことを特徴とする請求項１８記載のファイルアクセスサーバ処理とＣＭＳサーバ処理の連携方法。
【請求項２０】
前記ＣＭＳサーバ処理のＣＭＳのコンテンツ操作用のＡＰＩ（アプリケーションインタフェース）を用いて、前記ファイルシステムに対する操作に対応するコンテンツ処理を実行する、ことを特徴とする請求項１８記載のファイルアクセスサーバ処理とＣＭＳサーバ処理の連携方法。
【請求項２１】
クライアントからのファイルシステムへのアクセスを制御するファイルアクセスサーバ処理と、データベースにてコンテンツを管理するＣＭＳ（Ｃｏｎｔｅｎｔｓ  Ｍａｎａｇｅｍeｎｔ  Ｓｙｓｔｅｍ）サーバ処理とを連携させる方法であって、
前記クライアントからの前記ファイルシステムへの操作イベントが発生した時、前記ＣＭＳサーバ処理部に通知して、前記ファイルシステムへの操作内容を、前記データベースに反映させ、
一方、前記ＣＭＳサーバ処理部が行う処理を、前記ファイルシステムに対する操作に変換して前記ファイルシステムに対して操作し、前記ファイルアクセスサーバ処理と前記ＣＭＳサーバ処理を連携させる、ことを特徴とする、ファイルアクセスサーバ処理とＣＭＳサーバ処理の連携方法。
【請求項２２】
クライアントからのファイルシステムへのアクセスを制御するファイルアクセスサーバ処理と、データベースにてコンテンツを管理するＣＭＳ（Ｃｏｎｔｅｎｔｓ  Ｍａｎａｇｅｍeｎｔ  Ｓｙｓｔｅｍ）サーバ処理と、を実行するコンピュータに、
前記クライアントのファイルアクセスアプリケーションからの前記ファイルシステムへの操作が行われた場合、前記ファイルシステムへの操作内容を、前記ＣＭＳサーバ処理で管理される前記データベースに反映させる制御を行う連携処理を実行させる、プログラム。
【請求項２３】
請求項２２記載のプログラムにおいて、
前記連携処理は、前記クライアントのＣＭＳアプリケーションによるファイル操作に対して、前記ファイルシステムに対する操作に変換し、前記ファイルシステムに対して操作を行うとともに、前記ファイルシステムに対する操作内容を、前記ＣＭＳサーバ処理で管理される前記データベースに反映させる制御を行う、プログラム。
【請求項２４】
請求項２２記載のプログラムにおいて、
前記連携処理では、前記ＣＭＳサーバ処理のＡＰＩ（アプリケーションインタフェース）を用いて前記ファイルシステムに対する操作に対応するコンテンツ処理を実行する、プログラム。
【請求項２５】
クライアントからのファイルシステムへのアクセスを制御するファイルアクセスサーバ処理と、データベースにてコンテンツを管理するＣＭＳ（Ｃｏｎｔｅｎｔｓ  Ｍａｎａｇｅｍeｎｔ  Ｓｙｓｔｅｍ）サーバ処理とを実行するコンピュータに、
前記クライアントからの前記ファイルシステムへの操作イベントが発生した時、前記ＣＭＳサーバ処理部に通知して、前記ファイルシステムへの操作内容を、前記データベースに反映させる処理と、
一方、前記ＣＭＳサーバ処理で行う処理を、前記ファイルシステムに対する操作に変換して前記ファイルシステムに対して操作し、前記ファイルアクセスサーバ処理と前記ＣＭＳサーバ処理を連携させる処理と、
を実行させる、プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システムに関し、特に、ファイルサーバのファイル管理と、コンテンツ管理システムを統合するシステムと方法及びコンピュータ・プログラムに関する。
【背景技術】
【０００２】
ストレージに格納される情報は年々増えつつあり、その膨大な情報をどうやって管理するか・活用するかが企業にとっても個人にとっても大きな課題となってくる。
【０００３】
データベースに格納されているデータを「構造化データ」、それ以外を「非構造化データ」と言う。
【０００４】
非構造化データは、ファイルとして、個人用パソコン内部やファイルサーバに格納されている。
【０００５】
特に、非構造化データの共有用途として、ファイルサーバやＮＡＳ（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ）は、汎用・高速・高信頼などの利点があり、現在広く使われている。
【０００６】
近年、この非構造化データの量が急激な伸びを見せており、このトレンドは今後さらに強まると見られている。これにともなって、非構造化データの管理がさらに重要な課題となってくると考えられる。
【０００７】
なお、特許文献１には、更新（登録、修正、削除等）のファイル操作を監視する監視手段を備えた構成が開示されている。また特許文献２には、データをファイル単位に管理することによってマルチメディア処理可能なファイルサーバの構成が開示されている。さらに特許文献３には、ＷＷＷサーバとＤＢサーバを備えたデータベース連携Ｗｅｂページ構築システムが開示されている。
【０００８】
【特許文献１】特開２００３−１４０９５８号公報
【特許文献２】特開平１１−９６１８７号公報
【特許文献３】特開２００２−１４８６４号公報
【非特許文献１】エンタープライズコンテンツ管理（ECM、ECMジャパン株式会社、インターネット  URL＜http://www.documentum.co.jp/solutions/ecm/ecm.htm>
【発明の開示】
【発明が解決しようとする課題】
【０００９】
従来のファイルサーバやファイルサーバ用のアプリケーションには、コンテンツ管理という視点が欠けている。
【００１０】
非構造化データは、今後さらに増えると見込まれており、非構造化データのコンテンツ管理の重要性は増している。
【００１１】
コンテンツ管理をするためには、ファイルに、多元的な属性を与え、それをもとにファイルを整理・検索するインターフェイスが必要である。
【００１２】
従来のファイルサーバは、そのような機能がない。このため、ファイルサーバ上では、ディレクトリ構成やファイル名といった単純なレベルでファイル管理する方法がとられている。
【００１３】
従来のファイルサーバは、コンテンツ管理に必要な多元的な属性の付与と、それに基づく整理・検索の機能を具備していない。
【００１４】
一方、コンテンツを管理、保存、展開等するために、コンテンツ管理システム（ＣＭＳ：Ｃｏｎｔｅｎｔｓ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）という製品（ソフトウエア）がある（例えば非特許文献１等参照）。
【００１５】
ＣＭＳでも、ファイルを扱い、管理することができる。しかしながら、ＣＭＳは、従来のファイルアクセスとは異なる専用システムを用いる必要がある。ファイルサーバとの互換性がなく、ファイルサーバとは別個のシステムとして構築しなければならない。
【００１６】
具体的には、一般に、ＣＭＳでファイルを読み書きする方法は、ファイルサーバの場合とは異なる。
【００１７】
このため、ユーザは、クライアント内のローカルディスクか、もしくは、ファイルサーバ上にて、ファイルを作成し、それをＣＭＳにアップロードするという作業が必要になる。
【００１８】
しかしながら、このような作業は非効率的である。
【００１９】
また、ファイルがローカルディスクやファイルサーバとＣＭＳの中に２重に存在するため、ストレージ容量の面でも非効率であり、一方を編集した場合に他方への反映を怠り一貫性が損なわれるなどの問題が起こりがちである。一部には、ＣＭＳの上にファイルサーバと互換のプロトコルでファイルの読み書きができるインターフェイスを設けた製品もある。
【００２０】
この種のＣＭＳ製品は、例えば図１５のような構成をとっている。なお、図１５は、従来のＯｒａｃｌｅ  Ｆｉｌｅｓの構成を模式的に示す図である。図１５を参照すると、ＣＭＳサーバ４は、ファイルアクセスサーバ処理部１３と、ＣＭＳサーバ処理部１７と、コンテンツを登録するデータベース１８と、ファイルシステム１４とを備えている。クライアント１は、ファイルアクセスアプリケーション１１と、ファイルアクセスクライアント処理部１２と、ＣＭＳアプリケーション１５と、ＣＭＳクライアント処理部１６とを備えている。クライアント１に対してはファイルサーバと同様に、既存のファイルアクセスアプリケーションが使えるという利点があり、かつＣＭＳの機能も実現できている。
【００２１】
しかし、一般に、ＣＭＳの機能は複雑であり、ファイルサーバと比較すると、読み出し書き込みの動作が遅いため、このような形態では、頻繁にファイルの読み書きを行うアプリケーションの動作には耐えず、ファイルサーバのように汎用的に使用できるものではない。
【００２２】
さらに、一般的なＣＭＳは、ファイルを、多元的な属性と共に管理しており、ユーザは、この多元的な属性に対して、キーワードを指定するなどの操作で、ファイルの検索を行う機能を有している。しかしながら、ＣＭＳの上に、ファイルサーバと互換のインターフェイスを設けただけの製品では、ファイルサーバのプロトコルにしか対応していないアプリケーションからは、ＣＭＳサーバ処理部で管理される、多元的な属性を参照することや、多元的な属性を用いて、ファイルの検索を行うことが出来ない。
【００２３】
すなわち、ファイルの作成や編集を行う環境と、ファイルの管理を行うＣＭＳとを、それぞれ別個のシステムとして構築しなければならず、
・作業の非効率性、
・容量の非効率性、
・ファイルの一貫性維持に対する脆弱性、
などの課題がある。
【００２４】
そして、ファイルサーバとＣＭＳとは、動作が大幅に異なることから、両者を統合することは極めて困難であった。
【００２５】
したがって、本発明の目的は、ファイルサーバとＣＭＳを統合可能とするシステム、方法とプログラムを提供することにある。
【課題を解決するための手段】
【００２６】
本願で開示される発明は、前記課題を解決するため、概略以下の通りの構成とされる。
【００２７】
本発明は、ファイルサーバとＣＭＳを統合させるため、以下のような機能を有するＦＳ−ＣＭＳ連携処理部を備えている。
【００２８】
本発明において、ＦＳ−ＣＭＳ連携処理部は、ファイルシステムへのイベントをモニタして、ＣＭＳに通知する手段と、ＣＭＳが行う処理をファイルシステムに対する操作に翻訳してファイルシステムに対して操作する手段を備える。
【００２９】
また、本発明においては、ＣＭＳの上でのみ管理していた多元的な属性を、ファイルシステムにおけるリンクに対応させ、ファイルサーバのプロトコルにしか対応していないアプリケーションからも使用可能にする。
【００３０】
さらに、本発明においては、検索ディレクトリという機能を設け、ＣＭＳの上でしか使用できなかったファイル検索を、ファイルサーバのプロトコルにしか対応していないアプリケーションからも使用可能としている。
【００３１】
さらにまた、本発明においては、検索ディレクトリからファイルを削除した場合に、ＣＭＳにおける多元的な属性をファイルシステムにおけるリンクに対応させた実装では、リンクが削除されるだけでファイルの実体は削除されないという課題が生じるため、削除イベントを監視する機構や、それに応じてファイルの実体を削除する機構などを設ける。
【００３２】
さらに、本発明においては、一部のアプリケーションの場合、ファイルを変更して保存すると、ファイルシステム上ではファイルの変更ではなく、新規ファイルに置き換わるという動作を行うため、この種のアプリケーションにて検索ディレクトリからファイルを更新すると、ファイルシステムにおけるリンクで表現していたＣＭＳにおける多元的な属性が失われてしまうという課題が生じるのに対し、リンクを再設定する機能を設ける。
【００３３】
本発明の一アスペクト（側面）に係るサーバ装置においては、ファイルシステムへのアクセスを制御するファイルアクセスサーバ処理部と、データベースにてコンテンツを管理するＣＭＳ（Ｃｏｎｔｅｎｔｓ  Ｍａｎａｇｅｍeｎｔ  Ｓｙｓｔｅｍ）サーバ処理部と、前記ファイルアクセスサーバ処理部による前記ファイルシステムへのファイル操作が行われた場合、前記ファイルシステムへの操作内容を前記ＣＭＳサーバ処理部に通知し、前記操作内容を、前記ＣＭＳサーバ処理部で管理される前記データベースに反映させる制御を行うＦＳ−ＣＭＳ連携処理部と、を備えている。
【００３４】
本発明に係るサーバ装置において、前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルサーバ装置が接続するクライアントのＣＭＳアプリケーションによるファイル操作を、前記ファイルシステムへのファイル操作に変換した上で、前記ファイルシステムに対して操作を行い、さらに、前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルシステムに対して行った前記操作の内容を、前記ＣＭＳサーバ処理部に通知し、前記操作の内容を、前記ＣＭＳサーバ処理部で管理される前記データベースに反映させる制御を行う構成としてもよい。
【００３５】
本発明に係るサーバ装置において、ＣＭＳアプリケーションのメニューページ上でファイル操作を選択するボタンのリンク先が、ＣＭＳアプリケーション本来の対応するページではなく予め用意した別のページに設定され、前記ボタンの選択時、前記別のページに制御が移り、前記ＦＳ−ＣＭＳ連携処理部の対応するファイル操作の処理が実行されるように設定されており、前記ＣＭＳアプリケーションのメニューページ上でファイル操作が選択された場合、前記ＦＳ−ＣＭＳ連携処理部により、前記ファイルシステムへのファイル操作が行われ、さらに、前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルシステムに対して行った前記操作の内容を、前記ＣＭＳサーバ処理部に通知し、前記操作の内容を、前記ＣＭＳサーバ処理部で管理される前記データベースに反映させる制御を行う、構成としてもよい。
【００３６】
本発明に係るサーバ装置において、前記ＦＳ−ＣＭＳ連携処理部は、前記ＣＭＳサーバ処理部のＡＰＩ（アプリケーションインタフェース）をコールすることで、前記ファイルシステムに為された前記操作の内容を、前記ＣＭＳサーバ処理部で管理される前記データベースに反映させる、構成としてもよい。
【００３７】
本発明に係るサーバ装置において、前記データベースが、１行あたり、ファイル名と、分類コードと、ファイルの属性情報の列を少なくとも含み、前記分類コードとして、ファイルの親ディレクトリのパス名を含み、前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルシステムへの操作イベント発生時、前記操作の対象となるパス名とファイル名とを取得し、ファイルの親ディレクトリを分類コードとして、前記ＣＭＳサーバ処理部のＣＭＳのコンテンツ操作用のＡＰＩをコールする、構成としてもよい。
【００３８】
本発明に係るサーバ装置において、前記データベースが、１行あたり、ファイル名と、分類コードと、ファイルの属性情報の列を少なくとも含み、前記ＦＳ−ＣＭＳ連携処理部は、ファイルの親ディレクトリのパス名と分類コードとを対応付ける変換テーブルを含み、前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルシステムへの操作イベント発生時、パス名とファイル名を取得し、親ディレクトリから前記変換テーブルを参照して分類コードを導き、前記ＣＭＳサーバ処理部のＣＭＳのコンテンツ操作用のＡＰＩをコールする、構成としてもよい。
【００３９】
本発明に係るサーバ装置は、ファイルシステムへのアクセスを制御するファイルアクセスサーバ処理部と、データベースにてコンテンツを管理するＣＭＳ（Ｃｏｎｔｅｎｔｓ  Ｍａｎａｇｅｍeｎｔ  Ｓｙｓｔｅｍ）サーバ処理部と、前記ファイルシステムへの操作イベントが発生した時、前記ＣＭＳサーバ処理部に通知して、前記データベースに反映させ、一方、前記ＣＭＳサーバ処理部が行う処理を、前記ファイルシステムに対する操作に変換して前記ファイルシステムに対して操作するＦＳ−ＣＭＳ連携処理部と、を備えている。
【００４０】
本発明において、前記ＦＳ−ＣＭＳ連携処理部は、クライアントから、前記ファイルシステムへのアクセスを、モニタリングアプリケーションインタフェースを通じて認識し、前記クライアントからのアクセスにより、前記ファイルシステムに変更が加えられると、前記ＦＳ−ＣＭＳ連携処理部は、前記変更内容を、前記ＣＭＳサーバ処理部に通知し、前記ＦＳ−ＣＭＳ連携処理部から前記通知を受けた前記ＣＭＳサーバ処理部では、前記データベースに前記変更内容を反映させ、前記クライアントがＣＭＳアプリケーションを用いてファイルに対する操作を行うと、前記ＦＳ−ＣＭＳ連携処理部を経由して、前記ファイルシステムにアクセスし、前記ＣＭＳサーバ処理部では、前記データベースに、前記変更内容を反映させる、構成としてもよい。
【００４１】
本発明に係るサーバ装置においては、ファイルシステムへのアクセスを制御するファイルアクセスサーバ処理部と、データベースにてコンテンツを管理するＣＭＳサーバ処理部と、前記ファイルシステムと前記ＣＭＳサーバ処理部を連携させるＦＳ−ＣＭＳ連携処理部と、を備え、前記ＦＳ−ＣＭＳ連携処理部は、クライアントから、前記ファイルシステムへのアクセスを、モニタリングアプリケーションインタフェースを通じて認識し、前記クライアントからのアクセスにより、前記ファイルシステムに変更が加えられると、前記ＦＳ−ＣＭＳ連携処理部は、前記変更内容を、前記ＣＭＳサーバ処理部に通知し、前記ＦＳ−ＣＭＳ連携処理部から前記通知を受けた前記ＣＭＳサーバ処理部では、前記データベースに、前記変更内容を反映させ、前記クライアントがＣＭＳアプリケーションを用いて前記ＣＭＳサーバ処理部にアクセスし、ファイルに対する操作を行うと、前記ＣＳＭサーバ処理部から、前記ＦＳ−ＣＭＳ連携処理部を経由して、前記ファイルシステムにアクセスする。
【００４２】
本発明において、前記ＦＳ−ＣＭＳ連携処理部は、前記削除（ＤＥＬＥＴＥ）を契機として、ファイルの拡張属性とリンクを設定しなおすようにしてもよい。
【００４３】
本発明において、前記ＦＳ−ＣＭＳ連携処理部は、前記クライアントからの前記ファイルシステムの検索ディレクトリへのアクセスを、モニタリングアプリケーションインタフェースを通じて認識すると、前記検索ディレクトリ名の示す属性を備えているファイルを、前記ＣＭＳサーバ処理部に問い合わせ、
前記ＣＭＳサーバ処理部は、前記ＦＳ−ＣＭＳ連携処理部からの前記問い合わせを受けて、前記データベースを検索して、前記検索ディレクトリ名の示す属性を備えているファイルのリストを、前記ＦＳ−ＣＭＳ連携処理部に返し、
前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルのリストをもとに、前記ファイルシステムにリンクファイルを作成し、前記検索ディレクトリ名の示す属性をもつファイルが一覧となって見えるようにしてもよい。
【００４４】
本発明において、前記ＦＳ−ＣＭＳ連携処理部が、ＲＥＮＡＭＥ元ファイルとＲＥＮＡＭＥ先ファイルを備えたＲＥＮＡＭＥテーブルと、ＤＥＬＥＴＥイベントを保存するＤＥＬＥＴＥテーブルを備えている。
【００４５】
本発明において、前記ＦＳ−ＣＭＳ連携処理部に、ＲＥＮＡＭＥ元ファイルとＲＥＮＡＭＥ先ファイルを備え、ＲＥＮＡＭＥイベントを保存するＲＥＮＡＭＥテーブルと、ＤＥＬＥＴＥイベントを保存するＤＥＬＥＴＥテーブルを備えている。前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルシステムのファイルが更新されるときには、ＲＥＮＡＭＥテーブルとＤＥＬＥＴＥテーブルを作成し、ＤＥＬＥＴＥイベントのファイルが、ＲＥＮＡＭＥテーブルのＲＥＮＡＭＥ先ファイルにあるかをチェックし、ＤＥＬＥＴＥイベントのファイルが存在した場合、ＲＥＮＡＭＥ元ファイルと同名なファイルがファイルシステム上にあるかをチェックし、ＲＥＮＡＭＥ元ファイルと同名なファイルが前記ファイルシステム上に存在した場合、アプリケーションの更新動作とみなし、拡張属性とリンクを再設定し、ＲＥＮＡＭＥテーブルとＤＥＬＥＴＥテーブルから、前記ファイルに関するエントリを削除する。
【００４６】
本発明に係るクライアント装置は、ファイルアクセスプロトコルと、ＣＭＳアクセスプロトコルで、前記本発明のファイルサーバのファイルアクセスサーバ処理部、ＣＭＳサーバ処理部にアクセスする。
【００４７】
本発明の他のアスペクト（側面）に係る方法は、クライアントからのファイルシステムへのアクセスを制御するファイルアクセスサーバ処理と、データベースにてコンテンツを管理するＣＭＳ（Ｃｏｎｔｅｎｔｓ  Ｍａｎａｇｅｍeｎｔ  Ｓｙｓｔｅｍ）サーバ処理と、を連携させる方法であって、前記クライアントのファイルアクセスアプリケーションからの前記ファイルシステムへの操作が行われた場合、前記ファイルシステムへの前記操作の内容を前記ＣＭＳサーバ処理に通知し、前記操作の内容を前記ＣＭＳサーバ処理で管理される前記データベースに反映させる制御を行う。本発明は、ファイルシステムへのアクセスを制御するファイルアクセスサーバ処理部と、コンテンツを管理するＣＭＳ（Ｃｏｎｔｅｎｔｓ  Ｍａｎａｇｅｍeｎｔ  Ｓｙｓｔｅｍ）サーバ処理部と、前記ファイルアクセスサーバ処理部とＣＭＳサーバ処理部を連携するＦＳ−ＣＭＳ連携処理部と、を備えたファイルサーバによる、ＦＳとＣＭＳの連携方法であって、
前記ＦＳ−ＣＭＳ連携処理部が、クライアントからのアクセス要求に基づき、ファイルシステムへのイベントをモニタしてＣＭＳサーバ処理部に通知する工程と、
前記ＦＳ−ＣＭＳ連携処理部が、前記ＣＭＳサーバ処理部が行う処理を、前記ファイルシステムに対する操作に変換してファイルシステムに対して操作する工程と、
を含む。
【００４８】
本発明に係る方法において、前記ＦＳ−ＣＭＳ連携処理部は、前記クライアントからファイルシステムへのアクセスを、モニタリングアプリケーションインタフェースを通じて認識し、前記クライアントからのアクセスにより、前記ファイルシステムに変更が加えられると、その変更内容を、前記ＣＭＳサーバ処理部に通知し、前記ＣＭＳサーバ処理部は、前記データベースにその変更を反映させる工程と、
前記クライアントがＣＭＳアプリケーションを用いて前記ＣＭＳサーバ処理部にアクセスし、ファイルに対する操作を行うと、前記ＣＳＭサーバ処理部から前記ＦＳ−ＣＭＳ連携処理部を経由して前記ファイルシステムにアクセスする工程と、
を含む。
【００４９】
本発明に係る方法において、ＣＭＳで管理される属性を、前記ファイルシステムにおけるリンクに対応させる工程を含み、前記ファイルサーバのプロトコルにしか対応していないアプリケーションからもＣＭＳをアクセス可能としている。
【００５０】
本発明に係る方法において、検索ディレクトリからファイルを削除した場合に、削除イベントを監視し、該削除イベントに応じてファイルの実体を削除する。
【００５１】
本発明に係る方法において、前記ＦＳ−ＣＭＳ連携処理部は、前記ＤＥＬＥＴＥを契機として、前記ファイルの拡張属性とリンクを設定しなおす。
【００５２】
本発明に係る方法において、前記ＦＳ−ＣＭＳ連携処理部は、
ファイルシステムのファイルが更新されるときには、ＲＥＮＡＭＥテーブルとＤＥＬＥＴＥテーブルを作成し、前記ＲＥＮＡＭＥテーブルは、ＲＥＮＡＭＥ元ファイルとＲＥＮＡＭＥ先ファイルを備え、
ＤＥＬＥＴＥイベントのファイルが、ＲＥＮＡＭＥテーブルのＲＥＮＡＭＥ先ファイルにあるかをチェックし、
ＤＥＬＥＴＥイベントのファイルが、ＲＥＮＡＭＥテーブルのＲＥＮＡＭＥ先ファイルに存在した場合、ＲＥＮＡＭＥ元ファイルと同名なファイルがファイルシステム上にあるかをチェックし、
ＲＥＮＡＭＥ元ファイルと同名なファイルがファイルシステム上に存在した場合、アプリケーションの更新動作とみなし、拡張属性とリンクを再設定し、
ＲＥＮＡＭＥテーブルとＤＥＬＥＴＥテーブルからこのファイルに関するエントリを削除する。
【００５３】
本発明の他のアスペクト（側面）に係るプログラムは、
ファイルシステムへのアクセスを制御するファイルアクセスサーバ処理部と、
コンテンツを管理するＣＭＳサーバ処理部と、
ＦＳ−ＣＭＳ連携処理部と、
を備えたファイルサーバのコンピュータに、
前記ＦＳ−ＣＭＳ連携処理部における、
クライアントからのアクセス要求に基づき、ファイルシステムへのイベントをモニタして前記ＣＭＳサーバ処理に通知する処理、
前記ＣＭＳサーバ処理で行う処理を、前記ファイルシステムに対する操作に変換してファイルシステムに対して操作する処理と、
を実行させるプログラムよりなる。
【００５４】
本発明の他のアスペクト（側面）に係るプログラムにおいて、
前記ＦＳ−ＣＭＳ連携処理部が、前記クライアントからファイルシステムへのアクセスを、モニタリングアプリケーションインタフェースを通じて認識し、前記クライアントからのアクセスにより、前記ファイルシステムに変更が加えられると、その変更内容を、前記ＣＭＳサーバ処理部に通知する処理と、
前記ＣＭＳサーバ処理部は、前記データベースにその変更を反映させる処理と、
前記クライアントがＣＭＳアプリケーションを用いて前記ＣＭＳサーバ処理部にアクセスし、ファイルに対する操作を行うと、前記ＣＳＭサーバ処理部から、前記ＦＳ−ＣＭＳ連携処理部を経由して前記ファイルシステムにアクセスする処理と
を前記コンピュータに実行させるプログラムよりなる。
【００５５】
本発明の他のアスペクト（側面）に係るプログラムにおいて、
ＣＭＳで管理される属性を、前記ファイルシステムにおけるリンクに対応させる処理を備え、
ファイルサーバのプロトコルにしか対応していないアプリケーションからもＣＭＳをアクセス可能としてなる、ことを特徴とするプログラムよりなる。
【００５６】
本発明の他のアスペクト（側面）に係るプログラムにおいて、
前記検索ディレクトリからファイルを削除した場合に、削除イベントを監視し、前記削除イベントに応じてファイルの実体を削除する処理を、
を前記コンピュータに実行させるプログラムよりなる。
【００５７】
本発明の他のアスペクト（側面）に係るプログラムにおいて、ＤＥＬＥＴＥを契機として、拡張属性とリンクを設定しなおす、処理を前記コンピュータに実行させるプログラムよりなる。
【００５８】
本発明の他のアスペクト（側面）に係るプログラムにおいて、前記ＦＳ−ＣＭＳ連携処理部が、
前記ファイルシステムのファイルが更新されるときには、ＲＥＮＡＭＥテーブルとＤＥＬＥＴＥテーブルを作成し、
ＤＥＬＥＴＥイベントのファイルが、ＲＥＮＡＭＥテーブルのＲＥＮＡＭＥ先ファイルにあるかをチェックし、
ＤＥＬＥＴＥイベントのファイルが、ＲＥＮＡＭＥテーブルのＲＥＮＡＭＥ先ファイルに存在した場合、ＲＥＮＡＭＥ元ファイルと同名なファイルがファイルシステム上にあるかをチェックし、
ＲＥＮＡＭＥ元ファイルと同名なファイルがファイルシステム上に存在した場合、アプリケーションの更新動作とみなし、拡張属性とリンクを再設定し、
ＲＥＮＡＭＥテーブルとＤＥＬＥＴＥテーブルからこのファイルに関するエントリを削除する処理を前記コンピュータに実行させるプログラムよりなる。
【発明の効果】
【００５９】
本発明によれば、ＦＳ−ＣＭＳ連携処理部を備え、ファイルサーバに対して行われた操作をＣＭＳに反映し、また、ＣＭＳが行う処理をファイルシステムに対して反映する構成としたことで、ファイルサーバで所望のコンテンツ管理を実現することができる。
【００６０】
本発明によれば、従来はファイルサーバとコンテンツ管理という２つのシステムに分離していたものを統合することで、より簡素で効率的な管理を可能としている。
【発明を実施するための最良の形態】
【００６１】
次に、本発明を実施する最良の形態のシステム構成について図を用いて説明する。図１は、本発明を実施する最良の形態のシステム構成の一例を示す図である。図１を参照すると、この実施形態は、少なくとも１台以上のクライアント１と、少なくとも１台以上のファイルサーバ２とを備えている。クライアント１とファイルサーバ２はネットワーク３で接続されている。
【００６２】
＜ファイルサーバ・ＣＭＳの仕組み＞
はじめに、ファイルサーバとＣＭＳの典型的な構成について、比較例として、図１０を参照して説明しておく。
【００６３】
図１０を参照すると、この比較例において、クライアント１は、ファイルアクセスアプリケーション１１と、ファイルアクセスクライアント処理部１２を備えている。
【００６４】
ファイルサーバ２は、ファイルアクセスサーバ処理部１３と、ファイルシステム１４を備えている。
【００６５】
クライアント１は、ファイルサーバ２にアクセスするときには、ファイルアクセスアプリケーション１１でファイルサーバ２を示すディレクトリを開き、ファイルにアクセスする。
【００６６】
ファイルアクセスアプリケーション１１は、ファイルアクセスクライアント処理部１２に処理を依頼する。
【００６７】
ファイルアクセスクライアント処理部１２は、ファイルアクセスプロトコル２１を介してファイルアクセスサーバ処理部１３と通信を行い、ファイル情報の獲得やファイルデータのＲＥＡＤ／ＷＲＩＴＥを行う。
【００６８】
ファイルサーバ２の内部において、ファイルアクセスサーバ処理部１３は、クライアント１のリクエストに応じてファイルシステム１４にアクセスし、ファイルシステム１４からの応答を、ファイルアクセスプロトコル２１に変換して、クライアント１に返すという処理を行う。
【００６９】
図１０に示すように、ＣＭＳサーバ４は、ファイルサーバ２とは別に設けられている。クライアント１は、ＣＭＳサーバ４への処理依頼を行うため、ＣＭＳアプリケーション１５とＣＭＳクライアント処理部１６を備えている。
【００７０】
ＣＭＳサーバ４は、ＣＭＳサーバ処理部１７と、データベース１８と、ファイルシステム１４を備えている。
【００７１】
典型的なＣＭＳにおいて、ファイルをＲＥＡＤ／ＷＲＩＴＥする方法は、ファイルサーバ２の場合とは異なる。
【００７２】
クライアント１上で動作するＣＭＳアプリケーション１５に、ファイルアップロードの類のメニューページが設けられており、該メニュー上からの操作で、ファイルをアップロードし、該メニューで、多元的な属性を設定する。
【００７３】
つまり、ユーザは、ファイルサーバ２上にファイルを作成し、コンテンツ管理を行うために、ＣＭＳアプリケーション１５のメニューの操作により、当該ファイルをＣＭＳサーバ４にアップロードするという作業が必要になる。
【００７４】
＜第１の実施形態＞
図２は、本発明の第１の実施形態の構成を示す図である。図２を参照すると、本実施形態において、ファイルサーバ２は、ファイルアクセスサーバ処理部１３と、ファイルシステム１４と、ＦＳ（File  System）−ＣＭＳ（Contents  Management  System）連携処理部１９と、ＣＭＳサーバ処理部１７と、データベース１８を備えている。クライアント１は、ファイルアクセスアプリケーション１１と、ファイルアクセスクライアント処理部１２と、ＣＭＳアプリケーション１５と、ＣＭＳクライアント処理部１６を備えている。なお、クライアント１の構成は、図１０の構成と同一である。ファイルサーバ２における、ファイルアクセスサーバ処理部１３、ＣＭＳサーバ処理部１７、ＦＳ−ＣＭＳ連携処理部１９の各処理部は、ファイルサーバ２を構成するコンピュータで実行されるプログラムによって処理、機能を実現してもよいことは勿論である。本実施の形態では、ファイルサーバ２に、ＦＳ−ＣＭＳ連携処理部１９を導入している。以下、ＦＳ−ＣＭＳ連携処理部１９の動作について説明する。
【００７５】
クライアント１がファイルアクセスアプリケーション１１を用いて、ファイルシステム１４にアクセスすると、ＦＳ−ＣＭＳ連携処理部１９は、イベントを検出するモニタリングＡＰＩ（アプリケーションインタフェース）２４を通じて、ファイルシステム１４へのアクセスを検出する。
【００７６】
モニタリングＡＰＩ２４は、さまざまな実装があるが、例えばデータ管理アプリケーションインタフェース（ＤＭＡＰＩ）が用いられる（ＤＭＡＰＩが有効化される）。ＤＭＡＰＩは、ファイルシステム１４に対して起きたイベントを受け取ることができるＡＰＩである。また、ＦＣＴＲＬのＮＯＴＩＦＹ機能を用いてもよい。
【００７７】
ＤＭＡＰＩの機能について、図１１を参照して概説する。ＤＭＡＰＩは、予めカーネルに登録した領域に対してアクセスがあると、アプリケーションに通知を行うＡＰＩ（アプリケーションインタフェース）である。
【００７８】
ＤＭＡＰＩアプリケーション２０（ＤＭＡＰＩを利用するユーザ空間アプリケーション）は、ファイルシステム１４に対して、場所とイベントを登録する（１）。
【００７９】
ここで、場所とは、イベントが発生したら通知をあげるディレクトリやファイルを指定する。なお、場所として、ファイルシステム全体を指定することも可能である。
【００８０】
イベントでは、通知をあげる操作を指定する。
【００８１】
登録されるイベントは、例えば
・ファイル作成（ＣＲＥＡＴＥ）、
・ファイル削除（ＤＥＬＥＴＥ）、
・ＯＰＥＮ、
・ＣＬＯＳＥ、
・ＲＥＡＤ、
・ＷＲＩＴＥ、
・ＲＥＮＡＭＥ、
・ＬＩＮＫ、・・・
など、ファイルシステムＡＰＩのほとんどが指定可能である。
【００８２】
図１１に示す例では、ＤＭＡＰＩアプリケーション２０は、場所：ディレクトリＡ、イベント：ＣＲＥＡＴＥを登録する。
【００８３】
この場合、ファイルシステム１４のディレクトリＡに、クライアント１がファイルＸを作成したときに（２）、ＤＭＡＰＩアプリケーション２０に対して、ディレクトリＡにファイルＸが作成されたことが通知される（３）。
【００８４】
再び、図２を参照すると、クライアント１のアクセスにより、ファイルシステム１４に変更が加えられると、ＦＳ−ＣＭＳ連携処理部１９は、その変更を、ＣＭＳサーバ処理部１７に通知する。ＣＭＳサーバ処理部１７は、データベース１８にその変更を反映させる。
【００８５】
また、クライアント１がＣＭＳアプリケーション１５を用いてＣＭＳサーバ処理部１７にアクセスし、ファイルに対する操作を行うと、ＣＳＭサーバ処理部１７から、ＦＳ−ＣＭＳ連携処理部１９を経由してファイルシステム１４にアクセスする。
【００８６】
これらの機能により、ファイルサーバとＣＭＳとで、ファイルの一貫性を保つことができる。
【００８７】
なお、ＣＭＳのデータベース１８の内容は、ＣＭＳによって異なるが、その基本は、ディレクトリの階層構造に相当する分類コードと、ファイル属性とが列になり、ファイルが行になっている。図１２に、ＣＭＳデータベースの一例を示す。図１２に示す例では、ファイル毎（行毎）に、ファイル名、分類コード、シリアルＩＤ、リビジョン、最終更新時刻、属性の各列がある。また、図１２に示す例では、分類コードは、ディレクトリと同じイメージである。このように、分類コードをディレクトリ階層構造と同じとすることで、ディレクトリと分類コードの相互の変換が不要となる。なお、分類コードとディレクトリ構造とを別にして、ＦＳ−ＣＭＳ連携処理部１９に変換テーブルを備えた構成としてもよい。
【００８８】
図２に示した本実施形態において、クライアント１のファイルアクセスにより、ファイルシステム１４に変更が加えられたときの動作を以下に説明する。
【００８９】
図１３は、本実施形態において、ファイルシステム１４に新規にファイルを作成した場合の処理を説明するためのフローチャートである。
【００９０】
クライアント１のファイルアクセスにより、ファイルシステム１４に新規にファイルを作成した場合、ＤＭＡＰＩを通じて、ＦＳ−ＣＭＳ連携処理部１９にファイルを新規に作成したファイルの親ディレクトリのパス名とファイル名が渡される（ＳＴＥＰ１）。
【００９１】
次に、ＦＳ−ＣＭＳ連携処理部１９で、分類コードを見つける（ＳＴＥＰ２）。
【００９２】
本実施形態においては、図１２を参照して説明したように、分類コードをディレクトリと同一とすることで、ＦＳ−ＣＭＳ連携処理部１９では、ＤＭＡＰＩから通知されたファイルの親ディレクトリのパス名から、容易に分類コードを導くことができる。なお、本発明は、分類コードをディレクトリと同一とする構成に限定されるものでなく、前述したように、分類コードとディレクトリを別にしてもよいことは勿論である。この場合、ＦＳ−ＣＭＳ連携処理部１９では、親ディレクトリのパス名から変換テーブルを引いて（検索して）、分類コードを導くなどして、分類コードを見つける必要がある。特に制限されないが、親ディレクトリのパス名と分類コードとの対応をテーブル形式で格納した変換テーブルは、ＦＳ−ＣＭＳ連携処理部１９内に備えてもよい。
【００９３】
次に、ＦＳ−ＣＭＳ連携処理部１９は、ＣＭＳサーバ処理部１７のＡＰＩをコールして、ファイルの新規登録を行う（ＳＴＥＰ３）。データベース１８には、新規ファイルに対応した、ファイル名、分類コード、シリアルＩＤ、リビジョン、最終更新時刻、属性の列が新規登録される。一般に、ＣＭＳには、外部プログラムからコンテンツを操作するためのＡＰＩが用意されている。本実施形態では、ＦＳ−ＣＭＳ連携処理部１９は、このＡＰＩを利用する。
【００９４】
次に、ファイルシステム１４に対するファイル操作が削除である場合を説明する。クライアント１のファイルアクセスにより、ファイルアクセスサーバ処理部１３により、ファイルシステム１４内のファイルを削除した場合には、ファイルの新規作成の場合と同様に、ＦＳ−ＣＭＳ連携処理部１９には、ＤＭＡＰＩ経由で、削除したファイルの親ディレクトリとファイル名が渡される。
【００９５】
ＦＳ−ＣＭＳ連携処理部１９では、親ディレクトリパス名から、分類コードを導き、ファイル名と同一のコンテンツを削除する。ファイルの削除は、ＣＭＳサーバ処理部１７のＡＰＩを利用する。この場合、例えば、データベース１８から当該ファイル名の行が削除される。
【００９６】
次に、ファイルシステム１４のファイルの更新について説明する。クライアント１のファイルアクセスにより、ファイルアクセスサーバ処理部１３により、ファイルの更新が行われた場合、ファイルの新規作成や削除の場合とは異なり、ファイルの最終更新時刻が変わるだけである。ＦＳ−ＣＭＳ連携処理部１９には、ＤＭＡＰＩ経由で、ファイルのパス名が渡される。ＦＳ−ＣＭＳ連携処理部１９は、ファイルパス名から分類コードを導き、最終更新時刻を変更するために、ＣＭＳサーバ処理部１７のＡＰＩをコールする。この場合、データベース１８の当該ファイル名、分類コードに対応する行の、最終更新時刻の列が変更される。
【００９７】
次に、クライアント１がＣＭＳアプリケーション１５を用いてファイルに変更を加えたときの動作を説明する。
【００９８】
まず、新規にファイルを作成した場合、クライアント１は、ＣＭＳアプリケーション１５経由で、ファイルをアップロードする。その際、ファイルのアップロード先が、図２のファイルシステム１４内となるように、事前に設定しておく。
【００９９】
本実施形態においては、クライアント１が、ＣＭＳサーバ上のフォルダで、ファイルをアップロードするだけで、自動的に、ファイルサーバ２のファイルシステム１４内の対応するディレクトリに、該ファイルがアップロードされる。すなわち、比較例として示した図１０の構成の場合、クライアント１は、ＣＭＳアプリケーション１５の操作により、ＣＭＳサーバ４上のフォルダで、ファイルをアップロードすると、ＣＭＳサーバ４のファイルシステム１４内にファイルを新規作成することになるが、本実施形態では、図２のファイルサーバ２のファイルシステム１４内にファイルが新規作成されるように、アップロード先が設定されている。
【０１００】
なお、ＣＭＳサーバがファイルのアップロード先を設定（変更）できない構成の場合や、ファイルの作成操作によりデータベース内部にファイルを格納してしまう場合には、別の方法をとる必要がある。その手法について、図１４を参照して説明する。
【０１０１】
まず、ＣＭＳサーバ（図１０の４）で、新規ファイルを登録するためのページ（ＣＭＳメニューページ）を、ＦＳ−ＣＭＳ連携処理部１９にアクセスするＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）とし、ボタンの選択により、独自に設けた新規登録ページに飛ぶように予め設定しておく。これは、ＣＭＳメニューページの新規ファイル登録のリンクを書き換えるだけで済むことから、変更は容易である。具体的には、ＣＭＳメニューページの新規登録ボタン６１のリンク先を、独自の新規登録ページ７１（ＵＲＬ）に設定しておく。クライアント１において、ＣＭＳアプリケーション１５のＣＭＳメニューページの新規登録ボタン６１が選択されると、リンク先の新規登録ページ７１が表示され、新規登録ページ７１上でファイルをアップロードすると、ファイルサーバ２のＦＳ−ＣＭＳ連携処理部１９の対応する処理に移行する。
【０１０２】
ＦＳ−ＣＭＳ連携処理部１９では、新規登録ページ７１でアップロードされたファイルをファイルシステム１４に格納し、ファイルシステム１４へのファイルの新規作成に対応してＣＭＳサーバ処理部１７に対して、前述したＣＭＳのＡＰＩをコールして、ＣＭＳのデータベース１８に対して、新規ファイルの登録を行う。なお、ＣＭＳサーバ処理部１７に対する処理は、ファイルアクセスサーバ処理部１３からファイルシステム１４に新規ファイルを作成した場合にＦＳ−ＣＭＳ連携処理部１９がＣＭＳサーバ処理部１７に対して行う処理と同じである。
【０１０３】
次に、クライアント１で動作するＣＭＳアプリケーション１５からのファイル削除操作について、図１４を参照して説明する。ＣＭＳアプリケーション１５のメニューページからファイルシステム１４のファイルを削除する場合も、同様にして、削除ボタン６２から、独自の削除ページ７２へリンクするようにしておく。これにより、ＦＳ−ＣＭＳ連携処理部１９に対して、最初に、ファイルの削除が通知され、ＦＳ−ＣＭＳ連携処理部１９は、ファイルシステム１４から該当するファイルの削除を行い、つづいて、ＣＭＳサーバ処理部１７に対して、前述したＣＭＳサーバ処理部１７のＡＰＩをコールして、データベース１８の対応する行の内容を削除する。これにより、ファイルシステムとＣＭＳの連携をとることができる。
【０１０４】
ＣＭＳアプリケーション１５のメニューページからファイルシステム１４のファイルを更新する場合も、更新ボタン６３から独自の更新ページ７３へリンクするようにしておく。
【０１０５】
これにより、ＦＳ−ＣＭＳ連携処理部１９に対して、最初に、更新が通知され、ＦＳ−ＣＭＳ連携処理部１９は、ファイルシステム１４において、ファイルの更新を行い、つづいて、ＣＭＳサーバ処理部１７に対して、前述したＣＭＳのＡＰＩをコールして、ＣＭＳのデータベース１８の対応する行において、更新情報を設定する。これにより、ファイルシステムとＣＭＳの連携をとることができる。
【０１０６】
なお、図２のＣＭＳのデータベース１８に対して、クライアント１のＣＭＳアプリケーション１５、ＣＭＳクライアント処理部１６、ＣＭＳアクセスプロトコル２３、ＣＭＳサーバ処理部１７を介して、ＣＭＳのデータベース１８の内容に変更が為され、ファイルシステム１４に変更内容を反映する必要がある場合、ＣＭＳサーバ処理部１７が、ＦＳ−ＣＭＳ連携処理部１９に通知し、ＦＳ−ＣＭＳ連携処理部１９にてファイルシステム１４へのファイル操作を行うようにしてもよいことは勿論である。例えば、ＣＭＳのデータベース１８（図１２）内のある行（エントリ）を削除する場合、削除対象の行のファイル名と分類コードのパス名（親ディレイトリ）をＦＳ−ＣＭＳ連携処理部１９に通知し、ＦＳ−ＣＭＳ連携処理部１９がファイルシステム１４内の該当ファイルの削除操作を行うようにしてもよい。すなわち、ＣＭＳ側からファイルシステム側への連携を行うことができる。ファイルのＲＥＮＡＭＥ等も、同様にして行うことができる。
【０１０７】
＜第２の実施形態＞
次に、本発明の第２の実施形態について説明する。本実施形態では、ＣＭＳの検索機能を、ファイルシステムとして実現する。ＣＭＳには、多元的な属性やファイル同士の関連性を把握し、ユーザに対して整理して提示したり、ストレージ管理に利用したり、関連性を提示したりする機能が必要である。
【０１０８】
本実施形態では、ファイルサーバ上でその機能を実現するために、検索ディレクトリを用いる。
【０１０９】
まず、検索ディレクトリの機能について説明し、つづいて検索ディレクトリを実現するために、図２のＦＳ−ＣＭＳ連携処理部１９がどのような動作をするかについて説明する。
【０１１０】
検索ディレクトリは、多元的な属性、またはその組み合わせがディレクトリ名となっており、そのディレクトリを開くと、その属性が付与されているファイルが一覧となって見えるものである。
【０１１１】
通常のディレクトリと同じように見えるため、クライアント１は、ファイルアクセスアプリケーション１１を介してアクセスでき、また更新も可能である。
【０１１２】
検索ディレクトリは、図２のファイルアクセスアプリケーション１１でアクセスできるので、ＣＭＳクライアント処理部１６を導入していないクライアント１でも、アクセスが可能となる。図３を参照して、具体的に説明する。図３は、本発明の第２の実施形態を説明するための図であり、検索ディレクトリのリンク構成が模式的に示されている。
【０１１３】
ディレクトリＡ（３１）にファイルＸ（３４）が置かれており、「開発情報」と「機密」という２つの属性３７が付与されている。
【０１１４】
検索ディレクトリ「開発情報」（３２）と検索ディレクトリ「機密」（３３）がファイルシステム１４に作成される。
【０１１５】
検索ディレクトリ「開発情報」（３２）にリンクファイルＸ１（３５）が置かれ、検索ディレクトリ「機密」（３３）にはリンクファイルＸ２（３６）が置かれている。
【０１１６】
これらのリンクファイルは、ハードリンクまたはシンボリックリンクで、ファイルＸ（３４）にリンクされている。つまり、これらのファイルを開く（「ＯＰＥＮ」する）と、ファイルＸ（３４）が開く。
【０１１７】
クライアント１は、例えば「開発情報」という属性のついたファイル、あるいは、「機密」という属性のついたファイルを探す場合、検索ディレクトリ「開発情報」（３２）や、検索ディレクトリ「機密」（３３）を開くことで、簡単に見つけることができる。
【０１１８】
このような検索ディレクトリを、ＦＳ−ＣＭＳ連携処理部１９がどのように実現しているかについて以下に説明する。
【０１１９】
まず、ファイルシステム１４に、検索ディレクトリを作成する。
【０１２０】
検索ディレクトリの作成については、
・ＦＳ−ＣＭＳ連携処理部１９が自動で作成してもよいし、
・クライアント１からＣＭＳクライアント処理部１６を通じて作成を指示するようにしてもよい。
【０１２１】
クライアント１が検索ディレクトリにアクセスしてきたら、ＦＳ−ＣＭＳ連携処理部１９は、モニタリングＡＰＩ２４を通じて、検索ディレクトリのアクセスを検出する。
【０１２２】
モニタリングＡＰＩ２４が、クライアントによる検索ディレクトリのアクセスを検出したら、ＦＳ−ＣＭＳ連携処理部１９は、その検索ディレクトリ名の示す属性を備えているファイルを、ＣＭＳサーバ処理部１７に問い合わせる。
【０１２３】
ＣＭＳサーバ処理部１７は、データベース１８を検索して、該当するファイルリストをＦＳ−ＣＭＳ連携処理部１９に返す。
【０１２４】
該当するファイルリストをもとに、ＦＳ−ＣＭＳ連携処理部１９は、ファイルシステム１４に、リンクファイルを作成する。このリンクは、ハードリンクであってもシンボリックリンクであってもよい。これにより、検索ディレクトリに、その属性をもつファイルのリストが見えるようになる。
【０１２５】
このように、検索ディレクトリを作ると、１つのファイルに対して、ファイルシステム１４内で複数のリンクファイルが作成される。
【０１２６】
通常のファイルシステム１４では、ファイルが削除されたときに、そのファイルにリンクしているリンクファイルは削除されない。つまり、ファイル自体が削除されても、検索ディレクトリからは削除されないことになってしまう。
【０１２７】
そして、削除されたファイルにアクセスしたときの現象は、ハードリンクとシンボリックリンクの場合で異なる。
【０１２８】
例えばハードリンクの場合、ファイルの削除操作により、ファイルのリンクカウンタが１つ減るだけで、ファイル実体はファイルシステム１４から削除されない。ファイルシステム１４では、リンクカウンタが「０」になったら、ファイル実体が削除される。つまり、検索ディレクトリから、ファイルをアクセスすると、ファイル実体にアクセスできてしまう。つまり、ファイルを削除したのに、アクセスできてしまうというおかしな現象になる。
【０１２９】
一方、シンボリックリンクの場合、リンクカウンタは「１」のままであるため、ファイルの削除動作により、ファイルシステム１４から、ファイル実体が削除される。この削除の実行に対して、すでに、ファイル自体は削除されているので、アクセスしたときに、ファイルが存在しないというエラーがでる。
【０１３０】
つまり、ファイル実体は存在しないのに、検索ディレクトリからは、該ファイルは削除されない、という、おかしな現象になる。
【０１３１】
この問題を解決するため、ＦＳ−ＣＭＳ連携処理部１９は、モニタリングＡＰＩ２４を通じて、ファイルが削除されたことを受けとったら、削除されたファイルにリンクしているリンクファイルを、ＣＭＳサーバ処理部１７に問い合わせる。
【０１３２】
ＣＭＳサーバ処理部１７は、データベース１８を検索し、リンクしているファイルの情報をＦＳ−ＣＭＳ連携処理部１９に返す。
【０１３３】
ＦＳ−ＣＭＳ連携処理部１９は、それに基づいて、ファイルシステム１４上のリンクファイルを削除する。
【０１３４】
ファイルシステム１４がゴミ箱フォルダ機能を備えている場合には、削除要求を受けたファイルはいきなり削除されるのではなく、ファイルシステム１４上でゴミ箱フォルダへ移動される。
【０１３５】
その場合は、ＦＳ−ＣＭＳ連携処理部１９は、削除イベントではなく、ゴミ箱フォルダへの移動（ＲＥＮＡＭＥ）というイベントを受け取る。
【０１３６】
ＦＳ−ＣＭＳ連携処理部１９は、ゴミ箱フォルダへの移動を削除イベントと同じように扱い、リンクファイルを削除する。
【０１３７】
検索ディレクトリ内のファイルは、通常のファイルアクセスアプリケーション１１からアクセス可能であり、更新も可能である。ファイルの内容を変更しても、属性は変化しないし、検索ディレクトリのリンクファイルもつながった状態で保持される。
【０１３８】
ただし、一部のアプリケーションでファイルを変更して保存すると、ファイルシステム１４上では、ファイルの変更ではなく、新規ファイルに置き換わる場合がある。
【０１３９】
これは、アプリケーションの更新の途中でシステムが止まってしまった場合などには元の状態に戻れるようにするために、アプリケーションが行っている工夫である。
【０１４０】
ファイル自体に、上書き変更していくのではなく、別のファイルに変更を含めて、全てＷＲＩＴＥし、最終的に保存するときには、元ファイルの削除と、新規ファイルのファイル名変更（ＲＥＮＡＭＥ）を行う。こうすることにより、ファイル名変更というアトミックな処理で更新ができるため、更新の途中状態というステータスが無くなるのである。
【０１４１】
この動作のフローは、２つのタイプ（タイプＡ、タイプＢ）に分類できる。それぞれについて図４、及び図５を用いて説明する。
【０１４２】
まず、タイプＡについて図４を用いて説明する。図４は、ファイルＡ（４１）を更新する場合のフローを示している。
【０１４３】
まず、ファイルＡ（４１）は、「〜ファイルＡ２．ｔｍｐ」（４２）にＲＥＮＡＭＥされる（ＳＴＥＰ１）。これは更新前のファイルのバックアップという意味がある。
【０１４４】
更新を加えたファイルは、「〜ファイルＡ１．ｔｍｐ」（４３）という名前で、新規にＣＲＥＡＴＥ（作成）され、更新内容を含めてＷＲＩＴＥ(書き込み)される（ＳＴＥＰ２）。
【０１４５】
すべてＷＲＩＴＥされたら、元のファイルＡ（４１）にＲＥＮＡＭＥされる（ＳＴＥＰ３）。
【０１４６】
最後にバックアップファイルである「〜ファイルＡ２．ｔｍｐ」（４２）がＤＥＬＥＴＥ（削除）される（ＳＴＥＰ４）。
【０１４７】
この一連の動作により、途中のどの段階で止まってしまったとしても、バックアップに戻ることが可能とされ、更新途中であったことを検出することもできる。
【０１４８】
次に、タイプＢについて、図５を用いて説明する。タイプＢの場合、ファイルＡ（４１）は、「〜ファイルＡ．ｂａｋ」（４２）にＲＥＮＡＭＥされ（ＳＴＥＰ１）、更新を加えた新規ファイルが、はじめからファイルＡ（４１）として、ＣＲＥＡＴＥされ、ＷＲＩＴＥされる（ＳＴＥＰ２）。
【０１４９】
その後、「〜ファイルＡ．ｂａｋ」が削除される。
【０１５０】
この場合も、バックアップ用テンポラリファイル「〜ファイルＡ．ｂａｋ」（４２）が存在するため、更新途中で止まってしまっても、戻ることができる。
【０１５１】
しかし、検索ディレクトリにとっては、タイプＡにしてもタイプＢにしても、このような更新は都合が悪い。
【０１５２】
まず、ファイルシステム１４としては、別のファイルになってしまうため、多元的な属性をファイルシステムの拡張属性に保存している場合には、失われてしまう。
【０１５３】
また、検索ディレクトリのリンクは、シンボリックリンクであれば、ファイル名でつながっているので保持されるが、ハードリンクは切れてしまう。
【０１５４】
ファイルシステム１４として、別のファイルであるため仕方ないとも言えるが、ユーザにとっては更新であることからすると、コンテンツ管理システムとしては、利便性が損なわれてしまう。
【０１５５】
そこで、この問題を、本実施形態のＦＳ−ＣＭＳ連携処理部１９を用いて、どのように解決しているか、以下に説明する。
【０１５６】
アプリケーションがファイル４１を更新する際の動作では、必ず、ファイル４１がバックアップ用テンポラリファイル４２にＲＥＮＡＭＥされ（ＳＴＥＰ１）、最後にバックアップ用テンポラリファイル４２がＤＥＬＥＴＥされる（ＳＴＥＰ３またはＳＴＥＰ４）。
【０１５７】
更新フローの最後は、ＤＥＬＥＴＥであり、これをきっかけとして、拡張属性とリンクを設定しなおすのがよい。
【０１５８】
そのために、ＦＳ−ＣＭＳ連携処理部１９に、ＲＥＮＡＭＥイベントを保存するＲＥＮＡＭＥテーブル５１と、ＤＥＬＥＴＥイベントを保存するＤＥＬＥＴＥテーブル５２を持つ。
【０１５９】
これらのイベントを保存して参照することで、アプリケーションの更新を検出する。
【０１６０】
具体的には、図４のタイプＡのフローでファイルＡが更新されるときには、図６（Ａ）、図６（Ｂ）のＲＥＮＡＭＥテーブル５１とＤＥＬＥＴＥテーブル５２が作成される。ＲＥＮＡＭＥテーブル５１は、ＲＥＮＡＭＥ元ファイルとＲＥＮＡＭＥ先ファイル、属性欄を備える。ＤＥＬＥＴＥテーブル５２は、ＣＲＥＡＴＥファイルを有する。
【０１６１】
図５のタイプＢのフローでファイルＡが更新されるときは、図７（Ａ）、（Ｂ）のＲＥＮＡＭＥテーブル５１、ＤＥＬＥＴＥテーブル５２ができる。
【０１６２】
図８は、本実施形態の処理手順を示す流れ図である。図８を参照して、本実施形態の処理を説明する。
【０１６３】
まず、ＤＥＬＥＴＥイベント発生で処理がスタートする（ＳＴＥＰ０）。
【０１６４】
ＤＥＬＥＴＥイベントのファイルが、ＲＥＮＡＭＥテーブル５１のＲＥＮＡＭＥ先ファイルに存在するかをチェックする（ＳＴＥＰ１）。
【０１６５】
ＤＥＬＥＴＥイベントのファイルが、ＲＥＮＡＭＥテーブル５１のＲＥＮＡＭＥ先ファイルに存在した場合、ＲＥＮＡＭＥ元ファイルと同名なファイルがファイルシステム上にあるかをチェックする（ＳＴＥＰ２）。
【０１６６】
ＲＥＮＡＭＥ元ファイルと同名なファイルがファイルシステム上に存在した場合には、アプリケーションの更新動作とみなし、拡張属性とリンクを再設定する（ＳＴＥＰ３）。
【０１６７】
最後に、ＲＥＮＡＭＥテーブル５１とＤＥＬＥＴＥテーブル５２から、該ファイルに関するエントリを削除する（ＳＴＥＰ４）。これは、該ファイルのエントリの削除を行わないと、ＲＥＮＡＭＥテーブル５１とＤＥＬＥＴＥテーブル５２が際限なく大きくなるためである。
【０１６８】
ファイルシステム１４が、ゴミ箱フォルダ機能を備えている場合には、更新時の元ファイルはゴミ箱フォルダに移動する。つまり、ＤＥＬＥＴＥテーブル５２がＲＥＮＡＭＥテーブル５１で代替可能となる。
【０１６９】
図９（Ａ）、図９（Ｂ）に、タイプＡとタイプＢの場合のＲＥＮＡＭＥテーブル５１をそれぞれ示す。
【０１７０】
ゴミ箱フォルダへのＲＥＮＡＭＥイベントを受け取ったら、ＲＥＮＡＭＥテーブル５１を参照して、元ファイル名を割り出す。
【０１７１】
そして、ファイルシステム上に、ＲＥＮＡＭＥ元ファイルと同名のファイルが存在すれば、ゴミ箱フォルダのファイルから、拡張属性やリンクを引き継ぐ。
【０１７２】
あるいは、スナップショットを利用して定期的に再設定するようにしてもよい。例えば夜間などのアクセスがない時間帯にリンクを総チェックする。
【０１７３】
リンク切れの復旧のために、スナップショットを利用する。リンク切れのファイルは、現在のファイルシステム１４からは削除されているが、スナップショットをとっている場合には、スナップショット領域には、残っている。よって、スナップショット領域のファイルにアクセスし、それが、現在のファイルシステム１４にも存在するか否かをチェックすることで、リンク切れを検出することができる。
【０１７４】
もし、スナップショット領域のファイルと、現在のファイルシステム上のファイルとが同一であれば、リンクはつながっており、異っていれば、更新されたことを意味する。
【０１７５】
これは、例えばｉｎｏｄｅ番号（データ領域を確保するための番号）を比較したり、更新時刻を比較したりすることで、可能である。
【０１７６】
更新されている場合、スナップショット領域のファイルから、拡張属性を読みこんで、更新後のファイルに設定し、リンクは張り直す。
【０１７７】
リンク切れの総チェックを行うときに、予めＲＥＮＡＭＥイベントを受けていれば、そのファイルだけをチェックする、もしくは、何らかの機能により更新されたファイル一覧を獲得できれば、それだけをチェックすることも可能である。これにより、チェックにかかる時間を短縮できる。
【０１７８】
上記した本実施形態によれば、ファイルサーバとコンテンツ管理システムという２つのシステムを統合することができ、管理の簡素化、効率化ができる。ファイルサーバでファイル管理をしているところにコンテンツ管理システムを導入すると、従来は二重管理になってしまうために避けるところが多かった。本発明によれば、ファイルサーバを残しつつコンテンツ管理システムを組み込むことができ、導入障壁が低くなる。
【０１７９】
なお、前記ＦＳ−ＣＭＳ連携処理部１９における、ファイルシステム１４への操作イベントの認識は、ポーリング方式、あるいは、イベント発生が割り込み等で通知される方式等、任意の方式で行ってもよい。
【０１８０】
以上、本発明を上記実施例に即して説明したが、本発明は上記実施例の構成にのみ制限されるものでなく、本発明の範囲内で当業者であればなし得るであろう各種変形、修正を含むことは勿論である。
【図面の簡単な説明】
【０１８１】
【図１】本発明の一実施形態のシステム構成を示す図である。
【図２】本発明の一実施形態の機能構成を示す図である。
【図３】本発明の検索ディレクトリのリンク構成を模式的に示す図である。
【図４】アプリケーションがファイルを更新するフローを示す図である。
【図５】アプリケーションがファイルを更新するフローを示す図である。
【図６】（Ａ）、（Ｂ）は、本発明の第２の実施形態におけるＲＥＮＡＭＥテーブル・ＤＥＬＥＴＥテーブルをそれぞれ示す図である。
【図７】（Ａ）、（Ｂ）は、本発明の第２の実施形態におけるＲＥＮＡＭＥテーブル・ＤＥＬＥＴＥテーブルを示す図である。
【図８】本発明の第２の実施形態における拡張属性・リンクの再設定フローを示す図である。
【図９】（Ａ）、（Ｂ）は、本発明の第２の実施形態におけるＲＥＮＡＭＥテーブルとＤＥＬＥＴＥテーブルをそれぞれ示す図である。
【図１０】比較例のファイルサーバとＣＭＳの機能構成を示す図である。
【図１１】ＤＭＡＰＩの動作を説明する図である。
【図１２】ＣＭＳデータベースの構成の一例を説明する図である。
【図１３】ファイルシステムに新規ファイル作成したときのフローを示す図である。
【図１４】ＣＭＳからファイル操作したときの構成を示す図である。
【図１５】従来のＯｒａｃｌｅ Ｆｉｌｅｓの構成を示す図である。
【符号の説明】
【０１８２】
１  クライアント
２  ファイルサーバ
３  ネットワーク
４  ＣＭＳサーバ
１１  ファイルアクセスアプリケーション
１２  ファイルアクセスクライアント処理部
１３  ファイルアクセスサーバ処理部
１４  ファイルシステム
１５  ＣＭＳアプリケーション
１６  ＣＭＳクライアント処理部
１７  ＣＭＳサーバ処理部
１８  データベース
１９  ＦＳ−ＣＭＳ連携処理部
２０  ＤＭＡＰＩアプリケーション
２１  ファイルアクセスプロトコル
２２  ファイルシステムＡＰＩ
２３  ＣＭＳアクセスプロトコル
２４  モニタリングＡＰＩ
３１  ディレクトリＡ
３２  検索ディレクトリ
３３  検索ディレクトリ
３４  ファイルＸ
３５  リンクファイルＸ１
３６  リンクファイルＸ２
３７  属性
４１  ファイルＡ
４２  バックアップ用テンポラリファイル
４３  更新用テンポラリファイル
５１  ＲＥＮＡＭＥテーブル
５２  ＤＥＬＥＴＥテーブル
６１  新規登録ボタン
６２  削除ボタン
６３  更新ボタン
７１  新規登録ページ
７２  削除ページ
７３  更新ページ
【図１】
2008040602.tif 000003
【図２】
2008040602.tif 000004
【図３】
2008040602.tif 000005
【図４】
2008040602.tif 000006
【図５】
2008040602.tif 000007
【図６】
2008040602.tif 000008
【図７】
2008040602.tif 000009
【図８】
2008040602.tif 000010
【図９】
2008040602.tif 000011
【図１０】
2008040602.tif 000012
【図１１】
2008040602.tif 000013
【図１２】
2008040602.tif 000014
【図１３】
2008040602.tif 000015
【図１４】
2008040602.tif 000016
【図１５】
2008040602.tif 000017