(57)【要約】【課題】  従来の検査方法は、検査のための冗長データそのものがファイルシステム自体に組み込まれているため、データの書き換えに応じて冗長データも変わり、データが改変されたかどうかを知る手段としては利用することができない。【解決手段】  データ領域５にコンテンツデータ２５とアプリケーション管理情報２６を記録する際に、コンテンツデータ２５のファイル管理情報２７とアプリケーション管理情報２６のファイル管理情報２８とがルートディレクトリ領域４に記録される。本発明では、ファイル管理情報２７及び２８から検査データを生成し、それを記録媒体の特定の領域に書き込む。その後、記録媒体を装置にマウントする際に、記録媒体のファイルシステムから読み取ったファイル管理情報２６及び２８を特定の関数で変換した値を算出し、記録媒体の特定の領域から読み込んだ検査データと一致しているかどうか比較する。【選択図】            図４
2005222525.tif 000002
【特許請求の範囲】
【請求項１】
記録媒体に、データを記録する領域であるデータ領域と、このデータ領域のどの領域を使用しているかを少なくとも示す管理領域と、前記データ領域に記録するデータのファイル管理情報を示すディレクトリとを設けて、前記記録媒体に記録するデータを管理するファイルシステムに用いられ、前記データ領域に記録されているデータの変更を検出するための検査データを前記記録媒体に記録するファイルシステムの検査データ記録方法において、
前記管理領域に記録されたデータを予め定めた特定の関数で一意に定まる値に変換して、第１の検査データを生成する第１の生成ステップと、
前記ディレクトリに記録されたデータを前記特定の関数で一意に定まる値に変換して、第２の検査データを生成する第２の生成ステップと、
前記第１及び第２の検査データを前記記録媒体上の所定の領域に記録する記録ステップと
を含むことを特徴とするファイルシステムの検査データ記録方法。
【請求項２】
前記ファイルシステムはＦＡＴファイルシステムであり、前記管理領域はＦＡＴであることを特徴とする請求項１記載のファイルシステムの検査データ記録方法。
【請求項３】
前記ファイルシステムはＵＤＦであり、前記管理領域はスぺースビットマップであることを特徴とする請求項１記載のファイルシステムの検査データ記録方法。
【請求項４】
前記所定の領域は、マスター・ブート・レコード、ブートセクタ、パーティション構造の隙間、ヒドン・セクタのうちの少なくとも１つであることを特徴とする請求項１乃至３のうちいずれか一項記載のファイルシステムの検査データ記録方法。
【請求項５】
記録媒体にファイル管理情報を記録するファイルシステムに用いられ、前記記録媒体に記録されているデータの変更を検出するファイルシステムのデータ変更検出方法において、
前記記録媒体上の所定の領域に予め記憶された検査データであり、前記ファイル管理情報を予め定めた特定の関数で一意に定まる値に変換した検査データを読み込む読み込みステップと、
前記ファイル管理情報を前記特定の関数で変換した一意に定まる値を算出する算出ステップと、
前記読み込みステップにより読み込んだ検査データと前記算出ステップにより算出した値とを比較することにより、前記記録媒体に記録されているデータの変更を検出する検出ステップと
を含むことを特徴とするファイルシステムのデータ変更検出方法。
【請求項６】
前記記録媒体は、データを記録する領域であるデータ領域と、このデータ領域のどの領域を使用しているかを示す管理領域と、前記データ領域に記録するデータのファイル管理情報を示すディレクトリとを有し、
前記検査データは、前記管理領域に記録されたデータを前記特定の関数で一意に定まる値に変換した第１の検査データと、前記ディレクトリに記録されたデータを前記特定の関数で一意に定まる値に変換した第２の検査データとを含み、
前記算出ステップは、前記管理領域に記録されたデータを前記特定の関数で変換した一意に定まる第１の値と、前記ディレクトリに記録されたデータを前記特定の関数で変換した一意に定まる第２の値とを算出し、
前記検出ステップは、まず前記第１の検査データと前記第１の値とを比較することにより、前記記録媒体に記録されているデータの変更を検出することを特徴とする請求項５記載のファイルシステムのデータ変更検出方法。
【請求項７】
前記検出ステップは、前記第１の検査データと前記第１の値とを比較して両者が一致した場合に、前記第２の検査データと前記第２の値とを比較することにより、前記記録媒体に記録されているデータの変更を検出することを特徴とする請求項６記載のファイルシステムのデータ変更検出方法。
【請求項８】
前記ファイルシステムはＦＡＴファイルシステムであり、前記管理領域はＦＡＴであることを特徴とする請求項５乃至７のうちいずれか一項記載のファイルシステムのデータ変更検出方法。
【請求項９】
前記ファイルシステムはＵＤＦであり、前記管理領域はスぺースビットマップであることを特徴とする請求項５乃至７のうちいずれか一項記載のファイルシステムのデータ変更検出方法。
【請求項１０】
前記所定の領域は、マスター・ブート・レコード、ブートセクタ、パーティション構造の隙間、ヒドン・セクタのうちの少なくとも１つであることを特徴とする請求項５乃至９のうちいずれか一項記載のファイルシステムのデータ変更検出方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はファイルシステムの検査データ記録方法及びデータ変更検出方法に係り、特に可換型記録媒体にデータを記録再生する際の管理構造や管理方式を規定するファイルシステムにおいて、可換型記録媒体におけるデータの書き換えの有無を検出するのに好適なファイルシステムの検査データ記録方法及びデータ変更検出方法に関する。
【背景技術】
【０００２】
デジタルカメラ、デジタルビデオカメラ等の携帯型のＡＶ機器などに、データを保存する目的でメモリカードやカード型のハードディスクドライブ（ＨＤＤ）、あるいは記録型ＣＤ（Compact Disk）やＤＶＤ（Digital Versatile Disk）などの着脱可能な汎用の可換型記録媒体が用いられる場合がある。このような可換型記録媒体は汎用の記録媒体であるため、携帯機器から取り出し、直接又はアダプタ等を介して、パーソナルコンピュータ（以下、ＰＣと記す）に接続してデータを読み書きすることが一般に可能である。
【０００３】
カード型の記録媒体では、デファクトスタンダードであるＦＡＴ−１２／１６／３２等のＦＡＴ（File Allocation Table）系のファイルシステムによってデータを管理することが多い。また、ＣＤ−Ｒ、ＣＤ−ＲＷ等の記録型ＣＤではＩＳＯ（国際標準化機構）が定めたＣＤ−ＲＯＭの標準論理フォーマットであるＩＳＯ ９６６０、又は光ストレージ向け汎用ファイルフォーマットであるＵＤＦ（Universal Disk Format）が、また、ＤＶＤ−Ｒ／−ＲＷ／＋Ｒ／＋ＲＷ／ＲＡＭ等の記録型ＤＶＤでは、ＵＤＦが一般に用いられる。
【０００４】
また、交換型の記録媒体を備えず、内蔵の不揮発性メモリ等にデータを記録する機器でも、ＵＳＢ（Universal Serial Bus）のマスストレージクラス等の手段を用いて、ＰＣに接続されたリムーバルディスクとして取り扱うことができるものが存在する。これらのファイルシステムは汎用のファイルシステムであるため、ＰＣに特別なドライバを導入することなく記録媒体上のデータを自由に操作することができ、ユーザーの利便性を図っている。
【０００５】
ところが、このようなＰＣによる自由な操作によって、携帯機器側で予期しないデータの改変が発生することがある。例えば、ＰＣ側で記録済みのデータを書き換えたり、削除したり、新しくデータを書き込んだりする場合がこれに相当する。このような場合でも携帯機器側のデータ管理方法がファイルシステムにのみ依存する場合は、ファイルシステム自体の整合性はとれているので問題はない。
【０００６】
ところが、携帯機器側で記録内容に関して独自の管理情報を管理している場合は、ファイルシステムと独自の管理情報の間で不整合が発生する場合がある。例えば、内容の一覧を管理するテーブルを持っている場合、ＰＣ上で新しく追加された内容がこのテーブルに反映されない。また、このテーブルに内容の作成日、更新日、サイズなどが記録されている場合、ＰＣ側で内容を変更すると、更新日、サイズなどが一致しなくなる。
【０００７】
また、ファイルの物理的な配置情報を携帯機器側で管理していた場合、ＰＣ側でファイルの改変を行わなかったとしても、スキャンディスク等の再配置ツールの使用によって、論理的には同じ内容であっても物理的には変わってしまうため、情報の不整合が発生する場合がある。
【０００８】
そこで、ファイルシステム自体の整合性をチェックするために、ファイル管理情報自体に冗長性をもたせ、ファイル内容を反映するデータとしてパリティ等の情報を冗長データとしてファイル管理情報に含める方法が従来より知られている（例えば、特許文献１参照）。この従来の方法は、ファイルシステム自体の整合性をチェックするものであり、ファイルデータから求めた冗長データと記録されている冗長データを比較することによって、ファイルデータに異常がないかどうかを調べることができる。
【０００９】
【特許文献１】特開平１１−１３４２３６号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、上記の従来の方法では、検査のための冗長データそのものがファイルシステム自体に組み込まれているため、データの書き換えに応じて前記冗長データも変わり、データが改変されたかどうかを知る手段としては利用することができない。また、生成される冗長データはファイルデータそのものから生成されるので、冗長データを生成するのに必要な処理ステップ数、処理時間はファイルサイズの大きさに依存することになり、一定ではない。
【００１１】
これは検査についても同様であり、この従来の方法を適用してファイルシステムのマウント時やアンマウント時に検査を実施すると、記録データの増加に従って、システムの起動や終了時間が著しく増大するという欠点がある。特に、ＡＶストリームデータのように、ギガバイトオーダーの大きいサイズのファイルでは、冗長データの生成や検査に極めて長い時間が必要である。
【００１２】
また、ファイルの数が多くなった場合もファイル毎に処理する必要があるため、同様に処理時間が増大する。更に、この方法で生成される特別な冗長データは、単なるパリティやチェックサム等の簡単な評価値であるため、データが改変されたかどうかを確認する手段に用いるには不十分である。
【００１３】
本発明は以上の点に鑑みなされたもので、可換型記録媒体に対して他の機器で行われた記録内容の書き換えを簡単に検出し得、もって、ファイルシステムと独立した任意の管理情報の整合性の更新の必要性を迅速に判断できるファイルシステムの検査データ記録方法及びデータ変更検出方法を提供することを目的とする。
【００１４】
また、本発明の他の目的は、可換型記録媒体に対して他の機器で行われた記録内容の書き換えを、ファイルサイズに依存することなく、迅速に検出し得るファイルシステムの検査データ記録方法及びデータ変更検出方法を提供することにある。
【課題を解決するための手段】
【００１５】
本発明は上記の目的を達成するため、図１（ａ）の原理説明用フローチャートに示すように、ファイル管理情報を予め定めた特定の関数で一意に定まる値に変換し、これを検査データとして記録媒体上の所定の領域に記録する（ステップＳ１）。その後、記録媒体を装置にマウントした際に、図１（ｂ）の原理説明用フローチャートに示すように、検査データが配置してあるはずの所定の領域のデータを検査データとして読み込み（ステップＳ１１）、記録媒体のファイルシステムから読み取ったファイル管理情報を特定の関数で変換した値を算出する（ステップＳ１２）。そして、記録媒体の所定の領域から読み込んだ検査データと、ステップＳ１２で算出した値とが一致しているかどうか比較し（ステップＳ１３）、その比較結果に基づき、ファイルが変更されているかどうか検出する（ステップＳ１４、Ｓ１５、Ｓ１６）。
【００１６】
この発明では、ファイル管理情報を予め定めた特定の関数で一意に定まる値に変換し、これを記録媒体の現在の記録された状態を反映する検査データとして記録媒体上の特定の領域に、通常のファイルシステムの管理外の検査データとして記録しておく。
【００１７】
上記の検査データを記録された記録媒体が、このような管理を行っていない他の機器に接続されて使用されたときに、書き換え、追記、削除、新規作成等のファイルの変更（記録内容の改変）が行われると、前記検査データと記録内容との不整合が発生する。
【００１８】
そこで、本発明では、記録媒体のマウント時に記録媒体のファイルシステムの管理情報を検査データと同じ特定の関数を使って変換し、この変換して得られた値と記録媒体上に記録されている検査データとを比較することによって、ファイルの変更の有無を検出することができる。
【００１９】
更に、比較結果が不一致のときは、ファイルが変更されていると判断して、第２のステップで算出した値を、記録媒体上の所定の領域に検査データとして更新記録する新たなステップを含むことにより、ファイルシステムと独立した任意の管理情報とを常に整合させることができる。
【発明の効果】
【００２０】
本発明によれば、記録媒体のマウント時に記録媒体のファイルシステムの管理情報から検査データ生成時に使用した特定の関数を用いて算出したデータの値を、記録媒体の所定の領域から読み取った検査データと比較するようにしたため、可換型記録媒体に対して他の機器で行われた記録内容の書き換えをファイルサイズに依存することなく、迅速に検出することができ、ファイルシステムと独立した任意の管理情報の整合性の更新の必要性を迅速に判断できる。
【発明を実施するための最良の形態】
【００２１】
次に、本発明を実施するための最良の形態について図面と共に説明する。
【００２２】
（１）ＦＡＴファイルシステムへの適用
（ａ）ＦＡＴファイルシステム
まず、本発明を適用し得るファイルシステムの一例として、汎用的でデータ交換性に優れるという特長のあるＦＡＴファイルシステムについて説明する。図２はＦＡＴファイルシステムの構造を説明するための図で、全体は同図（ａ）に示すように、システム領域１、２つのＦＡＴ２、３、ルートディレクトリ領域４及びデータ領域５から構成される。以後、ＦＡＴファイルシステムをＦＡＴ−ＦＳと略記する。
【００２３】
データ領域５はクラスタと呼ばれる連続する複数セクタ単位に分割して使用され、クラスタと１対１に対応するエントリを持つ管理テーブルであるＦＡＴを使ってファイルの配置情報を管理する。各クラスタには、順番に番号（クラスタ番号）が振られる。
【００２４】
図２（ａ）に２及び３で示すように、ＦＡＴは２つあって、１つは予備である。また、システム領域１にはＯＳ（オペレーティングシステム）のブートコードやファイルシステム全体の管理情報などが格納されている。記録データはルートディレクトリ領域４内のディレクトリ上でファイルとして記録され、ルートディレクトリを頂点とする任意の木構造からなる階層構造を構成する。
【００２５】
ルートディレクトリ以下のディレクトリはサブディレクトリと呼ばれ、１つの特殊なファイルとして管理される。ディレクトリの構造はルートディレクトリもサブディレクトリも同じで、ディレクトリエントリのテーブルになっている。１つのディレクトリエントリには、記録データの内容を表すファイル名等の情報と共に、データの先頭が格納されているクラスタのクラスタ番号をファイルのエントリ情報として記録する。
【００２６】
ディレクトリ内のデータ毎のファイル管理情報には、ファイルのエントリ情報の他に、一般に、最終更新日時、ファイルサイズ、読み書きや実行等に関する許可／不許可を示すファイル属性等の情報が含まれる。
【００２７】
ＦＡＴはクラスタ番号のテーブルになっており、図２（ｂ）に示すように、ファイルエントリで示されるクラスタ番号に対応するエントリには、ファイルデータの連結状態を示すために次のクラスタ番号が記録され、複数のクラスタに分散されたデータのつながり（クラスタチェイン）を管理することができる。ファイルの最後のクラスタには最終クラスタであることを示す識別子（ＦＡＴ１６の場合、ＦＦＦＦ）が記録される。このように、ＦＡＴ−ＦＳにおいては、ファイルはディレクトリとＦＡＴの２つを用いて管理される。
【００２８】
なお、クラスタ内に欠陥セクタがあると、そのクラスタは使用不可能な領域であることを示す識別子がＦＡＴに記録されるので、このクラスタは使用しない。従って、たとえ１セクタでも不良の領域があった場合は、そのセクタが属するクラスタ全体が使用不可能となるため、クラスタサイズが大きいほど効率的な使用の妨げになる。
【００２９】
ＦＡＴ上のクラスタエントリの内容はクラスタ番号を意味するので、そのエントリに与えるビット数によって、ファイルシステム全体で扱えるクラスタの数が決まる。ＦＡＴ−ＦＳには、そのビット数の違いで幾つかのバージョンがあり、ＦＡＴ１２、ＦＡＴ１６、ＦＡＴ３２ファイルシステムと呼ばれることがある。
【００３０】
ＦＡＴ１２、ＦＡＴ１６、ＦＡＴ３２などの数字の部分はクラスタ番号のビット数を示し、それぞれ１２ビット、１６ビット、３２ビットを意味している。従って、各ファイルシステムが扱えるクラスタの総数は、それぞれおよそ２の１２乗、２の１６乗、２の３２乗個程度になる。実際には、予約番号があるために、これらの数字より若干小さい値となる。図２（ｂ）に示すＦＡＴはＦＡＴ１６の例である。
【００３１】
（ｂ）検査データの生成
本発明の検査データは、記録媒体上のデータ管理情報に対して生成する。本発明をＦＡＴ−ＦＳに対して適用する場合は、ＦＡＴとディレクトリに対して検査データを生成すればよい。ＦＡＴの場合は、少なくともディレクトリ情報に対して、検査データを生成すればよいが、ディレクトリ構造が深い場合は、すべてのディレクトリをチェックするのに時間がかかるため、ディレクトリだけでなく、ＦＡＴに対しても検査データを生成するのが有効である。
【００３２】
逆に、ＦＡＴだけでは、ファイルの一部書き換えがあった場合に変化を検出できないため、ＦＡＴを利用する際には、ディレクトリの検査データと併用する必要がある。すなわち、改変をチェックする際は、まず、ＦＡＴ部分の検査データをチェックし、もし、検査データが一致した場合は、確認のためディレクトリの検査データをチェックする。
【００３３】
データの新規作成、削除、あるいは元のファイルのサイズが変わるような改変に対しては、ＦＡＴの内容が変化するため、ディレクトリを検索しなくともＦＡＴをチェックした段階で、改変を検出することができる。ディレクトリは、記録媒体上の任意の場所に散在している可能性があるが、ＦＡＴは、ディスク上の特定箇所に集中して配置されているため、高速にアクセスでき、その結果迅速な改変チェックができることになる。
【００３４】
（ｃ）詳細な説明
図３は本発明になるファイルシステムのデータ変更検出方法の一実施の形態が適用されるファイルシステムのシステム構成図を示す。同図において、対応機器は、本発明を適用した機器であり、本発明の動作を制御する中央処理装置（ＣＰＵ）１１が、その実行コードを保存してあるＨＤＤ１２に、メインバス１３、ＡＴＡ／ＡＴＡＰＩ  Ｉ／Ｆ１４を介して接続されており、また、実行コードを展開してＣＰＵ１１で実行するためのメインメモリ１５が機器内部のメインバス１３を介して接続されている。
【００３５】
ＡＴＡ／ＡＴＡＰＩ  Ｉ／Ｆ１４には、記録型ＤＶＤ、ＣＤに対応する書込型ドライブ１６を接続することもできる。メインバス１３にはＰＣＭＣＩＡ  Ｉ／Ｆ１７が接続してあり、メモリカードやカード型ＨＤＤ等の着脱可能な可換型記録媒体（リムーバブルメディア）１８をＰＣカードソケット１９に装填することにより、可換型記録媒体１８に対してデータの書き込み、読み込みを行うことができる。
【００３６】
その他、メインバス１３にはＤＭＡコントローラ２０が接続され、各デバイス間のＣＰＵ１１を介さないデータ転送をサポートしており、大量のデータ転送が必要な場合に利用することができる。
【００３７】
コンテンツデータをカード型記録媒体に記録する場合は、図示しない別なＩ／Ｆを介して直接、または、一旦メモリ上に蓄えられた後、必要なら加工されてＰＣＭＣＩＡ  Ｉ／Ｆ１７を介してカード型記録媒体に記録される。再生する場合は、その逆である。記録型ＤＶＤやＣＤ等のディスクメディアに対しては、同図では、ＡＴＡ／ＡＴＡＰＩ  Ｉ／Ｆ１４を介してコンテンツデータが記録再生される。
【００３８】
また、対応機器の特徴として、検査データを生成する検査データ生成手段を持つ。この検査データ生成手段は、検査データの対象となるデータに対して所定の計算を行って、その結果をＣＰＵ１１に返す。この検査データ生成手段は、図３に２１、２２で示すように、記録媒体のＩ／ＦであるＡＴＡ／ＡＴＡＰＩ  Ｉ／Ｆ１４内やＰＣＭＣＩＡ  Ｉ／Ｆ１７内にハードウェアである検査データ生成回路として設けてもよいし、データを一旦メモリに取り込むなどして、ＣＰＵ１１で計算して求めてもよい。
【００３９】
検査データ生成回路２１、２２を設けた場合は、データの転送と同時に検査データを計算することができる。他方、ＣＰＵ１１が検査データ生成手段を構成する場合は、計算結果はＣＰＵ１１自身が持つので、ＣＰＵ１１に返す必要はなくなる。
【００４０】
なお、記録媒体とのＩ／Ｆとして、ＡＴＡ／ＡＴＡＰＩ  Ｉ／Ｆ１４やＰＣＭＣＩＡ  Ｉ／Ｆ１７で説明したが、本発明は勿論これらに限られるものではなく、ＳＣＳＩ、ＵＳＢ、ＩＥＥＥ１３９４など、記録媒体の読み書きを行うのに必要なＩ／Ｆ機能を備えるものなら何でもよい。
【００４１】
今、対応機器において何らかのコンテンツデータを、対応機器に装着されているリムーバブルメディアに記録したとする。このとき、対応機器は、このコンテンツデータの利用に際して機器に特有なアプリケーションに有用な情報を併せて記録するものとする。この情報をアプリケーション管理情報と呼ぶことにする。
【００４２】
すなわち、図４に示すように、データ領域５にはコンテンツデータ２５とアプリケーション管理情報２６が記録されるが、これらの２つのデータを記録する際に、コンテンツデータ２５のファイル管理情報２７とアプリケーション管理情報２６のファイル管理情報２８とがルートディレクトリ領域４に記録される。これら２つのファイル管理情報２７及び２８には、配置情報、作成日時、ファイルサイズなどのファイル固有の情報（ファイル管理情報）が含まれる。
【００４３】
本発明では、これら２つのファイル管理情報２７及び２８から検査データを生成する。
すなわち、ルートディレクトリ領域４の内容を検査データ生成回路２１又は２２に入力し、特定の関数を用いて検査データを生成させる。具体的には、ルートディレクトリを記録媒体に書き込むときに、検査データ生成回路２１、２２を動作させて検査データを生成させ、ルートディレクトリの書き込み終了時に、生成された検査データを図３のＣＰＵ１１に返す。ＣＰＵ１１は得られた検査データを改めて、記録媒体の特定の領域に書き込む。
【００４４】
なお、図４のスイッチＳＷはＦＡＴ２の検査データを生成する場合は、ＦＡＴ２側に切り換えられ、ＦＡＴ２にクラスタチェインとして記録された、２つのファイル２５及び２６の配置情報を含むデータを検査データ生成回路２１（２２）へ供給し、ルートディレクトリ４の検査データを生成する場合は、ルートディレクトリ側に切り換えられ、ルートディレクトリ４からの２つのファイル管理情報２７及び２８を検査データ生成回路２１（２２）へ供給する。この場合、ファイルシステムを管理する情報毎に、検査データを生成して個別に管理してもよいし、両者をあたかも一つの検査対象データとして（一つのファイルとして）検査データを生成してもよい。
【００４５】
検査データの生成方法は、データ内容が変わったときに確実にその変化が検出できるようなものがよく、複数の可能性に対して同じ結果が得られる可能性が高いパリティのような単純なものは不適当である。本発明の一実施の形態では、この検査データを生成するために使用する特定の関数として、一方向ハッシュ関数を用いる。
【００４６】
一方向ハッシュ関数とは、任意の長さのメッセージを決められた長さのメッセージに圧縮する関数で、入力するデータを僅かでも変更すると、返される整数値が必ず変わることを期待できる。一般には、データの改竄のチェックなどのセキュリティ用途によく用いられる。また、ハッシュ値は逆変換によって、元のデータを復元することができないため、検査データから元のデータを知られたくない場合にも有用である。
【００４７】
そのほか簡単なものでは、サイクリック・リダンダンシイ・チェックコード（ＣＲＣ）などの簡単な演算でも十分な効果を得ることができる。この時、ファイルシステムなどでもよく利用されるものと同じ生成多項式を用いると、複数の演算をサポートする必要がなく、都合がよい。そのような多項式の例として、ＵＤＦでディスクリプタの検査に用いられる、次の１６ビット生成多項式がある。
【００４８】
Ｘ１６＋Ｘ１２＋Ｘ５＋１  （ＩＴＵ−Ｔ Ｖ．４１に規定されている）
これは、ＡＴＡ／ＡＴＡＰＩのＵＤＭＡ転送で転送データのエラー検出に用いられる生成多項式とも同じである。この場合は、転送時にＣＲＣの初期値が規定されているので、本発明に用いるＣＲＣでも同じ初期値と生成多項式を用いることで、ＵＤＭＡ転送で利用するＣＲＣ生成手段を共通化できるメリットがある。
【００４９】
また、検査データを生成するときに用いる２つのファイル管理情報２７及び２８は、それぞれ５１２バイト単位とすることにより、データ転送に伴って計算を行うことができて都合がよい。図４においては、ルートディレクトリ領域４のサイズがｎセクタ（ｎは自然数）であり、１セクタは５１２バイトである。
【００５０】
更に、検査対象となるデータ（ファイル管理情報２７及び２８）が、複数のセクタ（１セクタ＝５１２バイトとする）にまたがっている場合、連続するセクタ単位（エクステント）毎に検査データを求めるようにすると、必要なアクセス毎に検査データの生成を行うことができて効率が良い。
【００５１】
図５にその様子を示す。同図において、検査対象となるファイル管理情報が複数（図５では５つ）のセクタにまたがっており、例えば、それらを２つのエクステントに分かれて記録したものとすると、エクステント毎に読み出しコマンドを設定するため、読み出し毎に検査データを利用できる仕組みを用意しておくことにより、アクセス終了と同時に検査データを取得することができて都合がよい。図５では、連続する最初の２つのセクタからなる第１のエクステントのファイル管理情報から検査データ＃１を生成し、残りの連続する３つのセクタからなる第２のエクステントのファイル管理情報から検査データ＃２を生成する。
【００５２】
以上のようにして求めた検査データは、記録媒体上で通常のファイルシステムがデータとして管理しない領域に記録される。この場合は、幾つかの利点がある。一つは、ユーザーやファイルシステムからそのデータの存在が見えないため、不用意に改変される恐れがないということである。もう一つは、追記型記録媒体などで、検査データの記録位置を最終セッション内の特定位置に記録しておくことにしておけば、非対応機器で記録した際に検査データが記録されないため、検査データの存在をチェックするだけで非対応機器での改変を検出できることである。
【００５３】
次に、検査データが記録される記録媒体の特定の領域について図６と共に説明する。図６において、検査データ記録領域３１は、ＨＤＤで用いられるＭＢＲ（Master Boot Record）４１内に設けられている。ＭＢＲ４１の最終の２バイトはマジックナンバー（固定値０ｘ５５ａａ）で、その直前の６４バイトはパーティションテーブル４２なので、それらを除いた領域に検査データ記録領域３１が記録される。
【００５４】
また、検査データ記録領域３２は、ＨＤＤで用いられるブートセクタ４３内に設けられている。ＦＡＴファイルシステムでは、ブートセクタ４３の先頭３バイト４４にはブートコードがある場合はジャンプ命令が書き込まれている。また、Ｗｉｎｄｏｗｓ  ９５／９８（Ｗｉｎｄｏｗｓは登録商標）においては、続く８バイト（名称フィールド）４５をマウント時に書き換えてしまう場合がある。
【００５５】
その後に続く部分は０ｘ３ｄまでＦＡＴファイルシステムのパラメータが記録されている領域である。また、最終２バイトはＭＢＲと同様にマジックナンバー（固定値０ｘ５５ａａ）である。ブートセクタ４３内において、これらの領域４４、４５と最後の２バイトを除く領域に検査データ記録領域３２が形成される。
【００５６】
また、検査データ記録領域３３は、ＨＤＤで用いられるパーティション構造の隙間に形成されている。検査データ記録領域３３は、パーティションの前又は後の専用領域に形成されている。更に、検査データ記録領域３４は、ＦＡＴファイルシステムで設定可能なヒドン・セクタ（ｈｉｄｄｅｎ  ｓｅｃｔｏｒ）を利用した例である。ここで、ヒドン・セクタ・カウントで指定されるセクタ数は、先頭からブートセクタの直前までのセクタ数である。検査データは上記の検査データ記録領域３１、３２、３３、３４のいずれかに記録される。
【００５７】
次に、ユーザーが対応機器からリムーバブルメディアを取り出し、ＰＣに装着した場合について説明する。ＰＣでは、デファクトスタンダードであるＦＡＴファイルシステムを介して、前記二つのファイル（コンテンツデータ２５とアプリケーション管理情報２６）にアクセスすることができる。これらのファイルの読み出しを行っている場合は、内容が変化しないため問題ないが、アプリケーションを知らないＰＣ上では、コンテンツデータ２５の削除、更新、新規ファイルの記録など書き込みを伴う変更を行うと、アプリケーション管理情報２６に書いてある情報と、コンテンツの実際との対応がとれなくなってしまう。
【００５８】
この場合は、ユーザーがＰＣから前記リムーバブルメディアを取り出し、対応機器に再装着すると、アプリケーション管理情報とコンテンツの整合性がとれなくなっているため、そのままではアプリケーション管理情報を使用することはできない。従来は、この不整合状態が発生していることを事前に知ることができないため、アプリケーション管理情報２６を信じてコンテンツの操作を行うことになり、矛盾に気付くのが遅れたり、場合によってはコンテンツデータを破壊することもあり得る。
【００５９】
これに対し、本実施の形態では、ＰＣから取り出したリムーバブルメディアを対応機器に再装着する際、すなわち、マウント時にリムーバブルメディアに記録されている前記検査データとファイル管理情報との整合性をチェックすることによって、改変を検出し、アプリケーション管理情報を使用に先立って更新する必要があるかどうかを判断することができる。
【００６０】
すなわち、本実施の形態では、マウント時にリムーバブルメディアの予め定めておいた格納場所から記録済みの検査データを読み出して、一旦メモリ上に保存しておく。次に、ＦＡＴとルートディレクトリを読み出し、その読み出した情報を用いて検査データを前記方法と同様にして求め、先にメモリに保存しておいた検査データと比較する。この順序は逆でもよい。
【００６１】
もし、記録済みの検査データの読み出し値と、ＦＡＴとルートディレクトリから読み出した情報から算出した検査データの両者が一致すれば、改変は行われていないと判断し、待機状態に移行する。もし、両者が不一致であれば、改変が行われていると判断し、アプリケーション管理情報２６を再構築する。アプリケーション管理情報２６を更新したら、新しい検査データを前述した方法により生成して記録する。このように、本実施の形態では、対応機器では、記録媒体をマウントする際に検査データとファイルシステムの管理情報を常に整合性が保たれた状態にする。
【００６２】
なお、両者が不一致である場合、記録媒体にもともと検査データが記録されていなかった場合も考えられる。これは、この記録媒体が一度も対応機器で使われたことがないことを意味する。このときは、アプリケーション管理情報２６が存在しないため、これを再構築しようとした際に、この記録媒体が一度も対応機器で使われたことがないことを判断できるため、以後の不必要な動作（アプリケーション管理情報２６の新規作成や再構築）を中止することができる。
【００６３】
この記録媒体が一度も対応機器で使われたことがないことを判別するために、所定の領域に検査データが対応機器で記録されたことを示す識別子を含む情報を記録するようにしてもよい。この識別子を含む情報は、ファイルシステムの管理領域外に配置してもよいし、ファイルシステムの管理領域内にファイルとして配置してもよい。ファイルシステムの管理領域外の配置する場合は、検査データと同じ領域に配置するようにすれば、検査データを読み込んだ時に、同時に識別子の有無を判断できるので、この記録媒体が一度も対応機器で使われたことがない場合は、直ちにそれを判断することができるという優れた特徴がある。
【００６４】
次に、検査データのデータ形式について説明する。検査データのデータ形式は、対応するエクステント情報と関連付けるようにすると、検査データを取得する際に、記録媒体上のどこのエリア情報を基に計算されたかが直ちに分かるので都合がよい。
【００６５】
すなわち、ある検査データは、（CheckData,StartLBA,ExtentSize）の３つの組で表現することができる。ここで、CheckDataは検査データであり、StartLBAは算出の基になったデータが記録されているエクステントの先頭セクタのＬＢＡ（Logical Block Address：論理ブロックアドレス）、ExtentSizeはエクステントのセクタ（ＬＢＡ）単位のサイズである。検査データが複数ある場合は、順番に並べて記録する。
【００６６】
次に、検査データの記録形式の例を示す。
【００６７】
struct BFSI {
Base_FileSystem_ID             2 byte      WORD
reserved[1]                    1 byte      BYTE
Partition_Table_Offset         1 byte      BYTE
Partition_Table_LBA            4 byte      DWORD
Extended_Partition_Table_LBA   4 byte      DWORD
reserved[4]                    1*4 byte    BYTE
PartitionTable                 16 byte     PTable
FileSystem_Implementation_Use()  variable  FSIU
}
ここで、「Base_FileSystem_ID」は、対象となるファイルシステムを特定するためのIDであり、ＦＡＴ１２,ＦＡＴ１６,ＦＡＴ３２等が区別できるよう固定値を割り当てる。「reserved」は、データ構造のアライメントをとるために適宜挿入されている予約領域である。「Partition_Table_Offset」は、パーティションテーブル領域にある４つのパーティションを識別するための値で０〜３をとる。また、「Partition_Table_LBA」は、パーティションテーブルが記録されている論理セクタのLBAである。
【００６８】
また、「Extended_Partition_Table_LBA」は将来の拡張用に用意された領域である。「PartitionTable」は対象となるパーティションの配置が記録されているテーブル情報であり、Partition_Table_LBAのPartition_Table_Offsetで参照されるパーティションテーブル情報のコピーである。これによって、複数のパーティションが存在するような記録媒体においてパーティション毎に検査データを管理することができる。
【００６９】
更に、「FileSystem_Implementation_Use():FSIU」は、ファイルシステム毎に規定する検査データの内容であり、例えばＦＡＴ−ＦＳに対するそれは、以下のようにFileSystem_Implementation_Use_for_FAT()として規定される。ファイルシステム毎に規定するのは、ファイルシステムによって、ファイルの管理方法が異なるからである。
【００７０】
FileSystem_Implementation_Use_for_FAT()｛
Number_of_SubDirectory(=NDS)    4 byte         DWORD
reserved[4]                   1*4 byte         DWORD
FAT_BPB                       variable(*)      FSI
FAT_FSInfo                    variable(*)      FSI
FAT_FAT1                      variable(*)      FSI
FAT_FAT2                      variable(*)      FSI
FAT_ROOT                      variable(*)      FSI
FAT_SUB[NSD]                  variable(*)*NSD  FSI
｝
(*)通常32byte
上記のように、ＦＳＩＵは、複数のファイルシステム・インテグリティ情報（FileSystem_Integrity：ＦＳＩ)と、サブディレクトリ番号（Number_of_SubDirectory：ＮＳＤ)とから構成される。ＮＳＤはサブディレクトリの数である。
【００７１】
上記において、ＦＳＩは検査データとこれに対応付けられたエクステント情報であり、ＦＡＴ−ＦＳに固有な幾つかの構成要素からなる。また、「FAT_BPB」は、バイオス・パラメータ・ブロック（bios parameter block）に対する検査データである。「ＢＰＢ」は先に説明したブートセクタがこれに相当し、ＦＡＴファイルシステムの先頭セクタの情報である。
【００７２】
また、「FAT_FSInfo」は、ＦＡＴ−３２のための管理情報に対する検査データである。
「FAT_FAT1」はＦＡＴに対する検査データで、「FAT_FAT2」はＦＡＴのコピーに対する検査データである。更に、「FAT_ROOT」はルートディレクトリに対する検査データ、「FAT_SUB[NSD]」はＮＳＤで示された数のサブディレクトリのそれぞれに対する検査データである。
【００７３】
検査データのより詳しい構成例を以下に示す。
【００７４】
struct FileSystem_Integrity{
FSI_ID[3]                   1*3 byte      BYTE
reserved                    1 byte        BYTE
Section_ID                  2 byte        WORD
reserved                    4 byte        DWORD
reserved                    4 byte        DWORD
Number_of_Extent(=NOE)      4 byte        DWORD
Extent_Information[NOE]    12*NOE byte_EI
} FSI;
ここで、FSI_IDは、ＦＳＩであることを示す識別子で”FSI”という文字列である。「Section_ID」は、このファイルシステムにおけるＦＳＩの種類を示す、識別番号であり、ＦＡＴファイルシステムの場合、次のように規定する。
【００７５】
0  無効エントリ
1  FAT1
2  FAT2
3  BPB
4  FSINFO
5  ROOT
#8000  −  #FFFE  Sub  Directry
下位１５ビットはディレクトリの深さを示す。Root  Directryの直下のサブディレクトリを0とする。
【００７６】
#FFFF  No  Information
また、「Number_of_Extent(NOE)」は検査の対象となるデータのエクステントの数である。「Extent_Information[NOE]」は、検査の対象となるデータのエクステント情報であり、ＮＯＥが1でない場合は、ＮＯＥの個数分だけ並ぶことになる。また、「Extent_Information」は、先に述べた（CheckData,StartLBA,ExtentSize）の組データであり、次のように定義する。
【００７７】
struct Extent_Information{
Extent_Address             4 byte    DWORD
Extended_Extent_Address    4 byte    DWORD
Extent_Size                2 byte    WORD
CRC16                      2 byte    WORD
} _EI;
ここで、「Extent_Address」は対象となるエクステントの先頭セクタのＬＢＡである。
「Extended_Extent_Address」はＬＢＡを４バイトで表現できない場合の拡張用で、上位４バイトのＬＢＡである。「Extent_Size」はエクステントのサイズをセクタ単位で表したものである。「CRC16」は、ＩＴＵ−Ｔ Ｖ．４１の生成多項式をこのエクステントに適用して算出した値（ＣＲＣ関数の出力値）であり、これが検査データである。
【００７８】
ＣＲＣ関数（特にＣＲＣ１６関数）の初期値として、0x4ABAを用いると、ＡＴＡ／ＡＴＡＰＩ−４以降で規定されるＵＤＭＡ転送におけるＣＲＣの定義と同じになるので、ＡＴＡ／ＡＴＡＰＩ−４に対応した機器に搭載するのに都合がよい。
【００７９】
なお、ここでは、検査データをエクステント毎に計算するようにしたが、ＣＲＣをエクステント毎にリセットせず、保持しておけば、対象とするデータが複数のエクステントに分かれていても一つの検査データで管理することもでき、検査データ数の増加を抑えることができる。
【００８０】
（２）ＮＴＦＳへの適用
次に、本発明を適用し得るファイルシステムの他の例としてＮＴＦＳについて説明する。このＮＴＦＳは、ＦＡＴ−ＦＳと同様にクラスタ単位のファイル配置を行うが、ＦＡＴよりも比較的フラグメンテーションが発生しにくく、信頼性を向上させる仕組みや、より細かい属性設定が可能などの幾つかの特徴があり、ＦＡＴ−ＦＳより柔軟で高度な管理が可能である。
【００８１】
ＮＴＦＳの構造上の特徴は、パーティション内のすべてのファイルやディレクトリ毎に固定長の管理レコードを作成し、これを集中的に管理している点にある。この管理レコード群はＭＦＴ（Master File Table）と呼ばれる１つのファイルである。各レコードは固定長であり、このサイズに納まるような小さいファイルは管理レコード内で完結するように保存される。
【００８２】
一方、このサイズを超える大きいファイルは、ＭＦＴ以外の領域に一連の新しいクラスタが割り当てられ、そこへのインデックスが管理レコードに保存される。ＮＴＦＳの場合は、このＭＦＴに対して検査データを生成すればよい。
【００８３】
（３）ＩＳＯ ９６６０への適用
次に、本発明を適用し得るファイルシステムの他の例としてＩＳＯ ９６６０について説明する。このＩＳＯ ９６６０に対して本発明を適用する場合は、ディレクトリ毎に検査データを生成すればよい。ただし、追記型の記録媒体にＩＳＯ ９６６０が適用される場合は、非対応機器での改変が発生すると、最新のセッションに検査データそのものが存在しないので、検査データの照合をする必要はない。すなわち、検査データが存在しなければ、非対応機器で改変が行われたと判断できるので、その後の必要な処理を行うことができる。
【００８４】
（４）ＵＤＦへの適用
次に、本発明を適用し得るファイルシステムの他の例としてＵＤＦについて説明する。ＵＤＦ１.５以降では、ＶＡＴ（Virtual Allocation Table）という管理構造を用いることによって追記を実現している。追記型の記録媒体にＵＤＦが適用される場合は、非対応機器での改変が発生すると、ＩＳＯ ９６６０の場合と同様に最新セッションに検査データそのものが存在しないので、検査データの照合をする必要はない。すなわち、検査データが存在しなければ、非対応機器で改変が行われたと判断できるので、その後の必要な処理を行うことができる。
【００８５】
書き換え型のＵＤＦにおいては、ＦＡＴ−ＦＳに対して行っているように、ディレクトリ毎に検査データを用意して、ＦＡＴ−ＦＳと同様な手続きを踏めばよい。検査データの配置場所としては、ＵＤＦはボリューム管理構造をディスクリプタ形式で管理しているので、ディスクリプタシーケンスとパーティションを除く領域に記録することができる。
【００８６】
ＵＤＦの場合は、検査対象となるデータは、スペースビットマップと、ディレクトリ及びＩＣＢ（Information Control Block）である。スペースビットマップは、ＦＡＴファイルシステムにおけるＦＡＴに相当するものであり、ディスク上のどの領域を使用して、どの領域を使用していないかをビットマップのテーブルで表現した情報である。ビットマップを構成する１ビット１ビットが１つの論理セクタに対応し、この値が０であるか１であるかによって、使用しているかどうかを示す。従って、ファイルの長さや配置が変更されると、ビットマップが変化する。
【００８７】
ディレクトリとＩＣＢは、ファイルの管理情報であり、ディレクトリには、ファイルの識別情報とＩＣＢの記録場所が格納されている。ＩＣＢはファイル毎に存在し、ファイルの各種属性のほか、ファイルのディスク上の配置情報を有する。従って、ＵＤＦにおけるディレクトリとＩＣＢは、ＦＡＴファイルシステムにおけるディレクトリとＦＡＴの両方を併せ持った情報を有する。
【００８８】
ＦＡＴファイルシステムにおいて、まず最初にＦＡＴを検査するのと同様に、ＵＤＦにおいては、まず最初にスペースビットマップを検査すれば、データの新規作成、削除、あるいは元のファイルのサイズが変わるような改変に対しては、スペースビットマップが変化するため、ディレクトリとＩＣＢを検査しなくてもスペースビットマップをチェックした段階で、改変を検出することができる。
【００８９】
（５）ブリッジファイルシステムへの適用
次に、本発明を適用し得る他の例として、ブリッジファイルシステムへの適用について説明する。ＤＶＤ−ＲＯＭのように複数のファイルシステムが共存し、どのファイルシステムを通してもファイルにアクセスできるようにしたのが、ブリッジファイルシステムである。これらは通常読み取り専用の媒体に適用されるが、記録可能な媒体に適用すると、次のような不都合がある。
【００９０】
すなわち、１つのファイルシステムにしか対応していない機器でデータの改変を行うと、ブリッジされている他のファイルシステムにおける整合性がとれなくなり、他のファイルシステムから正常にアクセスできなくなる。この時、データが第一のファイルシステムしか対応できない機器によって改変されたことを検出できれば、第一のファイルシステムのファイル管理情報を基に、第二のファイルシステムのファイル管理情報を更新し、ブリッジファイルシステムが整合性を保つように制御することができる。これは、最初に説明したファイルシステムの管理情報とアプリケーション管理情報の関係と同様である。
【００９１】
すなわち、２つのファイルシステムが共存するブリッジファイルシステムに本発明を適用する場合は、第一のファイルシステムのファイル管理情報を予め定めた特定の関数で一意に定まる固定長の値を、第二のファイルシステムから検査データとして参照できるように記録媒体上の特定の領域に記録しておき、２つのファイルシステムをマウントする時に、第一のファイルシステムの管理情報から上記特定の関数で変換して求めた値と、記録媒体上に予め記録された第二のファイルシステムから参照可能な検査データとを比較し、両者が異なる場合は、第一のファイルシステムの管理情報を第二のファイルシステムの管理情報に反映させると共に、検査データを計算値で更新することによって、第一のファイルシステムの整合性と第二のファイルシステムの整合性を常に保つようにする。
【００９２】
また、上記の場合、第一のファイルシステムのファイル管理情報に対してエクステント毎に検査データを生成し、そのエクステントの配置情報と検査データとを対応付けて記録媒体に記録する。
【００９３】
これまで、検査データをファイルシステムがデータとして管理しない領域に記録するように説明してきたが、検査データをファイルシステム上のデータとして記録することも可能である。これによって、通常のファイルアクセス手段で検査データにアクセスできるという利点がある。ただ、ユーザーによって改変される危険性があるため、ファイルシステム上でシステムファイル、読み出し専用、隠し属性等の保護属性をつけて管理することによって、その危険性を減らすことができる。
【００９４】
なお、本発明は以上の実施の形態に限定されるものではなく、例えば、検査データを求めるために使用する特定の関数として、以上の実施の形態では、一方向ハッシュ関数あるいはＣＲＣ１６関数を説明したが、ＣＲＣ１６以外のビット数のＣＲＣ関数でもよい。また、ＣＲＣ関数の初期値は、「０Ｘ４ＡＢＡ」以外の値（例えば、「０ｘＦＦＦＦ」）でもよい。
【図面の簡単な説明】
【００９５】
【図１】本発明方法の原理説明用フローチャートである。
【図２】ＦＡＴファイルシステムの構造を説明するための図である。
【図３】本発明方法の一実施の形態が適用されるファイルシステムのシステム構成図である。
【図４】本発明方法において、２つのファイルの管理情報から検査データを生成することを示す図である。
【図５】本発明方法において、検査対象となるファイル管理情報が複数のセクタにまたがっているときの検査データを生成する方法を示す図である。
【図６】本発明方法において、検査データが記録される記録媒体の特定の領域の各例を示す図である。
【符号の説明】
【００９６】
１  システム領域
２、３  ＦＡＴ
４  ルートディリレクトリ
５  データ領域
１１  中央処理装置（ＣＰＵ）
１２  ＨＤＤ
１４  ＡＴＡ  ＡＴＡＰＩ  Ｉ／Ｆ
１５  メインメモリ
１６  書込型ドライブ
１７  ＰＣＭＣＩＡ  Ｉ／Ｆ
１８  メモリカード、カード型ＨＤＤ等の記録媒体
２１、２２  検査データ生成回路
２５  コンテンツデータ
２６  アプリケーション管理情報
２７  コンテンツデータのファイル管理情報
２８  アプリケーション管理情報のファイル管理情報
３１、３２、３３、３４  検査データ記録領域
４１  ＭＢＲ
４２  パーティションテーブル
４３  ブートセクタ
４４  ジャンプ命令
４５  名称フィールド
【図１】
2005222525.tif 000003
【図２】
2005222525.tif 000004
【図３】
2005222525.tif 000005
【図４】
2005222525.tif 000006
【図５】
2005222525.tif 000007
【図６】
2005222525.tif 000008