JPH0934765A - ファイル管理装置 - Google Patents

Abstract

(57)【要約】 【目的】 ユーザが管理する属性の内、特定時刻にユー
ザが属性値の変更をすることが分かっている場合、その
属性の変更をユーザの明示的な指示に依らずに行うこと
を目的とする。 【構成】 属性更新部２３は更新要求があらかじめ設け
られた属性更新一覧情報２３ｂとファイルの属性情報２
２を書き換える属性書換部２３ｃとを有し、属性書換部
２３ｃが所定の時刻に属性更新一覧情報２３ｂに従って
属性情報２２を書き換えることで、変更し忘れなどがな
くなり、ユーザの負担が減少する。また、属性書換部２
３ｃによる属性情報２２の書き換えを、属性情報２２に
アクセスがあったとき、または一定時間毎あるいは所定
時刻に行うことで、システムの処理負荷を軽減し、処理
効率を向上させることができる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はファイルを管理するファ
イル管理装置に関し、特にネットワーク上で共用される
ファイルを管理するファイルサーバなどにてファイルの
属性を管理するファイル管理装置に関する。

【０００２】

【従来の技術】近年、ワークステーションまたはパーソ
ナル・コンピュータで構成することができる複数のクラ
イアントおよび複数のサーバがローカル・エリア・ネッ
トワーク（以下、ＬＡＮという）によって相互に接続さ
れて構成されているクライアント・サーバシステムが普
及してきている。このシステム内において、特に、ネッ
トワーク上で共用されるファイルを管理しているのがフ
ァイルサーバである。

【０００３】ファイルサーバでは、ＵＮＩＸファイルシ
ステム、ＤＦＲ（Document Filingand Retrieval）など
の一般的なファイルシステムが採用されている。このよ
うなファイルシステムでは、一般に、ファイルはその実
際のデータを示す内容部とこれに付与されたタイトルな
どの付加情報である属性部とから構成されるものと考え
られる。さらに、そのファイルの属性部における属性と
しては、サーバが管理する属性とユーザが管理する属性
とに大別することができる。

【０００４】サーバが管理する属性の例としては、「作
成時刻」や「作成者名」などがあり、ユーザが明示的に
指定しなくても、その値がファイルシステムによって自
動的にセットされるものである。たとえば、ＵＮＩＸフ
ァイルシステムでは、ファイル作成時には、ユーザの明
示的な指示なしで自動的に「作成者」、「作成時刻」、
「作成者グループ」、「ファイルの識別子」などの情報
がファイルシステムによりセットされる。また、他のフ
ァイルシステムにおいても、同様の属性が自動的にセッ
トされるようになっている。

【０００５】一方、ユーザが管理する属性の例として
は、「タイトル」や「検索キーワード」などが挙げられ
る。また、ＤＦＲにおける「拡張属性」なども、この例
に挙げられる。ユーザが管理する属性は、ファイルシス
テム側でその内容の解釈を行わない事を特徴とし、ユー
ザが明示的に指定することによってのみ、値をセットす
ることが可能なものである。

【０００６】このように、従来のファイルシステムで
は、基本的に、サーバが管理する属性の範ちゅうに含ま
れる属性については、ファイルシステム側で値のセット
／更新を行い、ユーザが管理する属性については、ユー
ザが明示的に指示を与えることによってのみ、値のセッ
ト／更新変更を可能としていた。

【０００７】また、ファイルの属性を管理するシステム
として、特開平１−２６３７４６号公報がある。この公
報には、登録者名簿自動管理システムが開示されてい
る。この登録者名簿自動管理システムは、ファイルを管
理するファイルサーバと、ファイルサーバ内にあるディ
レクトリに対してアクセスを許可するための名簿を管理
する認証サーバとを具備しており、認証サーバ内の名簿
に変更があったときには、ファイルサーバ内のアクセス
リストも変更しようというものである。これにより、認
証サーバの登録者名簿を変更した場合に、変更対象登録
者がファイルサーバの複数ディレクトリに対して使用さ
れていても、その登録者をアクセスリストに含むすべて
のディレクトリに対して同じ変更をしなければならない
という手間を省くことができるものである。この場合に
も、ユーザが管理する属性については、サーバ側でファ
イルシステムが独自に変更するということはなく、他か
らの、ここでは認証サーバからの、指示によってしか変
更されない。

