JP2003015924A

JP2003015924A - ファイル管理方法

Info

Publication number: JP2003015924A
Application number: JP2001204148A
Authority: JP
Inventors: Eiji Kitsuke; 英士木付; Hirotoshi Iwano; 裕利岩野; Takayoshi Yamaguchi; 孝好山口
Original assignee: Sharp Corp
Current assignee: Sharp Corp
Priority date: 2001-07-05
Filing date: 2001-07-05
Publication date: 2003-01-17

Abstract

(57)【要約】【課題】ファイルに特殊なフィールドを追加すること
なく、ファイルが他のドライバもしくはアプリケーショ
ンにより更新されたことを簡単に検出することが可能な
ファイル管理システムを提供する。【解決手段】自由な書き込みが許可されたフィールド
に、ファイルの更新時に必ず更新される情報をバックア
ップ情報として書き込んでおき、このファイルの更新時
に必ず更新される情報とバックアップ情報とを比較する
ことによって、容易にファイルの更新の有無を検出する
ものである。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ファイルの更新時
に必ず更新される情報を含む管理情報を用いて、データ
と前記管理情報から構成されるファイルを管理するファ
イル管理方法に関し、より詳細には、ファイルの更新の
有無を簡単に検出することが可能なファイル管理方法に
関するものである。

【０００２】

【従来の技術】ＰＣ（パーソナルコンピュータ）用途や
ＡＶ（オーディオビジュアル）用途などの様々な用途
で、ディスク媒体にデータを記録する場合、一般的に論
理ファイルシステムが用いられる。論理ファイルシステ
ムを用いることによって、記録したデータをファイルと
して管理し、ディレクトリ階層を構築することが可能と
なり、管理が容易となる。論理ファイルシステムの例と
しては、広く普及しているＦＡＴ方式やＤＶＤなどで導
入されているＵＤＦ（Universal Disk Format）などが
挙げられる。

【０００３】論理ファイルシステムとは、ディスクに記
録されたデータに対して、データを識別するための情報
やデータが記録されたディスク上の位置情報などを管理
情報としてディスクに記録し、それらの情報にアクセス
することによって、データアクセスを可能にする仕組み
のことである。

【０００４】例えば、論理ファイルシステムの管理情報
には、ファイル名、そのファイルに関する作成日時、フ
ァイルサイズ、状態を示す情報などの属性情報、対応す
る実データが記録されているディスク上の位置情報など
が記録されている。

【０００５】ＦＡＴやＵＤＦなどといった様々な種類の
論理ファイルシステムが存在するが、これらは管理情報
の構成や管理する属性情報が異なるだけで、ファイル名
あるいはそれに準ずる情報からディスク上の目的のデー
タにアクセスすることが出来るという意味では、同じ目
的のためのものである。

【０００６】ここで、従来の一般的なファイルシステム
例を、ＤＶＤなどにも用いられているＵＤＦについて説
明する。ディスク内にはファイルやディレクトリが記録
され、ルートディレクトリを基準にツリー構造を形成す
る。ＵＤＦファイルシステムは、ディスク上をボリュー
ム情報を記録する領域とパーティション領域とに分けて
管理し、ファイルやディレクトリはパーティション領域
に記録される。

【０００７】ディスク上には、ディスク全体に割り振ら
れた論理セクタ番号（ＬＳＮ：Logical Sector Numbe
r）とパーティション内に割り振られた論理ブロック番
号（ＬＢＮ：Logical Block Number）との二つのアドレ
ス情報が付加されている。

【０００８】図１４、図１５にファイルとディレクトリ
の構造をそれぞれ示す。図１４及び図１５はパーティシ
ョン内のディスク上のイメージ図であり、左から右方向
へ論理ブロック番号が付加されている。ディスクから管
理情報やデータを読み出す際は、この論理ブロック番号
を指定して読み出すことになる。

【０００９】データは、その管理情報であるＦＥ（File
Entry）内のＡＤ（Allocation Descriptor）によって
記録位置が管理されている。図１６及び図１７にＦＥ、
ＡＤの構造規格を示す。ＦＥの先頭にはDescriptor Tag
が記録される。Descriptor Tagについては後述する。

