JP4952119B2 - ファイルサーバを用いたコンテンツ管理システムと方法およびプログラム - Google Patents

Description

本発明は、情報処理システムに関し、特に、ファイルサーバのファイル管理と、コンテンツ管理システムを統合するシステムと方法及びコンピュータ・プログラムに関する。

ストレージに格納される情報は年々増えつつあり、その膨大な情報をどうやって管理するか・活用するかが企業にとっても個人にとっても大きな課題となってくる。

データベースに格納されているデータを「構造化データ」、それ以外を「非構造化データ」と言う。

非構造化データは、ファイルとして、個人用パソコン内部やファイルサーバに格納されている。

特に、非構造化データの共有用途として、ファイルサーバやＮＡＳ（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ）は、汎用・高速・高信頼などの利点があり、現在広く使われている。

近年、この非構造化データの量が急激な伸びを見せており、このトレンドは今後さらに強まると見られている。これにともなって、非構造化データの管理がさらに重要な課題となってくると考えられる。

なお、特許文献１には、更新（登録、修正、削除等）のファイル操作を監視する監視手段を備えた構成が開示されている。また特許文献２には、データをファイル単位に管理することによってマルチメディア処理可能なファイルサーバの構成が開示されている。さらに特許文献３には、ＷＷＷサーバとＤＢサーバを備えたデータベース連携Ｗｅｂページ構築システムが開示されている。

特開２００３−１４０９５８号公報 特開平１１−９６１８７号公報 特開２００２−１４８６４号公報 エンタープライズコンテンツ管理（ECM、ECMジャパン株式会社、インターネット URL＜http://www.documentum.co.jp/solutions/ecm/ecm.htm>

従来のファイルサーバやファイルサーバ用のアプリケーションには、コンテンツ管理という視点が欠けている。

非構造化データは、今後さらに増えると見込まれており、非構造化データのコンテンツ管理の重要性は増している。

コンテンツ管理をするためには、ファイルに、多元的な属性を与え、それをもとにファイルを整理・検索するインターフェイスが必要である。

従来のファイルサーバは、そのような機能がない。このため、ファイルサーバ上では、ディレクトリ構成やファイル名といった単純なレベルでファイル管理する方法がとられている。

従来のファイルサーバは、コンテンツ管理に必要な多元的な属性の付与と、それに基づく整理・検索の機能を具備していない。

一方、コンテンツを管理、保存、展開等するために、コンテンツ管理システム（ＣＭＳ：Ｃｏｎｔｅｎｔｓ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）という製品（ソフトウエア）がある（例えば非特許文献１等参照）。

ＣＭＳでも、ファイルを扱い、管理することができる。しかしながら、ＣＭＳは、従来のファイルアクセスとは異なる専用システムを用いる必要がある。ファイルサーバとの互換性がなく、ファイルサーバとは別個のシステムとして構築しなければならない。

具体的には、一般に、ＣＭＳでファイルを読み書きする方法は、ファイルサーバの場合とは異なる。

このため、ユーザは、クライアント内のローカルディスクか、もしくは、ファイルサーバ上にて、ファイルを作成し、それをＣＭＳにアップロードするという作業が必要になる。

しかしながら、このような作業は非効率的である。

また、ファイルがローカルディスクやファイルサーバとＣＭＳの中に２重に存在するため、ストレージ容量の面でも非効率であり、一方を編集した場合に他方への反映を怠り一貫性が損なわれるなどの問題が起こりがちである。一部には、ＣＭＳの上にファイルサーバと互換のプロトコルでファイルの読み書きができるインターフェイスを設けた製品もある。

この種のＣＭＳ製品は、例えば図１５のような構成をとっている。なお、図１５は、従来のＯｒａｃｌｅ Ｆｉｌｅｓの構成を模式的に示す図である。図１５を参照すると、ＣＭＳサーバ４は、ファイルアクセスサーバ処理部１３と、ＣＭＳサーバ処理部１７と、コンテンツを登録するデータベース１８と、ファイルシステム１４とを備えている。クライアント１は、ファイルアクセスアプリケーション１１と、ファイルアクセスクライアント処理部１２と、ＣＭＳアプリケーション１５と、ＣＭＳクライアント処理部１６とを備えている。クライアント１に対してはファイルサーバと同様に、既存のファイルアクセスアプリケーションが使えるという利点があり、かつＣＭＳの機能も実現できている。

しかし、一般に、ＣＭＳの機能は複雑であり、ファイルサーバと比較すると、読み出し書き込みの動作が遅いため、このような形態では、頻繁にファイルの読み書きを行うアプリケーションの動作には耐えず、ファイルサーバのように汎用的に使用できるものではない。

さらに、一般的なＣＭＳは、ファイルを、多元的な属性と共に管理しており、ユーザは、この多元的な属性に対して、キーワードを指定するなどの操作で、ファイルの検索を行う機能を有している。しかしながら、ＣＭＳの上に、ファイルサーバと互換のインターフェイスを設けただけの製品では、ファイルサーバのプロトコルにしか対応していないアプリケーションからは、ＣＭＳサーバ処理部で管理される、多元的な属性を参照することや、多元的な属性を用いて、ファイルの検索を行うことが出来ない。

すなわち、ファイルの作成や編集を行う環境と、ファイルの管理を行うＣＭＳとを、それぞれ別個のシステムとして構築しなければならず、
・作業の非効率性、
・容量の非効率性、
・ファイルの一貫性維持に対する脆弱性、
などの課題がある。

そして、ファイルサーバとＣＭＳとは、動作が大幅に異なることから、両者を統合することは極めて困難であった。

したがって、本発明の目的は、ファイルサーバとＣＭＳを統合可能とするシステム、方法とプログラムを提供することにある。

本願で開示される発明は、前記課題を解決するため、概略以下の通りの構成とされる。

本発明は、ファイルサーバとＣＭＳを統合させるため、以下のような機能を有するＦＳ−ＣＭＳ連携処理部を備えている。

本発明において、ＦＳ−ＣＭＳ連携処理部は、ファイルシステムへのイベントをモニタして、ＣＭＳに通知する手段と、ＣＭＳが行う処理をファイルシステムに対する操作に翻訳してファイルシステムに対して操作する手段を備える。

また、本発明においては、ＣＭＳの上でのみ管理していた多元的な属性を、ファイルシステムにおけるリンクに対応させ、ファイルサーバのプロトコルにしか対応していないアプリケーションからも使用可能にする。

さらに、本発明においては、検索ディレクトリという機能を設け、ＣＭＳの上でしか使用できなかったファイル検索を、ファイルサーバのプロトコルにしか対応していないアプリケーションからも使用可能としている。

さらにまた、本発明においては、検索ディレクトリからファイルを削除した場合に、ＣＭＳにおける多元的な属性をファイルシステムにおけるリンクに対応させた実装では、リンクが削除されるだけでファイルの実体は削除されないという課題が生じるため、削除イベントを監視する機構や、それに応じてファイルの実体を削除する機構などを設ける。

さらに、本発明においては、一部のアプリケーションの場合、ファイルを変更して保存すると、ファイルシステム上ではファイルの変更ではなく、新規ファイルに置き換わるという動作を行うため、この種のアプリケーションにて検索ディレクトリからファイルを更新すると、ファイルシステムにおけるリンクで表現していたＣＭＳにおける多元的な属性が失われてしまうという課題が生じるのに対し、リンクを再設定する機能を設ける。

本発明の一アスペクト（側面）に係るサーバ装置においては、ファイルシステムへのアクセスを制御するファイルアクセスサーバ処理部と、データベースにてコンテンツを管理するＣＭＳ（Ｃｏｎｔｅｎｔｓ Ｍａｎａｇｅｍeｎｔ Ｓｙｓｔｅｍ）サーバ処理部と、前記ファイルアクセスサーバ処理部による前記ファイルシステムへのファイル操作が行われた場合、前記ファイルシステムへの操作内容を前記ＣＭＳサーバ処理部に通知し、前記操作内容を、前記ＣＭＳサーバ処理部で管理される前記データベースに反映させる制御を行うＦＳ−ＣＭＳ連携処理部と、を備えている。

本発明に係るサーバ装置において、前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルサーバ装置が接続するクライアントのＣＭＳアプリケーションによるファイル操作を、前記ファイルシステムへのファイル操作に変換した上で、前記ファイルシステムに対して操作を行い、さらに、前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルシステムに対して行った前記操作の内容を、前記ＣＭＳサーバ処理部に通知し、前記操作の内容を、前記ＣＭＳサーバ処理部で管理される前記データベースに反映させる制御を行う構成としてもよい。

本発明に係るサーバ装置において、ＣＭＳアプリケーションのメニューページ上でファイル操作を選択するボタンのリンク先が、ＣＭＳアプリケーション本来の対応するページではなく予め用意した別のページに設定され、前記ボタンの選択時、前記別のページに制御が移り、前記ＦＳ−ＣＭＳ連携処理部の対応するファイル操作の処理が実行されるように設定されており、前記ＣＭＳアプリケーションのメニューページ上でファイル操作が選択された場合、前記ＦＳ−ＣＭＳ連携処理部により、前記ファイルシステムへのファイル操作が行われ、さらに、前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルシステムに対して行った前記操作の内容を、前記ＣＭＳサーバ処理部に通知し、前記操作の内容を、前記ＣＭＳサーバ処理部で管理される前記データベースに反映させる制御を行う、構成としてもよい。