【０００８】

【発明が解決しようとする課題】上述のように、ファイ
ルサーバのファイルシステムでは、ユーザが管理する属
性についてはユーザが明示的に指示を与える場合以外、
ファイルシステムが勝手に変更することはない。そのた
め、たとえば一定時刻経過後に属性値を変更しなければ
ならないことがあらかじめ分かっているような場合で
も、一定時刻経過後にユーザが明示的に値を変更しなけ
ればならず、ユーザにかかる負担が大きく、また、変更
し忘れなどのミスも起こりやすいという問題があった。

【０００９】本発明はこのような点に鑑みてなされたも
のであり、ユーザが管理する属性の内、一定時刻経過後
にユーザが属性値の変更をすることがあらかじめ分かっ
ているような属性について、ユーザ管理属性の所定時刻
における更新をサーバ側で行い、属性の変更を明示的に
行わなければならないというユーザにかかる負担を減少
させ、変更し忘れなどの人為的なミスの発生確率を減ら
すことができるファイル管理装置を提供することを目的
とする。

【００１０】また、本発明は属性値の変更をする時機を
考慮して、属性変更に要する手間が必要以上に発生する
のを防ぎ、処理効率を向上させることができるファイル
管理装置を提供することを目的とする。

【００１１】

【課題を解決するための手段】本発明では上記課題を解
決するために、第１の発明は、ファイル格納装置に格納
されたファイルの属性情報を管理するファイル管理装置
において、ファイルの属性に対応して更新時刻条件およ
び更新内容情報が設定された属性更新条件情報（図１の
２３ｂ）を記憶する記憶手段と、前記更新時刻条件を満
足するときに前記属性更新条件情報の属性に対応する前
記ファイルの属性情報（２２）の属性の値を前記更新内
容情報に基づいて書き換える属性書換手段（２３ｃ）と
を具備するものである。

【００１２】また、第２の発明は、ファイル格納装置に
格納されたファイルの属性情報を管理するファイル管理
装置において、ファイルの属性に対応して更新時刻条件
および更新内容情報が設定された属性更新条件情報（図
４の２３ｂ）を記憶する記憶手段と、前記ファイルの属
性情報（２２）へのアクセスを検出したときに前記属性
更新条件情報に設定された前記更新時刻条件に基づいて
更新の要否を判断する更新要否判断手段（２４，２３
ｄ）と、前記更新要否判断手段によって更新が必要と判
断された前記ファイルの属性情報の対応する属性の値を
前記更新内容情報に基づいて書き換える属性書換手段
（２３ｃ）とを具備するものである。

【００１３】好ましくは、第１および第２の発明のファ
イル管理装置は、入力属性更新条件情報に基づいて、前
記記憶手段に前記属性更新条件情報を設定する設定手段
（２３ａ）を有するものである。

【００１４】

【作用】第１の発明によれば、記憶手段内の属性更新条
件情報には所定時刻に、たとえばユーザが属性値の変更
をすることがあらかじめ分かっている属性について、更
新時刻条件（たとえば更新時刻）および更新内容情報
（たとえば更新後の値）などが設定されており、その更
新時刻に達するなどにより更新時刻条件を満足すると、
属性書換手段がその属性に対応するファイルの属性情報
の属性値を更新内容情報に基づいて更新する。更新内容
情報が、たとえば更新後の値の場合には、更新後の値に
更新する。これにより、ユーザ管理属性の設定時刻にお
ける更新が可能になり、属性の更新に関するユーザの負
担を軽減することができる。

【００１５】また、第２の発明では、属性更新条件情報
には、たとえば第１の発明と同様に、属性更新条件を設
定しておき、更新要否判断手段がファイルの属性情報へ
のアクセスを検出したときに属性更新条件情報を参照し
て設定されている更新時刻条件に基づいて更新要否を判
断する。たとえば更新時刻条件として更新時刻が現時刻
を経過しているかどうかで更新の要否を判断し、すでに
現時刻を経過している属性があれば、属性書換手段に依
頼してファイルの属性情報の対応する属性の値を更新後
の値に更新する。これにより、属性の書き換えをファイ
ルの属性情報にアクセスがあったときを契機にして行う
ようにしたことにより、処理効率を向上させることがで
きる。