【００１０】ICB Tagにはファイル構造に関する記述が
記録され、Uid、Gid にはユーザＩＤとグループＩＤが
記録され、Permissionにファイルのパーミッションが記
録される。File Link CountはこのＦＥが参照している
ファイルやディレクトリの数が記録される。

【００１１】Record Format、Record Display Attribut
e、Record Lengthはレコード記録用のフィールドで現在
のＵＤＦでは使用しない。Information LengthにはＡＤ
の管理する領域であるデータの総サイズ、Logical Bloc
k RecordedにはＡＤの管理する領域であるデータの総論
理ブロック数が記録される。

【００１２】Access Date and Time、Modification Dat
e and Time、Attribute Date and Timeには最終アクセ
ス時刻、最終更新時刻、最終属性変更時刻が記録され
る。Checkpointは現在のＵＤＦでは常に１が記録され、
使用されていない。Extended Attribute ICB及びExtend
ed Attributesは拡張属性用のフィールド、Implementat
ion Identifierはシステム用の識別情報が記述出来るフ
ィールドで、Unique IDには各ＦＥ固有の番号が付与さ
れる。

【００１３】Extended Attributeフィールドの大きさは
Length of Extended Attributesに記録される。Allocat
ion DescriptorsはＡＤを記録するフィールドで、Lengt
h of Allocation Descriptorsに大きさが記録される。
ファイル用のＦＥにおいてＡＤはデータを記録したディ
スク上の連続した1領域を記録し、Extent LengthとExte
nt Positionから構成される。

【００１４】Extent Lengthは図１８に示す2ビットのタ
イプと30ビットの値から構成される。2ビットのタイプ
については、図１９で示した4つのタイプが存在する。
通常は0がセットされる。この30ビットには領域の長さ
がバイト単位で記録され、Extent Positionには領域の
開始ＬＢＮが記録される。ＦＥには複数のＡＤを記録す
ることが出来、分断記録されたファイルを一元的に管理
することが出来る。

【００１５】ディレクトリも同様にＦＥで管理されてい
る。ディレクトリ用のＦＥ内のＡＤはＦＩＤ(File Iden
tifier Descriptor)の集合の記録位置を管理している。
ただし、先頭のＦＩＤは親ディレクトリの記録位置を管
理するものであり、本書面の図中ではその矢印を省略す
る。図２０及び図２１にＦＩＤとＦＩＤに含まれるＩＣ
Ｂ(Information Control Block)の構造規格を示す。Ｆ
ＩＤの先頭もDescriptor Tagが記録されている。File V
ersion Numberにファイルの版数、File Characteristic
sには属性情報が記録される。

【００１６】Length of File IdentifierはFile Identi
fierフィールドの大きさを、Lengthof Implementation
UseはImplementation Useフィールドの大きさを記録す
る。Implementation Useフィールドはシステム用の記録
領域で、File Identifierフィールドにはファイル名も
しくはディレクトリ名が記録される。

【００１７】ＩＣＢはＦＥ領域の記録位置を管理する情
報で、Extent Length、Extent Location、Flags、UDF U
nique IDから構成されている。Extent Lengthには領域
の大きさがバイト単位で、Extent Locationには領域の
開始ＬＢＮが、Flagsは領域管理属性用のフィールドでU
DF Unique IDにはFIDの参照先であるＦＥと同じUniqueI
Dが記録される。

【００１８】図２２にDescriptor Tagの構造規格を示
す。Tag Identifierにはタグ種別が番号で記録される。
Descriptor Versionには版数が、Tag ChecksumにはDesc
riptorTagのチェックサム用の値が記録される。Tag Ser
ial Numberにはフォーマットする度につけられる通し番
号が付けられる。

【００１９】Descriptor CRCはタグ以降のDescriptor C
RC Lengthで指定された長さのデータに対してＣＲＣ（C
yclic Redundancy Check）用の値が記録される。ＣＲＣ
は、巡回冗長検査と呼ばれ、ディスクコントローラなど
でよく使われるデータの読み書きに対するエラーチェッ
クである。Tag Locationにはこの記述子自体の記録位置
（ＬＢＮ）が記録される。

【００２０】ここで、図２３を用いてＵＤＦファイルシ
ステムにおけるファイルの書き込み手順、及びファイル
の読み出し手順について説明する。まず、図２３に示す
ようにデータをディスクに書き込む。データの書き込み
が終了したらその記録領域の位置情報などを管理するＦ
Ｅをディスクに書き込む。データの記録領域の位置情報
は、ＦＥに含まれるＡＤに記録される。