本発明に係るサーバ装置において、前記ＦＳ−ＣＭＳ連携処理部は、前記ＣＭＳサーバ処理部のＡＰＩ（アプリケーションインタフェース）をコールすることで、前記ファイルシステムに為された前記操作の内容を、前記ＣＭＳサーバ処理部で管理される前記データベースに反映させる、構成としてもよい。

本発明に係るサーバ装置において、前記データベースが、１行あたり、ファイル名と、分類コードと、ファイルの属性情報の列を少なくとも含み、前記分類コードとして、ファイルの親ディレクトリのパス名を含み、前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルシステムへの操作イベント発生時、前記操作の対象となるパス名とファイル名とを取得し、ファイルの親ディレクトリを分類コードとして、前記ＣＭＳサーバ処理部のＣＭＳのコンテンツ操作用のＡＰＩをコールする、構成としてもよい。

本発明に係るサーバ装置において、前記データベースが、１行あたり、ファイル名と、分類コードと、ファイルの属性情報の列を少なくとも含み、前記ＦＳ−ＣＭＳ連携処理部は、ファイルの親ディレクトリのパス名と分類コードとを対応付ける変換テーブルを含み、前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルシステムへの操作イベント発生時、パス名とファイル名を取得し、親ディレクトリから前記変換テーブルを参照して分類コードを導き、前記ＣＭＳサーバ処理部のＣＭＳのコンテンツ操作用のＡＰＩをコールする、構成としてもよい。

本発明に係るサーバ装置は、ファイルシステムへのアクセスを制御するファイルアクセスサーバ処理部と、データベースにてコンテンツを管理するＣＭＳ（Ｃｏｎｔｅｎｔｓ Ｍａｎａｇｅｍeｎｔ Ｓｙｓｔｅｍ）サーバ処理部と、前記ファイルシステムへの操作イベントが発生した時、前記ＣＭＳサーバ処理部に通知して、前記データベースに反映させ、一方、前記ＣＭＳサーバ処理部が行う処理を、前記ファイルシステムに対する操作に変換して前記ファイルシステムに対して操作するＦＳ−ＣＭＳ連携処理部と、を備えている。

本発明において、前記ＦＳ−ＣＭＳ連携処理部は、クライアントから、前記ファイルシステムへのアクセスを、モニタリングアプリケーションインタフェースを通じて認識し、前記クライアントからのアクセスにより、前記ファイルシステムに変更が加えられると、前記ＦＳ−ＣＭＳ連携処理部は、前記変更内容を、前記ＣＭＳサーバ処理部に通知し、前記ＦＳ−ＣＭＳ連携処理部から前記通知を受けた前記ＣＭＳサーバ処理部では、前記データベースに前記変更内容を反映させ、前記クライアントがＣＭＳアプリケーションを用いてファイルに対する操作を行うと、前記ＦＳ−ＣＭＳ連携処理部を経由して、前記ファイルシステムにアクセスし、前記ＣＭＳサーバ処理部では、前記データベースに、前記変更内容を反映させる、構成としてもよい。

本発明に係るサーバ装置においては、ファイルシステムへのアクセスを制御するファイルアクセスサーバ処理部と、データベースにてコンテンツを管理するＣＭＳサーバ処理部と、前記ファイルシステムと前記ＣＭＳサーバ処理部を連携させるＦＳ−ＣＭＳ連携処理部と、を備え、前記ＦＳ−ＣＭＳ連携処理部は、クライアントから、前記ファイルシステムへのアクセスを、モニタリングアプリケーションインタフェースを通じて認識し、前記クライアントからのアクセスにより、前記ファイルシステムに変更が加えられると、前記ＦＳ−ＣＭＳ連携処理部は、前記変更内容を、前記ＣＭＳサーバ処理部に通知し、前記ＦＳ−ＣＭＳ連携処理部から前記通知を受けた前記ＣＭＳサーバ処理部では、前記データベースに、前記変更内容を反映させ、前記クライアントがＣＭＳアプリケーションを用いて前記ＣＭＳサーバ処理部にアクセスし、ファイルに対する操作を行うと、前記ＣＳＭサーバ処理部から、前記ＦＳ−ＣＭＳ連携処理部を経由して、前記ファイルシステムにアクセスする。

本発明において、前記ＦＳ−ＣＭＳ連携処理部は、前記削除（ＤＥＬＥＴＥ）を契機として、ファイルの拡張属性とリンクを設定しなおすようにしてもよい。

本発明において、前記ＦＳ−ＣＭＳ連携処理部は、前記クライアントからの前記ファイルシステムの検索ディレクトリへのアクセスを、モニタリングアプリケーションインタフェースを通じて認識すると、前記検索ディレクトリ名の示す属性を備えているファイルを、前記ＣＭＳサーバ処理部に問い合わせ、
前記ＣＭＳサーバ処理部は、前記ＦＳ−ＣＭＳ連携処理部からの前記問い合わせを受けて、前記データベースを検索して、前記検索ディレクトリ名の示す属性を備えているファイルのリストを、前記ＦＳ−ＣＭＳ連携処理部に返し、
前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルのリストをもとに、前記ファイルシステムにリンクファイルを作成し、前記検索ディレクトリ名の示す属性をもつファイルが一覧となって見えるようにしてもよい。

本発明において、前記ＦＳ−ＣＭＳ連携処理部が、ＲＥＮＡＭＥ元ファイルとＲＥＮＡＭＥ先ファイルを備えたＲＥＮＡＭＥテーブルと、ＤＥＬＥＴＥイベントを保存するＤＥＬＥＴＥテーブルを備えている。

本発明において、前記ＦＳ−ＣＭＳ連携処理部に、ＲＥＮＡＭＥ元ファイルとＲＥＮＡＭＥ先ファイルを備え、ＲＥＮＡＭＥイベントを保存するＲＥＮＡＭＥテーブルと、ＤＥＬＥＴＥイベントを保存するＤＥＬＥＴＥテーブルを備えている。前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルシステムのファイルが更新されるときには、ＲＥＮＡＭＥテーブルとＤＥＬＥＴＥテーブルを作成し、ＤＥＬＥＴＥイベントのファイルが、ＲＥＮＡＭＥテーブルのＲＥＮＡＭＥ先ファイルにあるかをチェックし、ＤＥＬＥＴＥイベントのファイルが存在した場合、ＲＥＮＡＭＥ元ファイルと同名なファイルがファイルシステム上にあるかをチェックし、ＲＥＮＡＭＥ元ファイルと同名なファイルが前記ファイルシステム上に存在した場合、アプリケーションの更新動作とみなし、拡張属性とリンクを再設定し、ＲＥＮＡＭＥテーブルとＤＥＬＥＴＥテーブルから、前記ファイルに関するエントリを削除する。

本発明に係るクライアント装置は、ファイルアクセスプロトコルと、ＣＭＳアクセスプロトコルで、前記本発明のファイルサーバのファイルアクセスサーバ処理部、ＣＭＳサーバ処理部にアクセスする。

本発明の他のアスペクト（側面）に係る方法は、クライアントからのファイルシステムへのアクセスを制御するファイルアクセスサーバ処理と、データベースにてコンテンツを管理するＣＭＳ（Ｃｏｎｔｅｎｔｓ Ｍａｎａｇｅｍeｎｔ Ｓｙｓｔｅｍ）サーバ処理と、を連携させる方法であって、前記クライアントのファイルアクセスアプリケーションからの前記ファイルシステムへの操作が行われた場合、前記ファイルシステムへの前記操作の内容を前記ＣＭＳサーバ処理に通知し、前記操作の内容を前記ＣＭＳサーバ処理で管理される前記データベースに反映させる制御を行う。本発明は、ファイルシステムへのアクセスを制御するファイルアクセスサーバ処理部と、コンテンツを管理するＣＭＳ（Ｃｏｎｔｅｎｔｓ Ｍａｎａｇｅｍeｎｔ Ｓｙｓｔｅｍ）サーバ処理部と、前記ファイルアクセスサーバ処理部とＣＭＳサーバ処理部を連携するＦＳ−ＣＭＳ連携処理部と、を備えたファイルサーバによる、ＦＳとＣＭＳの連携方法であって、
前記ＦＳ−ＣＭＳ連携処理部が、クライアントからのアクセス要求に基づき、ファイルシステムへのイベントをモニタしてＣＭＳサーバ処理部に通知する工程と、
前記ＦＳ−ＣＭＳ連携処理部が、前記ＣＭＳサーバ処理部が行う処理を、前記ファイルシステムに対する操作に変換してファイルシステムに対して操作する工程と、
を含む。

本発明に係る方法において、前記ＦＳ−ＣＭＳ連携処理部は、前記クライアントからファイルシステムへのアクセスを、モニタリングアプリケーションインタフェースを通じて認識し、前記クライアントからのアクセスにより、前記ファイルシステムに変更が加えられると、その変更内容を、前記ＣＭＳサーバ処理部に通知し、前記ＣＭＳサーバ処理部は、前記データベースにその変更を反映させる工程と、
前記クライアントがＣＭＳアプリケーションを用いて前記ＣＭＳサーバ処理部にアクセスし、ファイルに対する操作を行うと、前記ＣＳＭサーバ処理部から前記ＦＳ−ＣＭＳ連携処理部を経由して前記ファイルシステムにアクセスする工程と、
を含む。