【００１６】

【実施例】以下、本発明の実施例を添付図面を参照して
説明する。図１は本発明のファイル管理装置の第１の実
施例の構成を示すブロック図である。

【００１７】図示の構成はＬＡＮなどのネットワークの
一例を示したもので、１１，１２はユーザがサーバに処
理を要求するためのクライアントを示し、２０は実際に
ファイルに対する処理を行うためのファイルサーバを示
している。なお、図では、ファイルサーバ２０は１つの
みであるが、複数個存在することもある。

【００１８】ファイルサーバ２０は、クライアント１
１，１２からの要求を受け付ける要求受付部２１と、フ
ァイルサーバ２０が管理しているファイルの属性の属性
タイプおよび属性の値がファイル毎にセットされている
属性情報２２と、この属性情報２２に対して属性の値の
更新を行う属性更新部２３とから構成される。なお、本
実施例では、要求受付部２１からの要求に応じて属性情
報２２を読み込む属性読込部（図示せず）を有する。フ
ァイルサーバ２０として、さらに要求受付部２１からの
要求に基づいて前記各ファイルの内容情報を管理する内
容管理部（図示せず）を持つ。

【００１９】属性更新部２３は、要求受付部２１を介し
てクライアント１１，１２からの依頼により属性更新要
求をセットする更新要求追加部２３ａと、この更新要求
追加部２３ａによって属性更新要求がセットされる更新
要求一覧情報２３ｂと、この更新要求一覧情報２３ｂの
内容に従ってファイルの属性情報２２の属性値の更新を
行う属性書換部２３ｃとを有している。この更新要求一
覧情報２３ｂは、メモリ、ディスクなどの記憶手段に記
憶されているものとする。

【００２０】更新要求一覧情報２３ｂには、属性更新要
求情報が保存されているが、この属性更新要求情報は、
クライアント１１，１２からの属性更新要求を要求受付
部２１が受け付けて、属性更新部２３の更新要求追加部
２３ａに追加処理を依頼することにより、その更新要求
追加部２３ａによって更新要求一覧情報２３ｂに追加さ
れて、保存される。

【００２１】更新要求一覧情報２３ｂの属性更新要求情
報としては、「ファイル識別子」、「属性タイプ」、
「更新時刻」および「更新後の値」を含んでいる。ここ
で、現時刻が更新要求一覧情報２３ｂにセットされてい
る「更新時刻」に達すると、属性書換部２３ｃは、「フ
ァイル識別子」に対応するファイルの属性情報２２にお
いて、該当する属性タイプの値を、「更新後の値」の値
に書き換える。現時刻はファイルサーバ２０の内蔵時計
から取得する。

【００２２】図２は更新要求一覧情報の構成例を示す図
である。図示の例によれば、更新要求一覧情報２３ｂは
表形式になっており、ファイル識別子と、属性タイプ
と、更新時刻と、更新後の値との各項目によって構成さ
れている。更新要求一覧情報２３ｂの各エントリ（行）
は更新時刻の早い順に並べられており、これは更新要求
追加部２３ａによる属性更新要求の追加の際に、セット
されている更新時刻とセットしようとする更新時刻とを
考慮して更新時刻の順に並ぶようエントリの追加挿入位
置が決められる。この例では、最初、１９９５年７月１
２日１２時に、ファイル識別子「ＦｉｌｅＡ」のファイ
ルの属性「タイトル」が属性「一般公開」に変更され、
次の１９９５年７月１２日１２時３０分に、ファイル識
別子「ＦｉｌｅＢ」のファイルの属性「アクセス権」が
一般に許されるようになり、そして、１９９５年７月１
３日１２時３０分に、ファイル識別子「ＦｉｌｅＣ」の
ファイルはその階層構造に関する属性が元のフォルダか
ら「ＦｏｌｄｅｒＸ」に変更されることにより、そのフ
ォルダの中に移動されることになる。