【００２１】さらに、ファイル名であるSHRP0001.MQTや
このＦＥの記録位置などを管理するＦＩＤを作成する。
このＦＥの記録位置はＦＩＤに含まれるＩＣＢに記録さ
れる。作成したＦＩＤは、SHRP0001.MQTを作成するディ
レクトリMQ#ROOTのＦＥが管理するＦＩＤ列に追加され
る。

【００２２】次に、ファイルを読み出す手順について説
明する。例えば作成した\MQ#ROOT\SHRP0001.DATを読み
出したい場合、まずＲＯＯＴディレクトリのＦＥをディ
スクから読み出し、このＦＥが管理するＦＩＤ列が記録
されている位置をＦＥ内のＡＤから把握する。この情報
を元にＦＩＤ列をディスクから読み出す。読み出したＦ
ＩＤ列の中からディレクトリ名であるMQ#ROOTを含むＦ
ＩＤを抽出する。

【００２３】抽出したＦＩＤ内のＩＣＢよりMQ#ROOTデ
ィレクトリのＦＥの記録位置を把握しディスクから読み
出す。同様に、MQ#ROOTディレクトリのＦＥが管理する
ＦＩＤ列よりSHRP0001.MQTに対応するＦＩＤを抽出し、
これによりＦＥをディスクから読み出す。読み出したＦ
Ｅには目的のファイルSHRP0001.MQTの実体の記録位置が
ＡＤに記録されているため、この情報を元にディスクか
ら読み出すことが可能となる。

【００２４】

【発明が解決しようとする課題】ここで、ＦＥのImplem
entation Identifierに注目する。通常このフィールド
はどのファイルシステムドライバによって編集されたの
かを示す識別情報が記録される。この情報を用いること
で、ファイルが最後に更新されたのはどのドライバが編
集した時であるかを確認することが出来る。しかしなが
ら、このフィールドを更新しないドライバでアクセスし
た場合、最後の更新がどのドライバによるものなのかは
保証されないという問題があった。

【００２５】また、ＨＴＭＬファイルなどのデータフォ
ーマットにおいて、ＨＴＭＬエディタなどのアプリケー
ションで作成されたファイルには、ヘッダ情報やコメン
トとしてエディタを識別する情報が記録されることがあ
る。しかし、作成されたファイルに対し、他のＨＴＭＬ
エディタで編集してもヘッダ情報を書き換えない可能性
がある。また、コメントはそのまま残されることが充分
に考えられる。その結果、上記と同様に最後に編集した
アプリケーションを特定することが出来ないという問題
があった。

【００２６】本発明は、上記課題に鑑みてなされたもの
であり、特定のファイルシステムドライバ、もしくはア
プリケーションでアクセスしたファイルに対し、初めて
アクセスするファイルであるのか、以前アクセスしたフ
ァイルが更新されたものであるのか、以前アクセスした
ままのファイルであるのかを容易に判別することが可能
なファイル管理システムを提供するものである。

【００２７】

【課題を解決するための手段】本願の第１の発明は、フ
ァイルの更新時に必ず更新される情報を含む管理情報を
用いて、データと前記管理情報から構成されるファイル
を管理するファイル管理方法において、前記管理情報内
の自由な書き込みが許可されたフィールドに、前記ファ
イルの更新時に必ず更新される情報をバックアップ情報
として書き込むことを特徴とする。

【００２８】本願の第２の発明は、ファイルの更新時に
必ず更新される情報を含む管理情報を用いて、データと
前記管理情報から構成されるファイルを管理するファイ
ル管理方法において、前記データ内の自由な書き込みが
許可されたフィールドに、前記ファイルの更新時に必ず
更新される情報をバックアップ情報として書き込むこと
を特徴とする。

【００２９】本願の第３の発明は、ファイルの更新時に
必ず更新される情報を含む管理情報を用いて、データと
前記管理情報から構成されるファイルを管理するファイ
ル管理方法において、所定の１ファイルの中に、前記フ
ァイルの更新時に必ず更新される情報をバックアップ情
報として、ファイル名と対応付けて書き込むことを特徴
とする。