本発明に係る方法において、ＣＭＳで管理される属性を、前記ファイルシステムにおけるリンクに対応させる工程を含み、前記ファイルサーバのプロトコルにしか対応していないアプリケーションからもＣＭＳをアクセス可能としている。

本発明に係る方法において、検索ディレクトリからファイルを削除した場合に、削除イベントを監視し、該削除イベントに応じてファイルの実体を削除する。

本発明に係る方法において、前記ＦＳ−ＣＭＳ連携処理部は、前記ＤＥＬＥＴＥを契機として、前記ファイルの拡張属性とリンクを設定しなおす。

本発明に係る方法において、前記ＦＳ−ＣＭＳ連携処理部は、
ファイルシステムのファイルが更新されるときには、ＲＥＮＡＭＥテーブルとＤＥＬＥＴＥテーブルを作成し、前記ＲＥＮＡＭＥテーブルは、ＲＥＮＡＭＥ元ファイルとＲＥＮＡＭＥ先ファイルを備え、
ＤＥＬＥＴＥイベントのファイルが、ＲＥＮＡＭＥテーブルのＲＥＮＡＭＥ先ファイルにあるかをチェックし、
ＤＥＬＥＴＥイベントのファイルが、ＲＥＮＡＭＥテーブルのＲＥＮＡＭＥ先ファイルに存在した場合、ＲＥＮＡＭＥ元ファイルと同名なファイルがファイルシステム上にあるかをチェックし、
ＲＥＮＡＭＥ元ファイルと同名なファイルがファイルシステム上に存在した場合、アプリケーションの更新動作とみなし、拡張属性とリンクを再設定し、
ＲＥＮＡＭＥテーブルとＤＥＬＥＴＥテーブルからこのファイルに関するエントリを削除する。

本発明の他のアスペクト（側面）に係るプログラムは、
ファイルシステムへのアクセスを制御するファイルアクセスサーバ処理部と、
コンテンツを管理するＣＭＳサーバ処理部と、
ＦＳ−ＣＭＳ連携処理部と、
を備えたファイルサーバのコンピュータに、
前記ＦＳ−ＣＭＳ連携処理部における、
クライアントからのアクセス要求に基づき、ファイルシステムへのイベントをモニタして前記ＣＭＳサーバ処理に通知する処理、
前記ＣＭＳサーバ処理で行う処理を、前記ファイルシステムに対する操作に変換してファイルシステムに対して操作する処理と、
を実行させるプログラムよりなる。

本発明の他のアスペクト（側面）に係るプログラムにおいて、
前記ＦＳ−ＣＭＳ連携処理部が、前記クライアントからファイルシステムへのアクセスを、モニタリングアプリケーションインタフェースを通じて認識し、前記クライアントからのアクセスにより、前記ファイルシステムに変更が加えられると、その変更内容を、前記ＣＭＳサーバ処理部に通知する処理と、
前記ＣＭＳサーバ処理部は、前記データベースにその変更を反映させる処理と、
前記クライアントがＣＭＳアプリケーションを用いて前記ＣＭＳサーバ処理部にアクセスし、ファイルに対する操作を行うと、前記ＣＳＭサーバ処理部から、前記ＦＳ−ＣＭＳ連携処理部を経由して前記ファイルシステムにアクセスする処理と
を前記コンピュータに実行させるプログラムよりなる。

本発明の他のアスペクト（側面）に係るプログラムにおいて、
ＣＭＳで管理される属性を、前記ファイルシステムにおけるリンクに対応させる処理を備え、
ファイルサーバのプロトコルにしか対応していないアプリケーションからもＣＭＳをアクセス可能としてなる、ことを特徴とするプログラムよりなる。

本発明の他のアスペクト（側面）に係るプログラムにおいて、
前記検索ディレクトリからファイルを削除した場合に、削除イベントを監視し、前記削除イベントに応じてファイルの実体を削除する処理を、
を前記コンピュータに実行させるプログラムよりなる。

本発明の他のアスペクト（側面）に係るプログラムにおいて、ＤＥＬＥＴＥを契機として、拡張属性とリンクを設定しなおす、処理を前記コンピュータに実行させるプログラムよりなる。

本発明の他のアスペクト（側面）に係るプログラムにおいて、前記ＦＳ−ＣＭＳ連携処理部が、
前記ファイルシステムのファイルが更新されるときには、ＲＥＮＡＭＥテーブルとＤＥＬＥＴＥテーブルを作成し、
ＤＥＬＥＴＥイベントのファイルが、ＲＥＮＡＭＥテーブルのＲＥＮＡＭＥ先ファイルにあるかをチェックし、
ＤＥＬＥＴＥイベントのファイルが、ＲＥＮＡＭＥテーブルのＲＥＮＡＭＥ先ファイルに存在した場合、ＲＥＮＡＭＥ元ファイルと同名なファイルがファイルシステム上にあるかをチェックし、
ＲＥＮＡＭＥ元ファイルと同名なファイルがファイルシステム上に存在した場合、アプリケーションの更新動作とみなし、拡張属性とリンクを再設定し、
ＲＥＮＡＭＥテーブルとＤＥＬＥＴＥテーブルからこのファイルに関するエントリを削除する処理を前記コンピュータに実行させるプログラムよりなる。

本発明によれば、ＦＳ−ＣＭＳ連携処理部を備え、ファイルサーバに対して行われた操作をＣＭＳに反映し、また、ＣＭＳが行う処理をファイルシステムに対して反映する構成としたことで、ファイルサーバで所望のコンテンツ管理を実現することができる。

本発明によれば、従来はファイルサーバとコンテンツ管理という２つのシステムに分離していたものを統合することで、より簡素で効率的な管理を可能としている。

次に、本発明を実施する最良の形態のシステム構成について図を用いて説明する。図１は、本発明を実施する最良の形態のシステム構成の一例を示す図である。図１を参照すると、この実施形態は、少なくとも１台以上のクライアント１と、少なくとも１台以上のファイルサーバ２とを備えている。クライアント１とファイルサーバ２はネットワーク３で接続されている。

＜ファイルサーバ・ＣＭＳの仕組み＞
はじめに、ファイルサーバとＣＭＳの典型的な構成について、比較例として、図１０を参照して説明しておく。

図１０を参照すると、この比較例において、クライアント１は、ファイルアクセスアプリケーション１１と、ファイルアクセスクライアント処理部１２を備えている。

ファイルサーバ２は、ファイルアクセスサーバ処理部１３と、ファイルシステム１４を備えている。

クライアント１は、ファイルサーバ２にアクセスするときには、ファイルアクセスアプリケーション１１でファイルサーバ２を示すディレクトリを開き、ファイルにアクセスする。

ファイルアクセスアプリケーション１１は、ファイルアクセスクライアント処理部１２に処理を依頼する。

ファイルアクセスクライアント処理部１２は、ファイルアクセスプロトコル２１を介してファイルアクセスサーバ処理部１３と通信を行い、ファイル情報の獲得やファイルデータのＲＥＡＤ／ＷＲＩＴＥを行う。

ファイルサーバ２の内部において、ファイルアクセスサーバ処理部１３は、クライアント１のリクエストに応じてファイルシステム１４にアクセスし、ファイルシステム１４からの応答を、ファイルアクセスプロトコル２１に変換して、クライアント１に返すという処理を行う。

図１０に示すように、ＣＭＳサーバ４は、ファイルサーバ２とは別に設けられている。クライアント１は、ＣＭＳサーバ４への処理依頼を行うため、ＣＭＳアプリケーション１５とＣＭＳクライアント処理部１６を備えている。

ＣＭＳサーバ４は、ＣＭＳサーバ処理部１７と、データベース１８と、ファイルシステム１４を備えている。

典型的なＣＭＳにおいて、ファイルをＲＥＡＤ／ＷＲＩＴＥする方法は、ファイルサーバ２の場合とは異なる。

クライアント１上で動作するＣＭＳアプリケーション１５に、ファイルアップロードの類のメニューページが設けられており、該メニュー上からの操作で、ファイルをアップロードし、該メニューで、多元的な属性を設定する。

つまり、ユーザは、ファイルサーバ２上にファイルを作成し、コンテンツ管理を行うために、ＣＭＳアプリケーション１５のメニューの操作により、当該ファイルをＣＭＳサーバ４にアップロードするという作業が必要になる。