【００２３】更新要求追加部２３ａで更新要求一覧情報
２３ｂのエントリを設定することにより、たとえば、
「部外秘文書の公開」、「文書フォルダ内容の差し替
え」、「文書ファイルの期間限定公開」などを行うこと
ができる。

【００２４】ここで、「部外秘文書の公開」とは、たと
えば、１か月間は部外秘としそれ以降は公開しても良い
という場合である。この場合に、１か月後にユーザが文
書のタイトルを変更し、秘密度の属性を公開に変更する
ことにより、ファイルのアクセス権が部内のみから社内
一般に変更され、実際に部外からのアクセスを制御する
ことができるようになる。すなわち、図２のファイル識
別子「ＦｉｌｅＭ」のファイルのように、１９９５年７
月１６日８時００分に、ファイルの属性「タイトル」が
社内公開に、属性「秘密度」が公開に、属性「アクセス
権」がＡ社に変更され、これによって部外秘文書の自動
公開が可能になる。

【００２５】「文書フォルダ内容の差し替え」について
は、ファイルシステムではいくつかの文書ファイルをま
とめてフォルダ内に格納することができるが、文書ファ
イルによっては、月が変わる度に、常に最新版が入って
いるフォルダから前の月度などの適切な月度のフォルダ
に文書ファイルを移し替えることがあり、これが文書フ
ォルダ内容の差し替えである。このような場合、ユーザ
は月初めに、ファイルの階層構造に関する属性を変更す
ることにより、文書フォルダ内容を差し替えることがで
きる。すなわち、図２のファイル識別子「ＦｉｌｅＮ」
のファイルのように、１９９５年７月１７日１７時００
分に、ファイルの属性「所属フォルダ」が６月度のフォ
ルダに変更され、文書フォルダ内容の自動差し替えが可
能になる。

【００２６】また、「文書ファイルの期間限定公開」
は、文書ファイルを一定期間だけ一般に公開して、期限
後は破棄するというような場合である。このような場
合、期間開始日にユーザは文書フォルダ内容の差し替え
と同様、ファイルの階層構造に関する属性を変更するこ
とで、文書ファイルを一般公開用のフォルダに格納し、
期限が切れた後に、ユーザによって再びファイルの階層
構造に関する属性を変更することにより、文書ファイル
をゴミ箱フォルダに移動する。すなわち、図２のファイ
ル識別子「ＦｉｌｅＯ」のファイルのように、１９９５
年７月１８日８時００分に、ファイルの属性「タイト
ル」が一般公開に、属性「アクセス権」が一般に許され
るようになり、属性「所属フォルダ」が一般公開用に、
そして、１９９５年８月１８日１７時００分に、ファイ
ルの属性「所属フォルダ」をゴミ箱に変更することによ
り、そのフォルダの中に移動されることになり、文書フ
ァイルの期間限定公開が可能になる。

【００２７】図３は更新要求追加部の処理の流れを示す
フローチャートである。要求受付部２１から更新要求一
覧情報２３ｂへのエントリの追加要求を受けると、更新
要求追加部２３ａは、まず、更新要求一覧情報２３ｂに
含まれる未処理のエントリの内、最初のエントリの情報
を取り出す（ステップＳ１）。最初は全てのエントリが
未処理なので、最初のエントリの情報が取り出される。
ここで、エントリが存在し、かつ、取り出したエントリ
の更新時刻が追加されるエントリの更新時刻の前かどう
かを判断する（ステップＳ２）。ここで、取り出したエ
ントリの更新時刻が追加されるエントリの更新時刻の前
であれば、ステップＳ１に戻って次に未処理のエントリ
の情報を取り出す。取り出したエントリの更新時刻が追
加されるエントリの更新時刻の前でなければ、取り出さ
れたエントリの後ろに新たにエントリを追加する（ステ
ップＳ３）。これにより、更新要求の追加処理では、更
新時刻が後になるエントリを順次探してそのエントリの
次に新たなエントリを追加するようにしたので、更新要
求の一覧は更新時刻の早い順に並べられた状態で作成さ
れることになる。