【００３０】本願の第４の発明は、前記ファイルの更新
時に必ず更新される情報と前記バックアップ情報とを比
較することにより、ファイルの更新の有無を検出するこ
とを特徴とする。

【００３１】

【発明の実施の形態】以下、本発明の第１の実施形態
を、ＵＤＦにおけるＦＥのInformation Lengthの変更を
検出するものについて、図１乃至図４とともに詳細に説
明する。

【００３２】すなわち、本実施形態は、管理情報内の自
由な書き込みが許可されたフィールドに、ファイルの更
新時に必ず更新される情報をバックアップ情報として書
き込むものである。

【００３３】最初に、本実施形態を適用したＵＤＦドラ
イバでファイルを更新する際の手順を、図１のフローチ
ャートとともに説明する。まず、通常のファイルの更新
処理を行う(ステップ101)。ただし、以降に行うImpleme
ntation IdentifierとDescriptor Tagの書き込みは、こ
の時点では行わない。

【００３４】次に、Information Lengthを読み込み(ス
テップ102)、Implementation Identifierにその情報を
記録する(ステップ103)。最後に、Descriptor Tagを編
集し、記録する(ステップ104)。

【００３５】ここで、Implementation Identifierフィ
ールドのフォーマットについて図２を用いて説明する。
ＵＤＦ規格では、Implementation IdentifierはEntity
Identifierフォーマットで記録される。そのうち、Iden
tifierフィールドにDeveloper IDが記録出来るので、こ
こでは"SHARP-UDF"と記録することにする。

【００３６】また、Implementation Useフィールドが自
由に規定出来るので、前２バイトにBackup Identifier
という名称でバックアップ情報の種類を規定する。ここ
ではInformation Lengthを示す値として"IL"と記録する
ことにする。後４バイトはBackup Valueと定義し、バッ
クアップ情報を記録する。ここではInformation Length
の下位４バイトを記録する。

【００３７】次に、上記の過程で記録されたファイル
を、本実施形態を適用していないＵＤＦドライバで編集
した場合について考える。まず、編集の結果、情報量が
変化すれば、Information Lengthが更新される。また、
Implementation Identifierを書き換えるドライバであ
れば、他のDeveloper IDが記録される。ここでは、Deve
loper IDとして"OTHER"が記録されるものとする。

【００３８】また、上記の過程で再編集されたファイル
に対し、本実施形態を適用したＵＤＦドライバでアクセ
スした際に更新の有無を検出する手順について、図３の
フローチャートとともに説明する。まず、対象となるフ
ァイルのＦＥを読み込み(ステップ201)、Implementatio
n Identifierを参照する(ステップ202)。

【００３９】ここで、Identifierフィールドに書き込ま
れたDeveloper IDが本ドライバのものでない場合、つま
り"OTHER"と記録されていた場合は、すでにデータの編
集が行われていることがわかる。もしくは、新規に作成
されたファイルも異なったDeveloper IDが付与されてい
るはずである(ステップ203)。

【００４０】Developer IDとして"SHARP"と記録されて
いた場合は、Implementation Useフィールドの前２バイ
トにBackup Identifierが記録されている。Backup Iden
tifierを読み込み、いずれの情報がバックアップされて
いるのかを判定する(ステップ204)。

【００４１】Backup Identifierに"IL"が記録されてい
た場合は、比較対象となるInformation Lengthを読み込
む(ステップ205)。もし、"IL"以外のものが記録されて
いた場合は、管理情報が書き換えられたことがわかり、
これはデータが編集されたことを示す。対象がInformat
ion Lengthであれば、Information Lengthの下位４バイ
トとBackup Valueを比較する(ステップ206)。２値が異
なる場合は、すでにデータの編集が行われていることが
わかる。

【００４２】本実施形態では、ファイルの更新時に必ず
更新される情報としてInformationLengthを例にとった
が、Access Timeやそれらの情報の組み合わせなど他の
情報を用いることも可能である。また、ＵＤＦに限らず
同様の情報をもった他のファイルシステムに適用して
も、同様の機能を実現出来ることは言うまでもない。

【００４３】さらに、上述した特定のドライバ以外で編
集されたことを検出する機能は、図４に示すような状況
にも利用することが出来る。図４において、本実施形態
を適用したドライバ101は、ファイルのバックアップ機
能、もしくはファイルの管理情報のバックアップ機能を
搭載している。