＜第１の実施形態＞
図２は、本発明の第１の実施形態の構成を示す図である。図２を参照すると、本実施形態において、ファイルサーバ２は、ファイルアクセスサーバ処理部１３と、ファイルシステム１４と、ＦＳ（File System）−ＣＭＳ（Contents Management System）連携処理部１９と、ＣＭＳサーバ処理部１７と、データベース１８を備えている。クライアント１は、ファイルアクセスアプリケーション１１と、ファイルアクセスクライアント処理部１２と、ＣＭＳアプリケーション１５と、ＣＭＳクライアント処理部１６を備えている。なお、クライアント１の構成は、図１０の構成と同一である。ファイルサーバ２における、ファイルアクセスサーバ処理部１３、ＣＭＳサーバ処理部１７、ＦＳ−ＣＭＳ連携処理部１９の各処理部は、ファイルサーバ２を構成するコンピュータで実行されるプログラムによって処理、機能を実現してもよいことは勿論である。本実施の形態では、ファイルサーバ２に、ＦＳ−ＣＭＳ連携処理部１９を導入している。以下、ＦＳ−ＣＭＳ連携処理部１９の動作について説明する。

クライアント１がファイルアクセスアプリケーション１１を用いて、ファイルシステム１４にアクセスすると、ＦＳ−ＣＭＳ連携処理部１９は、イベントを検出するモニタリングＡＰＩ（アプリケーションインタフェース）２４を通じて、ファイルシステム１４へのアクセスを検出する。

モニタリングＡＰＩ２４は、さまざまな実装があるが、例えばデータ管理アプリケーションインタフェース（ＤＭＡＰＩ）が用いられる（ＤＭＡＰＩが有効化される）。ＤＭＡＰＩは、ファイルシステム１４に対して起きたイベントを受け取ることができるＡＰＩである。また、ＦＣＴＲＬのＮＯＴＩＦＹ機能を用いてもよい。

ＤＭＡＰＩの機能について、図１１を参照して概説する。ＤＭＡＰＩは、予めカーネルに登録した領域に対してアクセスがあると、アプリケーションに通知を行うＡＰＩ（アプリケーションインタフェース）である。

ＤＭＡＰＩアプリケーション２０（ＤＭＡＰＩを利用するユーザ空間アプリケーション）は、ファイルシステム１４に対して、場所とイベントを登録する（１）。

ここで、場所とは、イベントが発生したら通知をあげるディレクトリやファイルを指定する。なお、場所として、ファイルシステム全体を指定することも可能である。

イベントでは、通知をあげる操作を指定する。

登録されるイベントは、例えば
・ファイル作成（ＣＲＥＡＴＥ）、
・ファイル削除（ＤＥＬＥＴＥ）、
・ＯＰＥＮ、
・ＣＬＯＳＥ、
・ＲＥＡＤ、
・ＷＲＩＴＥ、
・ＲＥＮＡＭＥ、
・ＬＩＮＫ、・・・
など、ファイルシステムＡＰＩのほとんどが指定可能である。

図１１に示す例では、ＤＭＡＰＩアプリケーション２０は、場所：ディレクトリＡ、イベント：ＣＲＥＡＴＥを登録する。

この場合、ファイルシステム１４のディレクトリＡに、クライアント１がファイルＸを作成したときに（２）、ＤＭＡＰＩアプリケーション２０に対して、ディレクトリＡにファイルＸが作成されたことが通知される（３）。

再び、図２を参照すると、クライアント１のアクセスにより、ファイルシステム１４に変更が加えられると、ＦＳ−ＣＭＳ連携処理部１９は、その変更を、ＣＭＳサーバ処理部１７に通知する。ＣＭＳサーバ処理部１７は、データベース１８にその変更を反映させる。

また、クライアント１がＣＭＳアプリケーション１５を用いてＣＭＳサーバ処理部１７にアクセスし、ファイルに対する操作を行うと、ＣＳＭサーバ処理部１７から、ＦＳ−ＣＭＳ連携処理部１９を経由してファイルシステム１４にアクセスする。

これらの機能により、ファイルサーバとＣＭＳとで、ファイルの一貫性を保つことができる。

なお、ＣＭＳのデータベース１８の内容は、ＣＭＳによって異なるが、その基本は、ディレクトリの階層構造に相当する分類コードと、ファイル属性とが列になり、ファイルが行になっている。図１２に、ＣＭＳデータベースの一例を示す。図１２に示す例では、ファイル毎（行毎）に、ファイル名、分類コード、シリアルＩＤ、リビジョン、最終更新時刻、属性の各列がある。また、図１２に示す例では、分類コードは、ディレクトリと同じイメージである。このように、分類コードをディレクトリ階層構造と同じとすることで、ディレクトリと分類コードの相互の変換が不要となる。なお、分類コードとディレクトリ構造とを別にして、ＦＳ−ＣＭＳ連携処理部１９に変換テーブルを備えた構成としてもよい。

図２に示した本実施形態において、クライアント１のファイルアクセスにより、ファイルシステム１４に変更が加えられたときの動作を以下に説明する。

図１３は、本実施形態において、ファイルシステム１４に新規にファイルを作成した場合の処理を説明するためのフローチャートである。

クライアント１のファイルアクセスにより、ファイルシステム１４に新規にファイルを作成した場合、ＤＭＡＰＩを通じて、ＦＳ−ＣＭＳ連携処理部１９にファイルを新規に作成したファイルの親ディレクトリのパス名とファイル名が渡される（ＳＴＥＰ１）。

次に、ＦＳ−ＣＭＳ連携処理部１９で、分類コードを見つける（ＳＴＥＰ２）。

本実施形態においては、図１２を参照して説明したように、分類コードをディレクトリと同一とすることで、ＦＳ−ＣＭＳ連携処理部１９では、ＤＭＡＰＩから通知されたファイルの親ディレクトリのパス名から、容易に分類コードを導くことができる。なお、本発明は、分類コードをディレクトリと同一とする構成に限定されるものでなく、前述したように、分類コードとディレクトリを別にしてもよいことは勿論である。この場合、ＦＳ−ＣＭＳ連携処理部１９では、親ディレクトリのパス名から変換テーブルを引いて（検索して）、分類コードを導くなどして、分類コードを見つける必要がある。特に制限されないが、親ディレクトリのパス名と分類コードとの対応をテーブル形式で格納した変換テーブルは、ＦＳ−ＣＭＳ連携処理部１９内に備えてもよい。

次に、ＦＳ−ＣＭＳ連携処理部１９は、ＣＭＳサーバ処理部１７のＡＰＩをコールして、ファイルの新規登録を行う（ＳＴＥＰ３）。データベース１８には、新規ファイルに対応した、ファイル名、分類コード、シリアルＩＤ、リビジョン、最終更新時刻、属性の列が新規登録される。一般に、ＣＭＳには、外部プログラムからコンテンツを操作するためのＡＰＩが用意されている。本実施形態では、ＦＳ−ＣＭＳ連携処理部１９は、このＡＰＩを利用する。

次に、ファイルシステム１４に対するファイル操作が削除である場合を説明する。クライアント１のファイルアクセスにより、ファイルアクセスサーバ処理部１３により、ファイルシステム１４内のファイルを削除した場合には、ファイルの新規作成の場合と同様に、ＦＳ−ＣＭＳ連携処理部１９には、ＤＭＡＰＩ経由で、削除したファイルの親ディレクトリとファイル名が渡される。

ＦＳ−ＣＭＳ連携処理部１９では、親ディレクトリパス名から、分類コードを導き、ファイル名と同一のコンテンツを削除する。ファイルの削除は、ＣＭＳサーバ処理部１７のＡＰＩを利用する。この場合、例えば、データベース１８から当該ファイル名の行が削除される。

次に、ファイルシステム１４のファイルの更新について説明する。クライアント１のファイルアクセスにより、ファイルアクセスサーバ処理部１３により、ファイルの更新が行われた場合、ファイルの新規作成や削除の場合とは異なり、ファイルの最終更新時刻が変わるだけである。ＦＳ−ＣＭＳ連携処理部１９には、ＤＭＡＰＩ経由で、ファイルのパス名が渡される。ＦＳ−ＣＭＳ連携処理部１９は、ファイルパス名から分類コードを導き、最終更新時刻を変更するために、ＣＭＳサーバ処理部１７のＡＰＩをコールする。この場合、データベース１８の当該ファイル名、分類コードに対応する行の、最終更新時刻の列が変更される。

次に、クライアント１がＣＭＳアプリケーション１５を用いてファイルに変更を加えたときの動作を説明する。

まず、新規にファイルを作成した場合、クライアント１は、ＣＭＳアプリケーション１５経由で、ファイルをアップロードする。その際、ファイルのアップロード先が、図２のファイルシステム１４内となるように、事前に設定しておく。

本実施形態においては、クライアント１が、ＣＭＳサーバ上のフォルダで、ファイルをアップロードするだけで、自動的に、ファイルサーバ２のファイルシステム１４内の対応するディレクトリに、該ファイルがアップロードされる。すなわち、比較例として示した図１０の構成の場合、クライアント１は、ＣＭＳアプリケーション１５の操作により、ＣＭＳサーバ４上のフォルダで、ファイルをアップロードすると、ＣＭＳサーバ４のファイルシステム１４内にファイルを新規作成することになるが、本実施形態では、図２のファイルサーバ２のファイルシステム１４内にファイルが新規作成されるように、アップロード先が設定されている。

なお、ＣＭＳサーバがファイルのアップロード先を設定（変更）できない構成の場合や、ファイルの作成操作によりデータベース内部にファイルを格納してしまう場合には、別の方法をとる必要がある。その手法について、図１４を参照して説明する。