【００２８】このようにして、更新要求の追加処理によ
って作成された更新要求一覧情報２３ｂに基づいて属性
書換部２３ｃの処理について考える。図１の構成例で
は、属性書換部２３ｃの起動タイミングは、更新要求一
覧情報２３ｂに更新時刻としてセットされた時刻が現時
刻になったときである。このためには、通常、更新要求
一覧情報２３ｂから次に処理を行う必要のある時刻をあ
らかじめ求めておき、これを現時刻と比較し、両時刻が
一致したときに、属性書換部２３ｃは処理を開始するこ
とになる。しかし、この方法では、処理の起動が必要か
否かを常にチェックし続ける必要がある。そこで、属性
書換部２３ｃの起動タイミングを考慮した構成例を以下
に示す。

【００２９】図４は本発明の第２の実施例の構成を示す
ブロック図である。図中、図１に示した構成要素と同一
の要素については同一の符号で示し、内容管理部につい
ても同一である。図示の構成例によれば、要求受付部２
１からの依頼により属性情報２２よりファイルの情報を
読み込む属性読込部２４を有し、属性更新部２３にはさ
らに属性更新判断部２３ｄを有して、属性書換部２３ｃ
の起動タイミングを属性情報２２へのアクセス時として
いる。

【００３０】ここで、要求受付部２１からの依頼によっ
て属性読込部２４がファイルの属性情報２２に対して情
報の読み込みを行うとき、すなわち、属性情報２２に対
してアクセスがあるとき、属性読込部２４は属性更新部
２３の属性更新判断部２３ｄに対して属性の更新の要否
の判断を依頼する。属性更新判断部２３ｄでは、更新要
求一覧情報２３ｂの更新時刻の項を参照して、更新すべ
き時刻を経過している要求があるかどうかを判断し、そ
の判断結果を属性読込部２４に通知する。属性読込部２
４は通知された判断結果が更新不要の場合には属性情報
２２を読み込み、判断結果が更新要の場合には通知され
た更新要求について属性の更新を行うよう属性更新部２
３の属性書換部２３ｃに依頼し、更新後の属性情報２２
を読み込む。本実施例の詳細動作例は後述する。

【００３１】図５は本発明の第３の実施例の構成を示す
ブロック図である。図中、図１に示した構成要素と同一
の要素については同一の符号で示し、属性読込部および
内容管理部も同一である。図示の構成例によれば、属性
更新部２３にはさらに時刻設定部２３ｅを有して、属性
書換部２３ｃの起動タイミングを時刻設定部２３ｅによ
って設定された時刻としている。

【００３２】この時刻設定部２３ｅは属性の書き換えを
行うタイミングの時間間隔を設定するもので、設定され
た一定周期の時間毎に属性書換部２３ｃに対して書き換
え処理を依頼するものである。したがって、属性書換部
２３ｃは時刻設定部２３ｅによって設定された一定時間
毎に、すなわち、所定の時間間隔で起動され、このと
き、更新すべき属性があれば、属性の書き換えを実行す
ることになる。この時間間隔を小さくすればするほど、
即時更新に近くなり、第１の実施例と同様な効果が得ら
れる。

【００３３】また、時刻設定部２３ｅは周期的な時間間
隔を設定するのではなく、特定の時刻を指定して、その
指定時刻に属性の書き換えを行うようにすることもでき
る。たとえば、ファイルサーバ２０の処理負荷の少ない
夜中などに時刻を設定しておき、その時刻になると、そ
れまでに更新を行わなければならない属性を一斉に更新
するように指定することもできる。