【００４４】まず、本実施形態を適用したドライバ101
で、ある媒体にファイルＡを作成する。すると、ドライ
バ101はバックアップ作成回路102を起動させ、ファイル
Ａの複製ファイルＡ'を自動生成する。

【００４５】次に、この媒体に本実施形態を適用してい
ないドライバ103でアクセスする。ここで、ドライバ103
を使用してファイルＡを編集してファイルＢに書き換え
る。すると、ファイルＢと複製ファイルＡ'の間に不整
合が生じる。

【００４６】そしてまた、この媒体に本実施形態を適用
したドライバ101で再度アクセスする。すると、ドライ
バ101の更新検出回路104が機能し、ファイルが更新され
ていることが検出される。それをトリガとして、バック
アップ更新回路105が起動し、複製ファイルＡ'を複製フ
ァイルＢ'に自動更新する。

【００４７】上記のように、バックアップを目的とした
場合、対象のファイルと複製ファイルとを比較すること
により、ファイルの更新を検出することは出来るが、交
互にファイルにアクセスする必要があるなど効率がよく
ない。これに対し、本実施形態によれば、アクセスする
のは対象のファイルのＦＥのみであるため、高速にファ
イル更新の有無の検出を行うことが可能である。

【００４８】以上詳述したとおり、本実施形態において
は、バックアップを目的とした場合に限らず他の目的に
対しても、容易にファイルの更新の有無を検出すること
が出来る。また、ファイルの管理情報として特殊なフィ
ールドを追加する必要がないことも有用な特徴である。

【００４９】次に、本発明の第２の実施形態として、Ｈ
ＴＭＬエディタによるＨＴＭＬファイルの最終更新時刻
の更新を検出するものについて、図５乃至図７とともに
詳細に説明する。

【００５０】すなわち、本実施形態は、データ内の自由
な書き込みが許可されたフィールドに、ファイルの更新
時に必ず更新される情報をバックアップ情報として書き
込むものである。

【００５１】最初に、本実施形態を適用したＨＴＭＬエ
ディタでＨＴＭＬファイルを更新する際の手順につい
て、図５のフローチャートとともに説明する。まず、通
常のＨＴＭＬエディットを行う(ステップ301)。保存時
にコメントタグを用いてエディタ情報と保存時刻を記録
し(ステップ302)、ファイルを閉じる(ステップ303)。

【００５２】この際に保存時刻とファイルの最終更新時
刻は同一の値でなければならない。本実施形態では、誤
差の許容範囲を考え、保存時刻は秒以下の情報を切り捨
てた値とする。

【００５３】図６にコメントタグの記録例を示す。この
例では、ＨＴＭＬヘッダ情報の中に"SHARP#BACKUP#INF
O"という識別情報と、このＨＴＭＬファイルを2001年6
月26日15時5分に編集完了したことを示す情報とが記録
されている。

【００５４】次に、上記の過程で記録されたＨＴＭＬフ
ァイルを、本実施形態を適用していないＨＴＭＬエディ
タで編集した場合について考える。まず、編集の結果、
ファイルの最終更新時刻が更新される。また、編集の過
程でコメントタグを削除するようなエディタの存在も考
えられる。

【００５５】また、上記の過程で再編集されたＨＴＭＬ
ファイルに対し、本実施形態を適用したエディタで再度
アクセスした際に更新の有無を検出する手順について、
図７のフローチャートとともに説明する。まず、対象と
なるＨＴＭＬファイルを読み込み(ステップ401)、コメ
ントタグを抽出する(ステップ402)。

【００５６】次に、コメントの内容から上述の"SHARP#B
ACKUP#INFO:"の記述を検索する(ステップ403)。もし検
出できなかった場合は、上記再編集過程で編集されたＨ
ＴＭＬファイル、もしくは新規作成されたＨＴＭＬファ
イルであると判断することが出来る。

【００５７】また、検出できた場合は、ファイルの最終
更新時刻を読み込み(ステップ404)、上記コメントタグ
から保存時刻を読み出して比較する(ステップ405)。も
し、ファイルの最終更新時刻と異なる場合は、上記再編
集過程で編集されたものであると判断することが出来
る。