まず、ＣＭＳサーバ（図１０の４）で、新規ファイルを登録するためのページ（ＣＭＳメニューページ）を、ＦＳ−ＣＭＳ連携処理部１９にアクセスするＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）とし、ボタンの選択により、独自に設けた新規登録ページに飛ぶように予め設定しておく。これは、ＣＭＳメニューページの新規ファイル登録のリンクを書き換えるだけで済むことから、変更は容易である。具体的には、ＣＭＳメニューページの新規登録ボタン６１のリンク先を、独自の新規登録ページ７１（ＵＲＬ）に設定しておく。クライアント１において、ＣＭＳアプリケーション１５のＣＭＳメニューページの新規登録ボタン６１が選択されると、リンク先の新規登録ページ７１が表示され、新規登録ページ７１上でファイルをアップロードすると、ファイルサーバ２のＦＳ−ＣＭＳ連携処理部１９の対応する処理に移行する。

ＦＳ−ＣＭＳ連携処理部１９では、新規登録ページ７１でアップロードされたファイルをファイルシステム１４に格納し、ファイルシステム１４へのファイルの新規作成に対応してＣＭＳサーバ処理部１７に対して、前述したＣＭＳのＡＰＩをコールして、ＣＭＳのデータベース１８に対して、新規ファイルの登録を行う。なお、ＣＭＳサーバ処理部１７に対する処理は、ファイルアクセスサーバ処理部１３からファイルシステム１４に新規ファイルを作成した場合にＦＳ−ＣＭＳ連携処理部１９がＣＭＳサーバ処理部１７に対して行う処理と同じである。

次に、クライアント１で動作するＣＭＳアプリケーション１５からのファイル削除操作について、図１４を参照して説明する。ＣＭＳアプリケーション１５のメニューページからファイルシステム１４のファイルを削除する場合も、同様にして、削除ボタン６２から、独自の削除ページ７２へリンクするようにしておく。これにより、ＦＳ−ＣＭＳ連携処理部１９に対して、最初に、ファイルの削除が通知され、ＦＳ−ＣＭＳ連携処理部１９は、ファイルシステム１４から該当するファイルの削除を行い、つづいて、ＣＭＳサーバ処理部１７に対して、前述したＣＭＳサーバ処理部１７のＡＰＩをコールして、データベース１８の対応する行の内容を削除する。これにより、ファイルシステムとＣＭＳの連携をとることができる。

ＣＭＳアプリケーション１５のメニューページからファイルシステム１４のファイルを更新する場合も、更新ボタン６３から独自の更新ページ７３へリンクするようにしておく。

これにより、ＦＳ−ＣＭＳ連携処理部１９に対して、最初に、更新が通知され、ＦＳ−ＣＭＳ連携処理部１９は、ファイルシステム１４において、ファイルの更新を行い、つづいて、ＣＭＳサーバ処理部１７に対して、前述したＣＭＳのＡＰＩをコールして、ＣＭＳのデータベース１８の対応する行において、更新情報を設定する。これにより、ファイルシステムとＣＭＳの連携をとることができる。

なお、図２のＣＭＳのデータベース１８に対して、クライアント１のＣＭＳアプリケーション１５、ＣＭＳクライアント処理部１６、ＣＭＳアクセスプロトコル２３、ＣＭＳサーバ処理部１７を介して、ＣＭＳのデータベース１８の内容に変更が為され、ファイルシステム１４に変更内容を反映する必要がある場合、ＣＭＳサーバ処理部１７が、ＦＳ−ＣＭＳ連携処理部１９に通知し、ＦＳ−ＣＭＳ連携処理部１９にてファイルシステム１４へのファイル操作を行うようにしてもよいことは勿論である。例えば、ＣＭＳのデータベース１８（図１２）内のある行（エントリ）を削除する場合、削除対象の行のファイル名と分類コードのパス名（親ディレイトリ）をＦＳ−ＣＭＳ連携処理部１９に通知し、ＦＳ−ＣＭＳ連携処理部１９がファイルシステム１４内の該当ファイルの削除操作を行うようにしてもよい。すなわち、ＣＭＳ側からファイルシステム側への連携を行うことができる。ファイルのＲＥＮＡＭＥ等も、同様にして行うことができる。

＜第２の実施形態＞
次に、本発明の第２の実施形態について説明する。本実施形態では、ＣＭＳの検索機能を、ファイルシステムとして実現する。ＣＭＳには、多元的な属性やファイル同士の関連性を把握し、ユーザに対して整理して提示したり、ストレージ管理に利用したり、関連性を提示したりする機能が必要である。

本実施形態では、ファイルサーバ上でその機能を実現するために、検索ディレクトリを用いる。

まず、検索ディレクトリの機能について説明し、つづいて検索ディレクトリを実現するために、図２のＦＳ−ＣＭＳ連携処理部１９がどのような動作をするかについて説明する。

検索ディレクトリは、多元的な属性、またはその組み合わせがディレクトリ名となっており、そのディレクトリを開くと、その属性が付与されているファイルが一覧となって見えるものである。

通常のディレクトリと同じように見えるため、クライアント１は、ファイルアクセスアプリケーション１１を介してアクセスでき、また更新も可能である。

検索ディレクトリは、図２のファイルアクセスアプリケーション１１でアクセスできるので、ＣＭＳクライアント処理部１６を導入していないクライアント１でも、アクセスが可能となる。図３を参照して、具体的に説明する。図３は、本発明の第２の実施形態を説明するための図であり、検索ディレクトリのリンク構成が模式的に示されている。

ディレクトリＡ（３１）にファイルＸ（３４）が置かれており、「開発情報」と「機密」という２つの属性３７が付与されている。

検索ディレクトリ「開発情報」（３２）と検索ディレクトリ「機密」（３３）がファイルシステム１４に作成される。

検索ディレクトリ「開発情報」（３２）にリンクファイルＸ１（３５）が置かれ、検索ディレクトリ「機密」（３３）にはリンクファイルＸ２（３６）が置かれている。

これらのリンクファイルは、ハードリンクまたはシンボリックリンクで、ファイルＸ（３４）にリンクされている。つまり、これらのファイルを開く（「ＯＰＥＮ」する）と、ファイルＸ（３４）が開く。

クライアント１は、例えば「開発情報」という属性のついたファイル、あるいは、「機密」という属性のついたファイルを探す場合、検索ディレクトリ「開発情報」（３２）や、検索ディレクトリ「機密」（３３）を開くことで、簡単に見つけることができる。

このような検索ディレクトリを、ＦＳ−ＣＭＳ連携処理部１９がどのように実現しているかについて以下に説明する。

まず、ファイルシステム１４に、検索ディレクトリを作成する。

検索ディレクトリの作成については、
・ＦＳ−ＣＭＳ連携処理部１９が自動で作成してもよいし、
・クライアント１からＣＭＳクライアント処理部１６を通じて作成を指示するようにしてもよい。

クライアント１が検索ディレクトリにアクセスしてきたら、ＦＳ−ＣＭＳ連携処理部１９は、モニタリングＡＰＩ２４を通じて、検索ディレクトリのアクセスを検出する。

モニタリングＡＰＩ２４が、クライアントによる検索ディレクトリのアクセスを検出したら、ＦＳ−ＣＭＳ連携処理部１９は、その検索ディレクトリ名の示す属性を備えているファイルを、ＣＭＳサーバ処理部１７に問い合わせる。

ＣＭＳサーバ処理部１７は、データベース１８を検索して、該当するファイルリストをＦＳ−ＣＭＳ連携処理部１９に返す。

該当するファイルリストをもとに、ＦＳ−ＣＭＳ連携処理部１９は、ファイルシステム１４に、リンクファイルを作成する。このリンクは、ハードリンクであってもシンボリックリンクであってもよい。これにより、検索ディレクトリに、その属性をもつファイルのリストが見えるようになる。

このように、検索ディレクトリを作ると、１つのファイルに対して、ファイルシステム１４内で複数のリンクファイルが作成される。

通常のファイルシステム１４では、ファイルが削除されたときに、そのファイルにリンクしているリンクファイルは削除されない。つまり、ファイル自体が削除されても、検索ディレクトリからは削除されないことになってしまう。

そして、削除されたファイルにアクセスしたときの現象は、ハードリンクとシンボリックリンクの場合で異なる。

例えばハードリンクの場合、ファイルの削除操作により、ファイルのリンクカウンタが１つ減るだけで、ファイル実体はファイルシステム１４から削除されない。ファイルシステム１４では、リンクカウンタが「０」になったら、ファイル実体が削除される。つまり、検索ディレクトリから、ファイルをアクセスすると、ファイル実体にアクセスできてしまう。つまり、ファイルを削除したのに、アクセスできてしまうというおかしな現象になる。

一方、シンボリックリンクの場合、リンクカウンタは「１」のままであるため、ファイルの削除動作により、ファイルシステム１４から、ファイル実体が削除される。この削除の実行に対して、すでに、ファイル自体は削除されているので、アクセスしたときに、ファイルが存在しないというエラーがでる。

つまり、ファイル実体は存在しないのに、検索ディレクトリからは、該ファイルは削除されない、という、おかしな現象になる。