【００３４】次に、第３の実施例の属性書換部２３ｃの
処理の動作を図６のフローチャートを参照して説明す
る。属性読込部２４から属性情報２２にアクセスがあっ
たことの通知があると、または時刻設定部２３ｅより一
定時間毎またはあらかじめ定められた一定時刻に時刻情
報が通知されると、属性書換部２３ｃは、更新要求一覧
情報２３ｂを参照し、更新要求一覧に含まれるエントリ
の内、最初のエントリの情報を取り出す（ステップＳ１
１）。ここで、エントリが存在し、かつ、更新すべき時
刻になっているかどうかを判断する。たとえば、更新時
刻と現時刻とを比較して更新時刻が現時刻を経過してい
るかどうかを判断する（ステップＳ１２）。更新要求一
覧情報２３ｂは更新時刻でソートされているので、最初
のエントリの情報において、更新時刻が現時刻を経過し
ていなければ、すべてのエントリの更新時刻も更新すべ
き時刻に達していないので、そのまま終了する。最初の
エントリの情報の更新時刻が現時刻を経過していれば、
属性書換部２３ｃは、更新要求エントリの記述に従って
ファイルの属性情報２２の該当する属性タイプの属性値
の書き換えを行う（ステップＳ１３）。そして、属性値
の書換えが終了した更新要求一覧情報２３ｂの最初のエ
ントリを削除する（ステップＳ１４）。その後、ステッ
プＳ１１に戻って、削除されたエントリの次のエントリ
の情報の取り出しに進む。このようにして、更新を行う
時刻情報の通知に応答して、更新要求一覧情報２３ｂの
最初のエントリに記述された更新時刻を現時刻と比較
し、更新時刻が現時刻より先であれば、それ以降のエン
トリを調べることなく更新処理を終了し、更新時刻が現
時刻より前であれば、更新時刻が現時刻より先となるエ
ントリが現れるまで、各エントリの更新処理を行うよう
にしている。

【００３５】本実施例では、すべてのファイル、または
属性タイプについて、同一の更新条件（すなわち、一定
間隔）で更新処理を行っていたが、ファイル、または属
性タイプの性質などに応じて異なる条件、たとえば、即
時性が要求されるものと、そうでないものとに分けて管
理しておき（たとえば、更新要求一覧を分ける）、それ
らを要求に適合した条件で更新処理するようにしてもよ
い。さらに、第２の実施例と組み合わせて、アクセス検
出時に更新すれば十分のものについては、アクセスを検
出したときに、更新処理をするように構成してもよい。

【００３６】次に、更新要求一覧情報の構成例として、
表を用いて情報の格納・探索を行う方法であって、情報
を登録するのに探索キーの内部コードを用いて格納エン
トリを決定するというようなハッシュ法を用いること
で、適切な更新エントリアクセスを高速に行えるように
した実施例を示す。なお、ハッシュ法は処理効率向上の
ために採用したものであり、本発明の本質とは関係がな
いので詳述はしないが、必要ならば、たとえば「ファイ
ルシステム」（啓学出版、Ｔ. Ｒ. ハーブロン著、遠山
元道訳）などに詳細が説明されている。

【００３７】図７は更新要求一覧情報の別の構成例を示
す図である。図示の更新要求一覧情報によれば、その項
目であるファイル識別子と属性タイプとから所定の計算
式によりハッシュ値が求められ、そのハッシュ値からこ
れに対応するエントリＥが作成され、そのエントリＥに
更新要求毎に作成された更新要求ノードＮが更新時刻の
順に整列されている。更新要求ノードＮには、更新時刻
および更新後の値がセットされている。

【００３８】この更新要求一覧情報による各実施例の更
新要求追加部の処理動作を図８のフローチャートを参照
して説明する。要求受付部２１から更新要求一覧情報２
３ｂへのエントリの追加要求を受けると、更新要求追加
部２３ａは、まず、対象となるファイルのファイル識別
子と属性タイプとからハッシュ値を求める（ステップＳ
２１）。次いで、そのハッシュ値に対応するエントリが
あるかどうかが判断される（ステップＳ２２）。ここ
で、ハッシュ値に対応するエントリがなければ、新たに
エントリを作成し（ステップＳ２３）、対応するエント
リがあれば、そのエントリを更新要求の追加対象エント
リとする。その後、更新要求ノードを作成し、作成した
更新要求ノードが更新時刻順に整列するようにエントリ
に挿入する（ステップＳ２４）。