【００５８】上記のようなファイル管理手法をＨＴＭＬ
エディタに実装することで、ＨＴＭＬの規格にファイル
更新検出用の特別なフィールドを定義することなく、容
易に更新の有無を検出することが可能となる。

【００５９】尚、本実施形態においては、ファイルの更
新時に必ず更新される情報として最終更新時刻を例に説
明したが、ファイルサイズやそれらの情報の組み合わせ
など他の情報を用いることも可能である。

【００６０】また、ＨＴＭＬファイルに限らず、本実施
形態のコメントタグのように、付加情報を記録するフィ
ールドを備えたファイルであれば、ＰＤＦファイルやＪ
ＰＥＧファイル、ＭＩＤＩファイルなどに適用しても、
同様の機能を実現出来ることは言うまでもない。

【００６１】次に、本発明の第３の実施形態として、Ｕ
ＤＦにおけるＦＥのDescriptor CRCの変更を検出するも
のについて、図８乃至図１０とともに詳細に説明する。

【００６２】すなわち、本実施形態は、所定の１ファイ
ルの中に、ファイルの更新時に必ず更新される情報をバ
ックアップ情報として、ファイル名と対応付けて書き込
むものであり、ここでは、更新をチェックする対象のフ
ァイルの前状態を保持する更新チェック用バックアップ
ファイルを用意する。

【００６３】最初に、本実施形態を適用したＵＤＦドラ
イバでファイルを更新する際の手順について、図８のフ
ローチャートとともに説明する。まず、通常のファイル
の更新処理を行う(ステップ501)。ここでは、上記第１
の実施形態と異なり、Implementation IdentifierとDes
criptor Tagの更新も行う。

【００６４】次に、Descriptor CRCの値を読み出し(ス
テップ502)、更新チェック用バックアップファイル"bac
kup.inf"を開き(ステップ503)、前記バックアップファ
イルに編集中のファイルのフルパスファイル名とＣＲＣ
の対応を記録する(ステップ504)。すでに同ファイルの
記録がある場合には更新する。

【００６５】前記バックアップファイルの記述例を図９
に示す。ここでは、16進２バイトのＣＲＣデータとファ
イルのフルパス名とが対応付けて記録されている。

【００６６】次に、上記の過程で記録されたファイル
を、本実施形態を適用していないＵＤＦドライバで編集
した場合について考える。ファイルを編集すれば、その
ＦＥに記録された値はそれぞれ更新され、Descriptor C
RCも異なった値になる。

【００６７】また、上記の過程で再編集されたファイル
に対し、本実施形態を適用したドライバで再度アクセス
した際に更新を検出する手順について、図１０のフロー
チャートとともに説明する。まず、媒体をマウントした
時点でバックアップファイル"backup.inf"を読み込む
(ステップ601)。

【００６８】アクセスしようとしたファイルがバックア
ップファイルに記録されたリストに含まれているかを判
定する(ステップ602)。もし、含まれていない場合、新
規作成されたものと判断され、ファイルの読み込みを開
始する(ステップ603)。

【００６９】含まれていた場合も、ファイルの読み込み
を開始し(ステップ604)、バックアップファイルに記録
されたＣＲＣとＦＥのDescriptor Tagに記録されたDesc
riptor CRCとを比較する(ステップ605)。２値が異なる
場合、ＦＥが以前と異なる情報を保持していることを示
し、ファイルの更新があったと判断することが出来る。

【００７０】尚、本実施形態においては、ファイルの更
新時に必ず更新される情報としてDescriptor CRCを例に
とって説明したが、第１の実施形態で示したようなInfo
rmation LengthやAccess Timeを使用することも可能で
ある。また、Descriptor Tag全体やこれら要素を組み合
わせたものでも可能である。

【００７１】さらに、本実施形態では、バックアップフ
ァイルというファイル形式で記録した例を示したが、論
理フォーマットを拡張するなどして、ファイルとは異な
る形式で記録しても良い。