この問題を解決するため、ＦＳ−ＣＭＳ連携処理部１９は、モニタリングＡＰＩ２４を通じて、ファイルが削除されたことを受けとったら、削除されたファイルにリンクしているリンクファイルを、ＣＭＳサーバ処理部１７に問い合わせる。

ＣＭＳサーバ処理部１７は、データベース１８を検索し、リンクしているファイルの情報をＦＳ−ＣＭＳ連携処理部１９に返す。

ＦＳ−ＣＭＳ連携処理部１９は、それに基づいて、ファイルシステム１４上のリンクファイルを削除する。

ファイルシステム１４がゴミ箱フォルダ機能を備えている場合には、削除要求を受けたファイルはいきなり削除されるのではなく、ファイルシステム１４上でゴミ箱フォルダへ移動される。

その場合は、ＦＳ−ＣＭＳ連携処理部１９は、削除イベントではなく、ゴミ箱フォルダへの移動（ＲＥＮＡＭＥ）というイベントを受け取る。

ＦＳ−ＣＭＳ連携処理部１９は、ゴミ箱フォルダへの移動を削除イベントと同じように扱い、リンクファイルを削除する。

検索ディレクトリ内のファイルは、通常のファイルアクセスアプリケーション１１からアクセス可能であり、更新も可能である。ファイルの内容を変更しても、属性は変化しないし、検索ディレクトリのリンクファイルもつながった状態で保持される。

ただし、一部のアプリケーションでファイルを変更して保存すると、ファイルシステム１４上では、ファイルの変更ではなく、新規ファイルに置き換わる場合がある。

これは、アプリケーションの更新の途中でシステムが止まってしまった場合などには元の状態に戻れるようにするために、アプリケーションが行っている工夫である。

ファイル自体に、上書き変更していくのではなく、別のファイルに変更を含めて、全てＷＲＩＴＥし、最終的に保存するときには、元ファイルの削除と、新規ファイルのファイル名変更（ＲＥＮＡＭＥ）を行う。こうすることにより、ファイル名変更というアトミックな処理で更新ができるため、更新の途中状態というステータスが無くなるのである。

この動作のフローは、２つのタイプ（タイプＡ、タイプＢ）に分類できる。それぞれについて図４、及び図５を用いて説明する。

まず、タイプＡについて図４を用いて説明する。図４は、ファイルＡ（４１）を更新する場合のフローを示している。

まず、ファイルＡ（４１）は、「〜ファイルＡ２．ｔｍｐ」（４２）にＲＥＮＡＭＥされる（ＳＴＥＰ１）。これは更新前のファイルのバックアップという意味がある。

更新を加えたファイルは、「〜ファイルＡ１．ｔｍｐ」（４３）という名前で、新規にＣＲＥＡＴＥ（作成）され、更新内容を含めてＷＲＩＴＥ(書き込み)される（ＳＴＥＰ２）。

すべてＷＲＩＴＥされたら、元のファイルＡ（４１）にＲＥＮＡＭＥされる（ＳＴＥＰ３）。

最後にバックアップファイルである「〜ファイルＡ２．ｔｍｐ」（４２）がＤＥＬＥＴＥ（削除）される（ＳＴＥＰ４）。

この一連の動作により、途中のどの段階で止まってしまったとしても、バックアップに戻ることが可能とされ、更新途中であったことを検出することもできる。

次に、タイプＢについて、図５を用いて説明する。タイプＢの場合、ファイルＡ（４１）は、「〜ファイルＡ．ｂａｋ」（４２）にＲＥＮＡＭＥされ（ＳＴＥＰ１）、更新を加えた新規ファイルが、はじめからファイルＡ（４１）として、ＣＲＥＡＴＥされ、ＷＲＩＴＥされる（ＳＴＥＰ２）。

その後、「〜ファイルＡ．ｂａｋ」が削除される。

この場合も、バックアップ用テンポラリファイル「〜ファイルＡ．ｂａｋ」（４２）が存在するため、更新途中で止まってしまっても、戻ることができる。

しかし、検索ディレクトリにとっては、タイプＡにしてもタイプＢにしても、このような更新は都合が悪い。

まず、ファイルシステム１４としては、別のファイルになってしまうため、多元的な属性をファイルシステムの拡張属性に保存している場合には、失われてしまう。

また、検索ディレクトリのリンクは、シンボリックリンクであれば、ファイル名でつながっているので保持されるが、ハードリンクは切れてしまう。

ファイルシステム１４として、別のファイルであるため仕方ないとも言えるが、ユーザにとっては更新であることからすると、コンテンツ管理システムとしては、利便性が損なわれてしまう。

そこで、この問題を、本実施形態のＦＳ−ＣＭＳ連携処理部１９を用いて、どのように解決しているか、以下に説明する。

アプリケーションがファイル４１を更新する際の動作では、必ず、ファイル４１がバックアップ用テンポラリファイル４２にＲＥＮＡＭＥされ（ＳＴＥＰ１）、最後にバックアップ用テンポラリファイル４２がＤＥＬＥＴＥされる（ＳＴＥＰ３またはＳＴＥＰ４）。

更新フローの最後は、ＤＥＬＥＴＥであり、これをきっかけとして、拡張属性とリンクを設定しなおすのがよい。

そのために、ＦＳ−ＣＭＳ連携処理部１９に、ＲＥＮＡＭＥイベントを保存するＲＥＮＡＭＥテーブル５１と、ＤＥＬＥＴＥイベントを保存するＤＥＬＥＴＥテーブル５２を持つ。

これらのイベントを保存して参照することで、アプリケーションの更新を検出する。

具体的には、図４のタイプＡのフローでファイルＡが更新されるときには、図６（Ａ）、図６（Ｂ）のＲＥＮＡＭＥテーブル５１とＤＥＬＥＴＥテーブル５２が作成される。ＲＥＮＡＭＥテーブル５１は、ＲＥＮＡＭＥ元ファイルとＲＥＮＡＭＥ先ファイル、属性欄を備える。ＤＥＬＥＴＥテーブル５２は、ＣＲＥＡＴＥファイルを有する。

図５のタイプＢのフローでファイルＡが更新されるときは、図７（Ａ）、（Ｂ）のＲＥＮＡＭＥテーブル５１、ＤＥＬＥＴＥテーブル５２ができる。

図８は、本実施形態の処理手順を示す流れ図である。図８を参照して、本実施形態の処理を説明する。

まず、ＤＥＬＥＴＥイベント発生で処理がスタートする（ＳＴＥＰ０）。

ＤＥＬＥＴＥイベントのファイルが、ＲＥＮＡＭＥテーブル５１のＲＥＮＡＭＥ先ファイルに存在するかをチェックする（ＳＴＥＰ１）。

ＤＥＬＥＴＥイベントのファイルが、ＲＥＮＡＭＥテーブル５１のＲＥＮＡＭＥ先ファイルに存在した場合、ＲＥＮＡＭＥ元ファイルと同名なファイルがファイルシステム上にあるかをチェックする（ＳＴＥＰ２）。

ＲＥＮＡＭＥ元ファイルと同名なファイルがファイルシステム上に存在した場合には、アプリケーションの更新動作とみなし、拡張属性とリンクを再設定する（ＳＴＥＰ３）。

最後に、ＲＥＮＡＭＥテーブル５１とＤＥＬＥＴＥテーブル５２から、該ファイルに関するエントリを削除する（ＳＴＥＰ４）。これは、該ファイルのエントリの削除を行わないと、ＲＥＮＡＭＥテーブル５１とＤＥＬＥＴＥテーブル５２が際限なく大きくなるためである。

ファイルシステム１４が、ゴミ箱フォルダ機能を備えている場合には、更新時の元ファイルはゴミ箱フォルダに移動する。つまり、ＤＥＬＥＴＥテーブル５２がＲＥＮＡＭＥテーブル５１で代替可能となる。

図９（Ａ）、図９（Ｂ）に、タイプＡとタイプＢの場合のＲＥＮＡＭＥテーブル５１をそれぞれ示す。

ゴミ箱フォルダへのＲＥＮＡＭＥイベントを受け取ったら、ＲＥＮＡＭＥテーブル５１を参照して、元ファイル名を割り出す。

そして、ファイルシステム上に、ＲＥＮＡＭＥ元ファイルと同名のファイルが存在すれば、ゴミ箱フォルダのファイルから、拡張属性やリンクを引き継ぐ。

あるいは、スナップショットを利用して定期的に再設定するようにしてもよい。例えば夜間などのアクセスがない時間帯にリンクを総チェックする。

リンク切れの復旧のために、スナップショットを利用する。リンク切れのファイルは、現在のファイルシステム１４からは削除されているが、スナップショットをとっている場合には、スナップショット領域には、残っている。よって、スナップショット領域のファイルにアクセスし、それが、現在のファイルシステム１４にも存在するか否かをチェックすることで、リンク切れを検出することができる。

もし、スナップショット領域のファイルと、現在のファイルシステム上のファイルとが同一であれば、リンクはつながっており、異っていれば、更新されたことを意味する。

これは、例えばｉｎｏｄｅ番号（データ領域を確保するための番号）を比較したり、更新時刻を比較したりすることで、可能である。