【００３９】次に、第２の実施例の属性更新判断部の処
理動作を図９のフローチャートを参照して説明する。属
性更新判断部２３ｄが属性読込部２４から該当ファイル
の属性を変更すべきかどうかの判断の依頼があると、そ
のファイルのハッシュ値を求め、更新要求一覧情報から
このハッシュ値にマッチするエントリを探し出す（ステ
ップＳ３１）。ここで、更新要求一覧情報にハッシュ値
に対応するエントリが存在するかどうか判断され（ステ
ップＳ３２）、存在する場合には、そのエントリの更新
要求ノードの更新時刻を参照して更新を行う必要がある
かどうかが判断される（ステップＳ３３）。更新を行う
必要があると判断された場合には、そのエントリから更
新を行う必要がある更新要求ノードを削除し、属性読込
部２４に対して属性タイプおよび更新後の値を通知する
（ステップＳ３４）。

【００４０】一方、ハッシュ値に対応するエントリが存
在しない場合、またはハッシュ値に対応するエントリが
存在しても属性の更新を行う必要がない場合には、属性
読込部２４に対して属性の更新の必要がない旨の通知を
行う（ステップＳ３５）。

【００４１】ここで、属性書換部２３ｃの起動タイミン
グが属性情報２２へのアクセスのときとし、属性情報２
２へアクセスしたときの属性読込部２４の処理の例を以
下に示す。

【００４２】次に、要求受付部からファイル属性の読み
込みを依頼された時の属性読込部の処理を図１０のフロ
ーチャートを参照して説明する。要求受付部２１からフ
ァイル属性の読み込みを依頼されると、属性読込部２４
は属性更新部２３の属性更新判断部２３ｄに対して当該
ファイルの属性を変更する必要があるかどうかのチェッ
クを依頼する（ステップＳ４１）。次に、属性更新判断
部２３ｄから通知されたチェックの結果は属性の変更を
必要とするものであるかどうかが判断される（ステップ
Ｓ４２）。ここで、属性の変更が必要と判断されると、
属性更新判断部２３ｄから通知された当該ファイルの属
性タイプおよび更新後の値の情報を用いて属性書換部２
３ｃに属性の更新を依頼する（ステップＳ４３）。ステ
ップＳ４２において、属性の変更が不要と通知された場
合、またはステップＳ４３において、属性の変更が終了
した場合には、そのときのファイルの属性情報２２の値
が属性読み込みの結果として要求受付部２１に返される
（ステップＳ４４）。

【００４３】以上述べた実施例によれば、次のような効
果が得られる。ファイルサーバにおいてファイルの内容
とともに管理されているファイルの属性をユーザが指定
した更新時刻に更新するようにした。これにより、一定
時刻経過後にユーザが属性値の変更をすることがあらか
じめ分かっているような属性について、その時刻にユー
ザが属性の変更を明示的に行わなくてもサーバ側で行う
ことができる。

【００４４】また、実際に属性の更新を行う時刻を属性
情報へのアクセスがあったときや、あらかじめ定められ
た一定時間、一定周期毎に行うように構成したことによ
り、処理効率を向上させることができる。さらに、属性
の更新を指定時刻に行うように構成したことにより、属
性の更新を行う時刻を深夜などシステムの処理負荷の少
ない時刻に設定することで、その時刻情報に基づいて、
その日に更新すべきであった属性を一括して更新するこ
とができ、処理効率を向上させることができる。

【００４５】さらに、更新要求一覧を用いて更新時刻で
ソートするようにしたので、更新時刻の判断が容易で、
更新の処理効率が高い。以上述べた実施例では、属性更
新条件情報としてファイルの属性に対応して更新時刻毎
に、更新後の値を設定する更新要求一覧を用いたが、フ
ァイルの属性に対応して更新条件時刻条件と、これに対
応する更新内容情報を設定できる形式であればどのよう
なものでもよい。たとえば、ファイルの属性に対応し
て、ある期間（第１の時刻から第２の時刻まで）を示す
更新条件時刻条件と、これに対応する更新内容情報（た
とえば当該期間に設定されるべき属性値）を設定した属
性更新条件情報を持ち、この更新条件を所定のタイミン
グ（第１ないし第３の実施例と同様）で判断して更新条
件を満足する場合（更新すべき場合）に更新するように
してもよい。この場合には、普段は非公開のファイルで
４月だけ閲覧を許すようなものの場合、ファイルの属性
に対応して、更新条件時刻条件として、４月、更新内容
情報（属性値）として公開、その他の月は非公開のよう
なシステムが解釈可能な記述で属性更新条件情報を設定
することにより、毎回更新時刻単位で設定する必要がな
い。