【００７２】第１の実施形態では、ＣＲＣの演算対象に
Implementation Useフィールドがあるので、ＣＲＣ演算
後にImplementation Useフィールドに書き込むことが出
来ない。これに対し、本実施形態では、ＣＲＣ演算後に
バックアップファイル"backup.inf"に識別対象の情報と
してＣＲＣのバックアップを記録することにより、第１
の実施形態では実装できなかったＣＲＣなどの情報を識
別対象の情報に適用することが可能である。また、第１
の実施形態のImplementation Useフィールドにあたるフ
ィールドが用意されていない場合にも、本実施形態は有
効である。

【００７３】次に、本発明の第４の実施形態として、上
記第２の実施形態と同様に、ＨＴＭＬエディタによるＨ
ＴＭＬファイルの最終更新時刻の更新を検出するものに
ついて、図１１乃至図１３とともに詳細に説明する。

【００７４】すなわち、本実施形態は、所定の１ファイ
ルの中に、ファイルの更新時に必ず更新される情報をバ
ックアップ情報として、ファイル名と対応付けて書き込
むものであり、ここでは、更新をチェックする対象のフ
ァイルの前状態を保持する更新チェック用バックアップ
ファイルを用意する。

【００７５】最初に、本実施形態を適用したＨＴＭＬエ
ディタでＨＴＭＬファイルを更新する際の手順につい
て、図１１のフローチャートとともに説明する。まず、
通常のＨＴＭＬエディットを行い、保存する(ステップ7
01)。次に、ファイルの最終更新時刻を読み出し(ステッ
プ702)、更新チェック用バックアップファイル"backup.
inf"を開く(ステップ703)。

【００７６】また、更新したファイルのフルパスファイ
ル名と読み出した最終更新時刻とを登録する(ステップ7
04)。すでに同ファイルの記録がある場合には、更新す
る。

【００７７】前記バックアップファイルの記述例を図１
２に示す。ここでは、各ファイルの最終更新日時とファ
イルのフルパス名とが対応付けられている。

【００７８】次に、上記の過程で記録されたＨＴＭＬフ
ァイルを、本実施形態を適用していないＨＴＭＬエディ
タで編集した場合、ファイルの最終更新時刻が更新され
る。

【００７９】また、上記の過程で再編集されたＨＴＭＬ
ファイルに対し、本実施形態を適用したエディタでアク
セスした際に更新を検出する手順について、図１３のフ
ローチャートとともに説明する。まず、媒体をマウント
した時点でバックアップファイル"backup.inf"を読み込
む(ステップ801)。

【００８０】そして、アクセスしようとしたＨＴＭＬフ
ァイルがバックアップファイルに記録されたリストに含
まれているかを判定する(ステップ802)。もし、含まれ
ていない場合、新規作成されたものと判断され、ＨＴＭ
Ｌファイルの読み込みを開始する(ステップ803)。

【００８１】アクセスしようとしたＨＴＭＬファイルが
リストに含まれていた場合も、ＨＴＭＬファイルの読み
込みを開始し(ステップ804)、バックアップファイルに
記録された最終更新時刻とファイルの管理情報に記録さ
れた最終更新時刻とを比較する(ステップ805)。２値が
異なる場合、ＨＴＭＬファイルの管理情報が以前と異な
る情報を保持していることを示し、ファイルの更新があ
ったと判断することが出来る。

【００８２】本実施形態では、第２の実施形態のように
システムの動作による時間の誤差を考える必要はない。
また、ＨＴＭＬ規格は容易にコメントを追加することが
出来るが、フィールドの大きさが限定されるなどバック
アップ情報を記録する領域が充分になかった場合や、Ｈ
ＴＭＬのタグを解析する手間を省きたい場合などに、本
実施形態は有効である。

【００８３】尚、本実施形態においては、ファイルの更
新時に必ず更新される情報として最終更新時刻を例にと
って説明したが、ファイルサイズやそれらの情報の組み
合わせなど他の情報を適用することも可能である。ま
た、ＨＴＭＬファイルに限らず、ＰＤＦファイルやＪＰ
ＥＧファイル、ＭＩＤＩファイルなどに適用しても、同
様の機能を実現出来ることは言うまでもない。

【００８４】

【発明の効果】本発明のファイル管理方法によれば、特
殊なフィールドを追加することなく、自由な書き込みが
許可されたフィールドに、ファイルの更新時に必ず更新
される情報をバックアップ情報として書き込むため、こ
のファイルの更新時に必ず更新される情報とバックアッ
プ情報とを比較することで、容易にファイルの更新の有
無を検出することができる。