更新されている場合、スナップショット領域のファイルから、拡張属性を読みこんで、更新後のファイルに設定し、リンクは張り直す。

リンク切れの総チェックを行うときに、予めＲＥＮＡＭＥイベントを受けていれば、そのファイルだけをチェックする、もしくは、何らかの機能により更新されたファイル一覧を獲得できれば、それだけをチェックすることも可能である。これにより、チェックにかかる時間を短縮できる。

上記した本実施形態によれば、ファイルサーバとコンテンツ管理システムという２つのシステムを統合することができ、管理の簡素化、効率化ができる。ファイルサーバでファイル管理をしているところにコンテンツ管理システムを導入すると、従来は二重管理になってしまうために避けるところが多かった。本発明によれば、ファイルサーバを残しつつコンテンツ管理システムを組み込むことができ、導入障壁が低くなる。

なお、前記ＦＳ−ＣＭＳ連携処理部１９における、ファイルシステム１４への操作イベントの認識は、ポーリング方式、あるいは、イベント発生が割り込み等で通知される方式等、任意の方式で行ってもよい。

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

本発明の一実施形態のシステム構成を示す図である。 本発明の一実施形態の機能構成を示す図である。 本発明の検索ディレクトリのリンク構成を模式的に示す図である。 アプリケーションがファイルを更新するフローを示す図である。 アプリケーションがファイルを更新するフローを示す図である。 （Ａ）、（Ｂ）は、本発明の第２の実施形態におけるＲＥＮＡＭＥテーブル・ＤＥＬＥＴＥテーブルをそれぞれ示す図である。 （Ａ）、（Ｂ）は、本発明の第２の実施形態におけるＲＥＮＡＭＥテーブル・ＤＥＬＥＴＥテーブルを示す図である。 本発明の第２の実施形態における拡張属性・リンクの再設定フローを示す図である。 （Ａ）、（Ｂ）は、本発明の第２の実施形態におけるＲＥＮＡＭＥテーブルとＤＥＬＥＴＥテーブルをそれぞれ示す図である。 比較例のファイルサーバとＣＭＳの機能構成を示す図である。 ＤＭＡＰＩの動作を説明する図である。 ＣＭＳデータベースの構成の一例を説明する図である。 ファイルシステムに新規ファイル作成したときのフローを示す図である。 ＣＭＳからファイル操作したときの構成を示す図である。 従来のＯｒａｃｌｅ Ｆｉｌｅｓの構成を示す図である。

符号の説明

１ クライアント
２ ファイルサーバ
３ ネットワーク
４ ＣＭＳサーバ
１１ ファイルアクセスアプリケーション
１２ ファイルアクセスクライアント処理部
１３ ファイルアクセスサーバ処理部
１４ ファイルシステム
１５ ＣＭＳアプリケーション
１６ ＣＭＳクライアント処理部
１７ ＣＭＳサーバ処理部
１８ データベース
１９ ＦＳ−ＣＭＳ連携処理部
２０ ＤＭＡＰＩアプリケーション
２１ ファイルアクセスプロトコル
２２ ファイルシステムＡＰＩ
２３ ＣＭＳアクセスプロトコル
２４ モニタリングＡＰＩ
３１ ディレクトリＡ
３２ 検索ディレクトリ
３３ 検索ディレクトリ
３４ ファイルＸ
３５ リンクファイルＸ１
３６ リンクファイルＸ２
３７ 属性
４１ ファイルＡ
４２ バックアップ用テンポラリファイル
４３ 更新用テンポラリファイル
５１ ＲＥＮＡＭＥテーブル
５２ ＤＥＬＥＴＥテーブル
６１ 新規登録ボタン
６２ 削除ボタン
６３ 更新ボタン
７１ 新規登録ページ
７２ 削除ページ
７３ 更新ページ

Claims (19)

1. ファイルシステムへのアクセスを制御するファイルアクセスサーバ処理部と、
   データベースにてコンテンツを管理するＣＭＳ（Ｃｏｎｔｅｎｔｓ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）サーバ処理部と、
   前記ファイルアクセスサーバ処理部による前記ファイルシステムへのファイル操作が行われた場合、前記ファイルシステムへの操作内容を前記ＣＭＳサーバ処理部に通知し、前記操作内容を、前記ＣＭＳサーバ処理部で管理される前記データベースに反映させ、前記ＣＭＳサーバ処理部が行う処理を、前記ファイルシステムに対する操作に変換して前記ファイルシステムに対して操作する制御を行うＦＳ−ＣＭＳ連携処理部と、
   を備え、
   前記ＦＳ−ＣＭＳ連携処理部は、ファイルサーバ装置が接続するクライアントのＣＭＳアプリケーションによるファイル操作を前記ファイルシステムへのファイル操作に変換した上で前記ファイルシステムに対して操作を行い、
   前記ファイルシステムに対する前記操作の内容を、前記ＣＭＳサーバ処理部に通知し、前記操作の内容を、前記ＣＭＳサーバ処理部で管理される前記データベースに反映させる制御を行う、ことを特徴とするファイルサーバ装置。
2. 請求項１記載のファイルサーバ装置において、
   前記ファイルサーバ装置が接続するクライアントで実行されるＣＭＳアプリケーションのメニューページ上のファイル操作を選択するボタンのリンク先が、ＣＭＳアプリケーション本来の対応するページではなく、予め用意した別のページに設定され、前記ボタンの選択時、前記別のページに制御が移り、前記ＦＳ−ＣＭＳ連携処理部の対応するファイル操作の処理が実行されるように設定されており、
   前記ＣＭＳアプリケーションのメニューページ上でファイル操作がなされた場合、前記ＦＳ−ＣＭＳ連携処理部により、前記ファイルシステムへのファイル操作が行われ、
   さらに、前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルシステムに対して行った前記操作の内容を、前記ＣＭＳサーバ処理部に通知し、前記操作の内容を、前記ＣＭＳサーバ処理部で管理される前記データベースに反映させる制御を行う、ことを特徴とするファイルサーバ装置。
3. 前記ＦＳ−ＣＭＳ連携処理部は、前記ＣＭＳサーバ処理部のＡＰＩ（アプリケーションインタフェース）をコールすることで、前記ファイルシステムに為された前記操作の内容を、前記ＣＭＳサーバ処理部で管理される前記データベースに反映させる、ことを特徴とする請求項１又は２に記載のファイルサーバ装置。
4. 前記データベースが、１行あたり、ファイル名と、分類コードと、ファイルの属性情報の列を少なくとも含み、
   前記分類コードとして、ファイルの親ディレクトリのパス名を含み、
   前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルシステムへの操作イベント発生時、前記操作の対象となるパス名とファイル名とを取得し、
   ファイルの親ディレクトリを分類コードとして、前記ＣＭＳサーバ処理部のＣＭＳのコンテンツ操作用のＡＰＩをコールする、ことを特徴とする請求項３記載のファイルサーバ装置。
5. 前記データベースが、１行あたり、ファイル名と、分類コードと、ファイルの属性情報の列を少なくとも含み、
   前記ＦＳ−ＣＭＳ連携処理部は、ファイルの親ディレクトリのパス名と分類コードとを対応付ける変換テーブルを含み、
   前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルシステムへの操作イベント発生時、パス名とファイル名を取得し、親ディレクトリから前記変換テーブルを参照して分類コードを導き、
   前記ＣＭＳサーバ処理部のＣＭＳのコンテンツ操作用のＡＰＩをコールする、ことを特徴とする請求項３記載のファイルサーバ装置。
6. クライアントからのファイルシステムへのアクセスを制御するファイルアクセスサーバ処理部と、
   データベースにてコンテンツを管理するＣＭＳ（Ｃｏｎｔｅｎｔｓ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）サーバ処理部と、
   前記クライアントからの前記ファイルシステムへの操作イベントが発生した時、前記ＣＭＳサーバ処理部に通知して、前記ファイルシステムへの操作内容を、前記データベースに反映させ、
   一方、前記ＣＭＳサーバ処理部が行う処理を、前記ファイルシステムに対する操作に変換して前記ファイルシステムに対して操作するＦＳ−ＣＭＳ連携処理部と、
   を備え、
   前記ＦＳ−ＣＭＳ連携処理部は、前記クライアントからの、前記ファイルシステムへのアクセスを、モニタリングアプリケーションインタフェースを通じて認識し、
   前記クライアントからのアクセスにより、前記ファイルシステムに変更が加えられると、前記ＦＳ−ＣＭＳ連携処理部は、前記変更内容を、前記ＣＭＳサーバ処理部に通知し、
   前記ＦＳ−ＣＭＳ連携処理部から前記通知を受けた前記ＣＭＳサーバ処理部では、前記データベースに前記変更内容を反映させ、
   前記クライアントがＣＭＳアプリケーションを用いてファイルに対する操作を行うと、前記ＦＳ−ＣＭＳ連携処理部を経由して、前記ファイルシステムにアクセスし、前記ＣＭＳサーバ処理部では、前記データベースに、前記変更内容を反映させる、ことを特徴とするファイルサーバ装置。