【００４６】また、以上述べた実施例では、更新要求一
覧で更新済のエントリは、順次削除し、属性更新条件情
報の設定が必要な場合には、新たにエントリを追加する
構成であったが、属性更新条件情報が設定できればどの
ような設定手段でもよい。

【００４７】さらに、属性値を更新後の値ですべて書換
える（置換）ものであったが、一部の追加も許すことと
し、一部追加（ａｄｄ）、置換（ｓｅｃ）のように更新
後の値に種別を設けてもよい。

【００４８】

【発明の効果】以上詳細に説明したように、本発明の第
１の発明では、ファイルの属性に対応して更新時刻条件
と更新内容情報を含む属性更新条件情報を記憶してお
き、更新時刻条件が満足するとき、対応するファイルの
属性情報を更新内容情報に基づいて更新するように構成
したので、ユーザの更新操作の手間が省ける。

【００４９】また、第２の発明によれば、第１の発明と
同様に属性更新条件情報を記憶しておき、ファイルの属
性情報に対するアクセスを検出したとき、更新時刻条件
に基づいて属性の更新の要否を判断して、対応するファ
イルの属性情報を更新内容情報に基づいて更新するよう
に構成したので、アクセス時のような遅くとも属性の更
新の必要な時に更新できるので、システムの更新処理の
効率が向上する。

【図面の簡単な説明】

【図１】本発明のファイル管理装置の構成例を示すブロ
ック図である。

【図２】更新要求一覧情報の構成例を示す図である。

【図３】更新要求追加部の処理の流れを示すフローチャ
ートである。

【図４】本発明のファイル管理装置の別の構成例を示す
ブロック図である。

【図５】本発明のファイル管理装置の別の構成例を示す
ブロック図である。

【図６】属性書換部の処理の流れを示すフローチャート
である。

【図７】更新要求一覧情報の別の構成例を示す図であ
る。

【図８】更新要求追加部の別の処理の流れを示すフロー
チャートである。

【図９】属性値の変更が必要か否かをチェックする属性
更新判断部の処理内容を示すフローチャートである。

【図１０】要求受付部からファイル属性の読み込みを依
頼された時の属性読込部の処理を示すフローチャートで
ある。

【符号の説明】

１１，１２ クライアント ２０ ファイルサーバ ２１ 要求受付部 ２２ 属性情報 ２３ 属性更新部 ２３ａ 更新要求追加部 ２３ｂ 更新要求一覧情報 ２３ｃ 属性書換部 ２３ｄ 属性更新判断部 ２３ｅ 時刻設定部 ２４ 属性読込部

Claims (2)

【特許請求の範囲】
1. 【請求項１】 ファイル格納装置に格納されたファイル
   の属性情報を管理するファイル管理装置において、 ファイルの属性に対応して更新時刻条件および更新内容
   情報が設定された属性更新条件情報を記憶する記憶手段
   と、 前記更新時刻条件を満足するときに前記属性更新条件情
   報の属性に対応する前記ファイルの属性情報の属性の値
   を前記更新内容情報に基づいて書き換える属性書換手段
   と、 を具備することを特徴とするファイル管理装置。
2. 【請求項２】 ファイル格納装置に格納されたファイル
   の属性情報を管理するファイル管理装置において、 ファイルの属性に対応して更新時刻条件および更新内容
   情報が設定された属性更新条件情報を記憶する記憶手段
   と、 前記ファイルの属性情報へのアクセスを検出したときに
   前記属性更新条件情報に設定された前記更新時刻条件に
   基づいて更新の要否を判断する更新要否判断手段と、 前記更新要否判断手段によって更新が必要と判断された
   前記ファイルの属性情報の対応する属性の値を前記更新
   内容情報に基づいて書き換える属性書換手段と、 を具備することを特徴とするファイル管理装置。