【００８５】また、上述のような自由な書き込みが許可
されたフィールドが存在しない場合であっても、前記フ
ァイルの更新時に必ず更新される情報をバックアップ情
報として、ファイル名と対応付けて所定の１ファイルの
中に書き込むことにより、容易にファイルの更新の有無
を検出することが可能となる。

【図面の簡単な説明】

【図１】本発明の第１の実施形態におけるファイルの更
新手順を示すフローチャートである。

【図２】本発明の第１の実施形態におけるImplementati
on Identifierを示す説明図である。

【図３】本発明の第１の実施形態におけるファイル更新
の検出手順を示すフローチャートである。

【図４】本発明の第１の実施形態をバックアップ機能に
利用した場合を示す説明図である。

【図５】本発明の第２の実施形態におけるファイルの更
新手順を示すフローチャートである。

【図６】本発明の第２の実施形態におけるバックアップ
情報の記録例を示す説明図である。

【図７】本発明の第２の実施形態におけるファイル更新
の検出手順を示すフローチャートである。

【図８】本発明の第３の実施形態におけるファイルの更
新手順を示すフローチャートである。

【図９】本発明の第３の実施形態におけるバックアップ
ファイルの記録例を示す説明図である。

【図１０】本発明の第３の実施形態におけるファイル更
新の検出手順を示すフローチャートである。

【図１１】本発明の第４の実施形態におけるファイルの
更新手順を示すフローチャートである。

【図１２】本発明の第４の実施形態におけるバックアッ
プファイルの記録例を示す説明図である。

【図１３】本発明の第４の実施形態におけるファイル更
新の検出手順を示すフローチャートである。

【図１４】ＵＤＦファイルシステムにおけるファイルの
記録方式を示す説明図である。

【図１５】ＵＤＦファイルシステムにおけるディレクト
リの記録方式を示す説明図である。

【図１６】File Entryを示す説明図である。

【図１７】Allocation Descriptorを示す説明図であ
る。

【図１８】Extent Lengthのフォーマットを示す説明図
である。

【図１９】Type of the Extentを示す説明図である。

【図２０】File Identifier Descriptorを示す説明図で
ある。

【図２１】Information Control Blockを示す説明図で
ある。

【図２２】Descriptor Tagを示す説明図である。

【図２３】ＵＤＦファイルシステムにおける記録例を示
す説明図である。

【符号の説明】

101 ドライバ 102 バックアップ作成回路 103 ドライバ 104 更新検出回路 105 バックアップ更新回路

───────────────────────────────────────────────────── フロントページの続き (72)発明者山口孝好大阪府大阪市阿倍野区長池町22番22号シャープ株式会社内Ｆターム(参考） 5B082 DE06 EA01 GA14 5D110 AA17 DA01 DA06 DA11 DA15 DA17 DB03 DC05 DC16 DC28

Claims

【特許請求の範囲】

【請求項１】ファイルの更新時に必ず更新される情報
を含む管理情報を用いて、データと前記管理情報から構
成されるファイルを管理するファイル管理方法におい
て、前記管理情報内の自由な書き込みが許可されたフィール
ドに、前記ファイルの更新時に必ず更新される情報をバ
ックアップ情報として書き込むことを特徴とするファイ
ル管理方法。
【請求項２】ファイルの更新時に必ず更新される情報
を含む管理情報を用いて、データと前記管理情報から構
成されるファイルを管理するファイル管理方法におい
て、前記データ内の自由な書き込みが許可されたフィールド
に、前記ファイルの更新時に必ず更新される情報をバッ
クアップ情報として書き込むことを特徴とするファイル
管理方法。
【請求項３】ファイルの更新時に必ず更新される情報
を含む管理情報を用いて、データと前記管理情報から構
成されるファイルを管理するファイル管理方法におい
て、所定の１ファイルの中に、前記ファイルの更新時に必ず
更新される情報をバックアップ情報として、ファイル名
と対応付けて書き込むことを特徴とするファイル管理方
法。
【請求項４】前記請求項１乃至３のいずれかに記載の
ファイル管理方法において、前記ファイルの更新時に必ず更新される情報と前記バッ
クアップ情報とを比較することにより、ファイルの更新
の有無を検出することを特徴とするファイル管理方法。