7. 前記ＣＭＳサーバ処理部で管理される属性を、前記ファイルシステムにおけるリンクに対応させる手段を備え、
   前記クライアントにおいて、前記ファイルアクセスサーバ処理部対応のプロトコルにしか対応していないアプリケーションからも、前記ＣＭＳサーバ処理部をアクセス可能としてなる、ことを特徴とする請求項６記載のファイルサーバ装置。
8. 検索ディレクトリ機能を備え、前記ＣＭＳサーバ処理部でのファイル検索を、前記クライアントにおいて前記ファイルアクセスサーバ処理部対応のプロトコルにしか対応していないアプリケーションからも利用可能としている、ことを特徴とする請求項６記載のファイルサーバ装置。
9. 前記ＦＳ−ＣＭＳ連携処理部は、前記クライアントからの前記ファイルシステムの検索ディレクトリへのアクセスを、モニタリングアプリケーションインタフェースを通じて認識すると、前記検索ディレクトリ名の示す属性を備えているファイルを、前記ＣＭＳサーバ処理部に問い合わせ、
   前記ＣＭＳサーバ処理部は、前記ＦＳ−ＣＭＳ連携処理部からの前記問い合わせを受けて、前記データベースを検索して、前記検索ディレクトリ名の示す属性を備えているファイルのリストを、前記ＦＳ−ＣＭＳ連携処理部に返し、
   前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルのリストをもとに、前記ファイルシステムにリンクファイルを作成し、前記検索ディレクトリ名の示す属性をもつファイルが一覧となって見えるようにしてなる、ことを特徴とする請求項６記載のファイルサーバ装置。
10. 前記検索ディレクトリからファイルがデリート（ＤＥＬＥＴＥ）された場合に、前記ファイルのデリート（ＤＥＬＥＴＥ）イベントに応じて、前記ファイルの実体をデリートする手段を備えている、ことを特徴とする請求項８又は９記載のファイルサーバ装置。
11. 前記ＦＳ−ＣＭＳ連携処理部は、デリート（ＤＥＬＥＴＥ）イベントを契機として、ファイルの拡張属性とリンクを再設定する、ことを特徴とする請求項６、８、９のいずれか一に記載のファイルサーバ装置。
12. 前記ＦＳ−ＣＭＳ連携処理部が、リネーム（ＲＥＮＡＭＥ）元のファイルと、リネーム（ＲＥＮＡＭＥ）先のファイルの情報を備えたリネーム（ＲＥＮＡＭＥ）テーブルと、
    デリート（ＤＥＬＥＴＥ）イベントを保存するデリート（ＤＥＬＥＴＥ）テーブルと、
    を備えている、ことを特徴とする請求項６、８、９のいずれか一に記載のファイルサーバ装置。
13. 前記ＦＳ−ＣＭＳ連携処理部は、
    前記ファイルシステムのファイルが更新されるときには、更新対象のファイルに関連付けて、リネーム（ＲＥＮＡＭＥ）イベントを保存するリネーム（ＲＥＮＡＭＥ）テーブルと、デリート（ＤＥＬＥＴＥ）イベントを保存するデリート（ＤＥＬＥＴＥ）テーブルと、を作成し、
    前記ＤＥＬＥＴＥイベントのファイルが、前記ＲＥＮＡＭＥテーブルのＲＥＮＡＭＥ先ファイルとして存在するか否かをチェックし、
    前記ＤＥＬＥＴＥイベントのファイルが前記ＲＥＮＡＭＥテーブルのＲＥＮＡＭＥ先ファイルとして存在した場合、ＲＥＮＡＭＥ元ファイルと同名なファイルが前記ファイルシステム上に存在するか否かをチェックし、
    前記ＲＥＮＡＭＥ元ファイルと同名なファイルが前記ファイルシステム上に存在した場合には、アプリケーションの更新動作とみなし、拡張属性とリンクを再設定し、前記ＲＥＮＡＭＥテーブルと前記ＤＥＬＥＴＥテーブルから、前記ファイルに関するエントリを削除する、ことを特徴とする請求項６、８、９のいずれか一に記載のファイルサーバ装置。
14. ファイルアクセスアプリケーションと、ＣＭＳ（Ｃｏｎｔｅｎｔｓ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）アプリケーションを含むクライアントと、
    前記クライアントと通信接続するファイルサーバ装置と、
    を備え、
    前記ファイルサーバ装置が、
    ファイルシステムと、
    前記クライアントからの前記ファイルシステムへのアクセスを制御するファイルアクセスサーバ処理部と、
    データベースにてコンテンツを管理するＣＭＳサーバ処理部と、
    前記ファイルシステムと前記ＣＭＳサーバ処理部とを連携させる制御を行うＦＳ−ＣＭＳ連携処理部と、
    を備え、
    前記ＦＳ−ＣＭＳ連携処理部は、
    前記クライアントのファイルアクセスアプリケーションからの前記ファイルシステムへのアクセスを、モニタリングアプリケーションインタフェースを通じて認識し、
    前記クライアントのファイルアクセスアプリケーションからの前記ファイルシステムへの操作イベントが発生した場合、前記ファイルシステムへの前記操作の内容を、前記ＣＭＳサーバ処理部で管理される前記データベースに反映させる制御を行い、
    前記クライアントのＣＭＳアプリケーションによるファイル操作を、前記ファイルシステムに対する操作に変換し、前記ファイルシステムに対して操作を行うとともに、前記ファイルシステムへの前記操作の内容を、前記ＣＭＳサーバ処理部に通知し、前記ＣＭＳサーバ処理部で管理される前記データベースに反映させる制御を行う、ことを特徴とする、ファイルサーバを用いたコンテンツ管理システム。
15. 前記ＦＳ−ＣＭＳ連携処理部は、前記クライアントからの前記ファイルシステムの検索ディレクトリへのアクセスを、モニタリングアプリケーションインタフェースを通じて認識すると、前記検索ディレクトリ名の示す属性を備えているファイルを前記ＣＭＳサーバ処理部に問い合わせ、
    前記ＣＭＳサーバ処理部は、前記ＦＳ−ＣＭＳ連携処理部からの前記問い合わせを受けて、前記データベースを検索して、前記検索ディレクトリ名の示す属性を備えているファイルのリストを、前記ＦＳ−ＣＭＳ連携処理部に返し、
    前記ＦＳ−ＣＭＳ連携処理部は、前記ファイルのリストをもとに、前記ファイルシステムにリンクファイルを作成し、前記検索ディレクトリ名の示す属性をもつファイルが一覧となって見えるようにしてなる、ことを特徴とする、請求項１４記載のファイルサーバを用いたコンテンツ管理システム。
16. クライアントからのファイルシステムへのアクセスを制御するファイルアクセスサーバ処理と、データベースにてコンテンツを管理するＣＭＳ（Ｃｏｎｔｅｎｔｓ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）サーバ処理と、を連携させる方法であって、
    前記クライアントのファイルアクセスアプリケーションから、前記ファイルシステムへの操作が行われた場合、前記ファイルシステムへの前記操作の内容を、前記ＣＭＳサーバ処理に通知し、前記操作の内容を前記ＣＭＳサーバ処理で管理される前記データベースに反映させる制御を行い、
    前記ＣＭＳサーバ処理が行う処理を、前記ファイルシステムに対する操作に変換して前記ファイルシステムに対して操作し、
    前記クライアントがＣＭＳアプリケーションをさらに含み、前記クライアントのＣＭＳアプリケーションによるファイル操作に対して、前記ファイルシステムに対する操作に変換し、前記ファイルシステムに対して操作を行うとともに、前記操作の内容を、前記ＣＭＳサーバ処理で管理される前記データベースに反映させる制御を行う、ことを特徴とするファイルアクセスサーバ処理とＣＭＳサーバ処理の連携方法。
17. 前記ＣＭＳサーバ処理のＣＭＳのコンテンツ操作用のＡＰＩ（アプリケーションインタフェース）を用いて、前記ファイルシステムに対する操作に対応するコンテンツ処理を実行する、ことを特徴とする請求項１６記載のファイルアクセスサーバ処理とＣＭＳサーバ処理の連携方法。
18. クライアントからのファイルシステムへのアクセスを制御するファイルアクセスサーバ処理と、データベースにてコンテンツを管理するＣＭＳ（Ｃｏｎｔｅｎｔｓ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）サーバ処理と、を実行するコンピュータに、
    前記クライアントのファイルアクセスアプリケーションからの前記ファイルシステムへの操作が行われた場合、前記ファイルシステムへの操作内容を、前記ＣＭＳサーバ処理で管理される前記データベースに反映させる制御を行い、前記ＣＭＳサーバ処理が行う処理を、前記ファイルシステムに対する操作に変換して前記ファイルシステムに対して操作する連携処理であって、前記クライアントのＣＭＳアプリケーションによるファイル操作に対して、前記ファイルシステムに対する操作に変換し、前記ファイルシステムに対して操作を行うとともに、前記ファイルシステムに対する操作内容を、前記ＣＭＳサーバ処理で管理される前記データベースに反映させる制御を行う連携処理を実行させる、プログラム。
19. 請求項１８記載のプログラムにおいて、
    前記連携処理では、前記ＣＭＳサーバ処理のＡＰＩ（アプリケーションインタフェース）を用いて前記ファイルシステムに対する操作に対応するコンテンツ処理を実行する、プログラム。

Images