(57)【要約】      （修正有）【課題】ファイルシステムによるファイル管理状態と、管理ファイルによるファイル管理状態とについての整合性を復帰させるための処理の効率化を図る。【解決手段】先ず、ファイルシステムにより記憶媒体に記憶されるファイルとして、コンテンツファイルについては、管理ファイルによっても管理する。そして、この管理ファイルのためのバックアップファイルも設ける。さらに、コンテンツファイルの管理状態についてのファイルシステムと管理ファイルとの間での整合性に関する状態を示すステイタス情報を設ける。そして、コンテンツファイルの追加記録、削除などの操作に応じてファイルシステム管理情報、管理ファイルを更新する処理の進行に応じて、このステイタス情報も書き換えていくようにされる。【選択図】図７
2007179436.tif 000002
【特許請求の範囲】
【請求項１】
記憶媒体に記憶されるファイルを管理する基本ファイル管理手段と、
上記基本ファイル管理手段によりファイル単位で管理される特定ファイル管理情報を利用して、上記基本ファイル管理手段により管理されるファイルにおける特定種類のファイルを管理する特定ファイル管理手段と、
上記基本ファイル管理手段によりファイル単位で管理され、上記特定ファイル管理情報のバックアップのために、上記特定ファイル管理情報の内容が反映される情報内容を有するものとされるバックアップファイルについての処理を行うバックアップファイル処理手段と、
上記特定種類のファイルに関する処理に応じて、上記基本ファイル管理手段によるファイル管理内容の変更と、上記特定ファイル管理情報及び上記バックアップファイルの書き換えとを行うための所定手順による処理が、上記基本ファイル管理手段、上記特定ファイル管理手段、及びバックアップファイル処理手段により実行されるように制御する更新制御手段と、
上記基本ファイル管理手段による上記特定種類のファイルの管理内容と、上記特定ファイル管理情報及び上記バックアップファイルの内容とに関する状態を示し、所定の不揮発性の記憶領域に記憶保持させておくべきステイタス情報を、上記更新制御手段による更新の処理が実行されているときの手順の進行状況に応じて変更するステイタス情報処理手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
上記ステイタス情報は、第１のステイタス情報としての情報単位と、第２のステイタス情報としての情報単位とから成り、
上記ステイタス情報処理手段は、
上記特定種類のファイルを対象とする処理を行うようにされ、この処理に応じて上記第１のステイタス情報を変更するファイル処理手段と、上記管理ファイルを更新するタイミングに応じて第２のステイタス情報を更新する上記特定ファイル管理手段と、により構成される、
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
上記ステイタス情報をメインのステイタス情報として、さらに、このメインのステイタス情報よりも高速にアクセス可能なようにして所定の不揮発性の記憶領域に記憶保持されるサブステイタス情報を処理するサブステイタス情報処理手段を備え、
上記サブステイタス情報処理手段は、上記特定ファイル管理手段による特定ファイル管理情報の更新処理に応じたタイミングで、上記基本ファイル管理手段による上記特定種類のファイルの管理内容と、上記特定ファイル管理情報及び上記バックアップファイルの内容とについての整合、不整合の別が示されるように、上記サブステイタス情報の内容を変更するようにされる、
ことを特徴とする請求項１に記載の情報処理装置。
【請求項４】
上記更新制御手段は、
上記特定種類のファイルに関する処理が削除である場合には、
上記特定ファイル管理情報の書き換え、上記バックアップファイルの書き換え、上記基本ファイル管理手段によるファイル管理内容の変更、の順序による処理となるようにする、
ことを特徴とする請求項１に記載の情報処理装置。
【請求項５】
上記特定ファイル管理手段は特定ファイル管理情報を所定サイズのデータ単位の集合により形成されるものとして管理し、上記バックアップファイル処理手段は、上記バックアップファイルを上記所定サイズのデータ単位の集合により形成されるものとして管理するようにされたうえで、
上記更新制御手段は、上記バックアップファイルを書き換えるときには、上記特定ファイル管理情報において書き換えが行われたデータ部分を含む上記データ単位のみを、バックアップファイルの構造にコピーする処理となるように制御を実行する、
ことを特徴とする請求項１に記載の情報処理装置。
【請求項６】
上記更新制御手段は、
作業メモリ上に保持されている、上記特定ファイル管理情報についての書き換えが行われたデータ部分を含むブロックのデータを、同じ上記作業メモリ上にコピーするようにして保持させるとともに、このコピーされた上記作業メモリ上のブロックのデータを、バックアップファイルの構造にコピーするようにして、バックアップファイルを書き換える、
ことを特徴とする請求項１に記載の情報処理装置。
【請求項７】
記憶媒体に記憶されるファイルを管理する基本ファイル管理手順と、
上記基本ファイル管理手順によりファイル単位で管理される特定ファイル管理情報を利用して、上記基本ファイル管理手順により管理されるファイルにおける特定種類のファイルを管理する特定ファイル管理手順と、
上記基本ファイル管理手順によりファイル単位で管理され、上記特定ファイル管理情報のバックアップのために、上記特定ファイル管理情報の内容が反映される情報内容を有するものとされるバックアップファイルについての処理を行うバックアップファイル処理手順と、
上記特定種類のファイルに関する処理に応じて、上記基本ファイル管理手順によるファイル管理内容の変更と、上記特定ファイル管理情報及び上記バックアップファイルの書き換えとを行うための所定手順による処理が、上記基本ファイル管理手順、上記特定ファイル管理手順、及びバックアップファイル処理手順により実行されるように制御する更新制御手順と、
上記基本ファイル管理手順による上記特定種類のファイルの管理内容と、上記特定ファイル管理情報及び上記バックアップファイルの内容とに関する状態を示し、所定の不揮発性の記憶領域に記憶保持させておくべきステイタス情報を、上記更新制御手順による更新の処理が実行されているときの手順の進行状況に応じて変更するステイタス情報処理手順と、
を実行することを特徴とする情報処理方法。
【請求項８】
記憶媒体に記憶されるファイルを管理する基本ファイル管理手順と、
上記基本ファイル管理手順によりファイル単位で管理される特定ファイル管理情報を利用して、上記基本ファイル管理手順により管理されるファイルにおける特定種類のファイルを管理する特定ファイル管理手順と、
上記基本ファイル管理手順によりファイル単位で管理され、上記特定ファイル管理情報のバックアップのために、上記特定ファイル管理情報の内容が反映される情報内容を有するものとされるバックアップファイルについての処理を行うバックアップファイル処理手順と、
上記特定種類のファイルに関する処理に応じて、上記基本ファイル管理手順によるファイル管理内容の変更と、上記特定ファイル管理情報及び上記バックアップファイルの書き換えとを行うための所定手順による処理が、上記基本ファイル管理手順、上記特定ファイル管理手順、及びバックアップファイル処理手順により実行されるように制御する更新制御手順と、
上記基本ファイル管理手順による上記特定種類のファイルの管理内容と、上記特定ファイル管理情報及び上記バックアップファイルの内容とに関する状態を示し、所定の不揮発性の記憶領域に記憶保持させておくべきステイタス情報を、上記更新制御手順による更新の処理が実行されているときの手順の進行状況に応じて変更するステイタス情報処理手順と、
を情報処理装置に実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、記憶媒体に対して情報の書き込み、読み出しを実行する情報処理装置と、その方法に関する。また、このような情報処理装置が実行すべきプログラムに関する。
【背景技術】
【０００２】
ＨＤＤ（ハードディスク）などをはじめとする各種の記憶媒体に記憶されるデータを管理するのにあたり、ファイルシステムを採用してファイル単位により管理することが広く行われている。このようなファイルシステムのフォーマットとしては、例えばＦＡＴ、ＨＦＳ(Hierarchical File System)などが知られている。
このようなファイルシステムが例えばアプリケーションと記憶媒体のドライバなどとの間に介在することで、例えばアプリケーションは、記憶媒体の物理的なデータ記憶構造を意識することなく、ファイルの読み書き等の操作(ファイル操作)を行うことができるようになっている。
【０００３】
また、近年においては、多くの種類の記憶媒体が、ビット単価の低下や記録密度の向上などにより大容量化の傾向にある。これとともに、各種情報処理の速度の高速化も進んでいる。このようなことを背景として、記憶媒体には、多数の静止画像、動画像、音声などのコンテンツにより形成されるデータのファイル（コンテンツファイル）を記憶させることができるようになってきている。
【０００４】
静止画、動画、音声などのコンテンツを記録再生する機器としては、現状であれば、デジタルスチルカメラ、ビデオカメラ装置などを挙げることができるが、このような機器にあって、上記のようにして記憶媒体に多数のコンテンツファイルが記憶できるようになってくると、例えば検索、閲覧のしやすさ、付属情報の充実などがユーザにとっての利便性としては重要になってくる。
ファイルシステムは、本来的には、上記しているように、記憶媒体に記憶されるデータをファイル単位で管理することを目的としていることから、ファイルシステムにおいて規定されるファイルの関連情報は、ファイル名（及び拡張子）、ファイルサイズ、作成日時、更新日時程度の基本的な情報に限定される。また、ＨＤＤなどをはじめとする各種の記憶媒体において基本的に採用されていることで、逆に、このような付属情報などについての拡張性にも乏しい。
【０００５】
そこで、ファイルシステムにより記憶媒体に記憶されるファイル全般についての管理を行うこととしたうえで、記憶媒体に記憶されるコンテンツファイルを対象として専用に管理するための情報を有して成るファイル形式の管理情報（管理ファイル）を利用することが提案され、また、実施されるようになってきている。
【０００６】
【特許文献１】特開２００４−２２７６３０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記管理ファイルとファイルシステムが使用する管理情報（ファイルシステム管理情報）とは、相互に個別の独立した情報単位である。このために、例えば、管理ファイルとファイルシステム管理情報の何れか一方が書き換え途中のときに電源が遮断されるなどの障害が発生して処理が中断されると、ファイルシステムによるファイル管理内容と、管理ファイルによるファイル管理内容との間に、何らかの不整合が生じることになる。このような不整合が生じた状態では、以降において正常なコンテンツファイルの管理が期待できなくなる。
そこで、本願発明としては、上記のようにして管理ファイルとファイルシステム管理情報の不整合が生じるような状態になったとしても、整合のとれた状態に復帰できるようにすることとしたうえで、さらに、このような復帰のための処理などが、より効率的なものとなるようにすることを目的とする。
【課題を解決するための手段】
【０００８】
そこで本発明は上記した課題を考慮して、情報処理装置として次のように構成する。
つまり、記憶媒体に記憶されるファイルを管理する基本ファイル管理手段と、この基本ファイル管理手段によりファイル単位で管理される特定ファイル管理情報を利用して、基本ファイル管理手段により管理されるファイルにおける特定種類のファイルを管理する特定ファイル管理手段と、基本ファイル管理手段によりファイル単位で管理され、特定ファイル管理情報のバックアップのために、上記特定ファイル管理情報の内容が反映される情報内容を有するものとされるバックアップファイルについての処理を行うバックアップファイル処理手段と、特定種類のファイルに関する処理に応じて、基本ファイル管理手段によるファイル管理内容の変更と、特定ファイル管理情報及びバックアップファイルの書き換えとを行うための所定手順による処理が、基本ファイル管理手段、特定ファイル管理手段、及びバックアップファイル処理手段により実行されるように制御する更新制御手段と、基本ファイル管理手段による特定種類のファイルの管理内容と、特定ファイル管理情報及びバックアップファイルの内容とに関する状態を示し、所定の不揮発性の記憶領域に記憶保持させておくべきステイタス情報を更新制御手段による更新の処理が実行されているときの手順の進行状況に応じて変更するステイタス情報処理手段とを備えることとした。
【０００９】
上記構成では、記憶媒体に記憶されるファイル全般についての基本的なファイル管理を基本ファイル管理手段により行うようにされている。そのうえで、これらのファイルのうちで特定種類のファイルについては、特定ファイル管理情報により管理される。さらに、特定ファイル管理情報については、バックアップファイルが設けられる。このバックアップファイルは、特定ファイル管理情報をバックアップする目的で設けられ、特定ファイル管理情報の内容が反映された情報内容を有するべきものとされる。
そして、特定種類のファイルに関する何らかの処理（記録、再生、削除、更新など）が行われるのに応じては、その処理結果が反映されるようにして、基本ファイル管理手段によるファイル管理内容の変更と、特定ファイル管理情報及びバックアップファイルの書き換え（更新）とを所定の処理手順に従って更新していくようにされるが、このときには処理の進行に応じて、基本ファイル管理手段によるファイルの管理内容と、特定ファイル管理情報及びバックアップファイルの内容が順次的に変化していくことになる。そこで、本願発明にあっては、このようにして変化する内容の状態遷移を、ステイタス情報に記述するようにされる。このステイタス情報は、不揮発性の記憶領域に記憶させておくようにされる。
このような構成の場合には、先ず、特定ファイル管理情報のバックアップファイルが存在することで、特定ファイル管理情報を正常化するのにあたっては、実際に記憶媒体に記憶されるコンテンツファイルをひととおり読み込んで再構築するようなことはせずに、バックアップファイルの内容を利用して行うことができる。
さらに、本願発明のステイタス情報が上記のようなものとされることで、例えば特定種類のファイルのファイル操作に応じて基本ファイル管理情報、特定ファイル管理情報、バックアップファイルを更新しているときに、電源遮断などの障害が生じて処理が中断され、これらの情報、ファイルに不整合が生じたとしても、ステイタス情報が示す状態により、その不整合がどのようなものであるのかについての推定を行うことができる。これに応じて、整合性を復帰させるための処理としても、推定される状態に適応した処理内容を選択できる。
【発明の効果】
【００１０】
このようにして本発明は、基本ファイル管理手段（基本ファイル管理手順）によるファイル管理内容と、特定ファイル管理情報などとの複数の管理情報の間で不整合が生じたような場合において、整合性を復帰させるための処理が、これまでよりも効率的に行われるという効果が得られる。
【発明を実施するための最良の形態】
【００１１】
以下、本発明を実施するための最良の形態（以下、実施の形態という）について説明する。本実施の形態としては、本発明としての情報処理装置の構成をデジタルビデオカメラに適用した場合を例に挙げることとする。
【００１２】
図１は、本実施の形態としてのデジタルビデオカメラ１の構成例を示すブロック図である。
この図に示すデジタルビデオカメラ１において、光学系部２は、撮像レンズ、絞りなどを備えて成り、入射された光を撮像光として、光電変換部３に結像させる。また、光学系部２においては、フォーカス（焦点）調整のためのフォーカス調整機構や、絞り値に応じて絞りを可変する絞り可変機構などを備えているものとされ、このような機構部の駆動は、カメラ機能部６から出力される駆動信号によって行われる。カメラ機能部６は、ＣＰＵ１０の制御に応じて、しかるべきフォーカス状態や絞りの状態等が得られるように所要の駆動信号を出力するようにされている。
また、例えば光学ズーム機能を与えることとした場合には、光学系部２においてズームレンズを移動させるズーム機構を設けると共に、上記と同様にして、ＣＰＵ１０の制御に応じて上記ズーム機構を移動させる駆動部を設けるようにすればよい。さらに、カメラ機能部６として、ストロボを設けたうえで、ストロボ発光機能を与えるように構成することもできる。
【００１３】
光電変換部３は、例えば光電変換素子であるＣＣＤ(Charge Coupled Device)、ＣＭＯＳセンサなどを備えて構成され、光学系部２から入射されて受光面にて結像された撮像光を光電変換することで撮像信号を生成してビデオ信号処理部４に出力する。撮影時においては、例えば露出設定結果に応じて決定されるシャッター速度の指示が、ＣＰＵ１０からビデオ信号処理部４に通知される。ビデオ信号処理部４では、通知されたシャッター速度に対応する走査タイミング信号を光電変換部３に出力する。光電変換部３は、この走査タイミング信号に応じて走査を行うようにして、光電変換処理を実行して映像信号を出力するようにされる。
【００１４】
ビデオ信号処理部４は、光電変換部３から入力されたアナログのビデオ信号（撮像画像信号）について、例えばゲイン調整、サンプルホールド処理を施すことによって波形整形を行ったうえで、Ａ／Ｄ変換を行うことで、デジタルとしてのビデオ信号データに変換する。そして、この変換処理によって得られたデジタルビデオ信号について、例えば、表示用輝度データの生成処理などをはじめ、表示部７にて表示が行われるようにするためのビデオ信号処理を実行する。これに伴い、ビデオ信号処理部４では、ＣＰＵ１０の制御に応じてキャラクタ画像なども撮像画像に重畳して表示可能なように、いわゆるオンスクリーンディスプレイのための信号処理も実行可能とされている。
表示部７として採用される実際のディスプレイデバイスについては特に限定されるべきものではないが、現状においては、広く液晶ディスプレイパネルが採用されている。
【００１５】
また、ビデオ信号処理部４は、光電変換部３から入力されたアナログビデオ信号を変換して得たデジタルビデオ信号について、例えば所定方式による圧縮符号化処理を施して、圧縮ビデオデータを生成することが可能とされている。
また、本実施の形態のデジタルビデオカメラは、スチルカメラ機能も備える。つまり、撮像画像信号について、写真としての所定形式による静止画データファイルを生成することが可能とされているが、このような画像処理も、ビデオ信号処理部４によって行われる。
【００１６】
また、ビデオ信号処理部４では、光電変換部３から入力された画像（映像）信号や、後述するメディアから読み出されたＡＶ(Audio Video)データのファイル（ＡＶファイル）などを、所定方式のアナログビデオ信号又はデジタルビデオ信号に変換して、画像入出力部５を介して外部機器などに出力可能とされている。
画像入出力部５は、外部から所定方式のビデオ信号を入力可能ともされており、この入力したビデオ信号をビデオ信号処理部４の処理を経て表示部７に表示させることが可能とされる。また、ビデオ信号処理部４は、画像入出力部５が入力したビデオ信号について、光電変換部３から入力されたアナログビデオ信号と同様にして、記録用データに変換してメディアコントローラ１３に転送することもできる。
これに対応して、画像入出力部５は、例えば所定方式に従った映像（画像）信号出力端子／映像信号入力端子を備える。
【００１７】
また、本実施の形態のデジタルビデオカメラ１は、音声処理部８及び音声入出力部９を備えることで、音声信号の入出力も可能とされている。
先ず、音声入力については、音声入出力部９としてマイクロフォンなどを備え、外部音声の収音を行って音声信号に変換して音声を入力するようにされる。そして、このようにして入力した音声信号を音声処理部８に出力する。音声処理部８は、例えば、撮像画像の圧縮符号化に対応する音声圧縮符号化方式により符号化された圧縮オーディオデータに変換するなどの音声信号処理を施す。
【００１８】
ＣＰＵ１０は、ビデオ信号処理部４により得られた撮像画像についての圧縮ビデオデータと、音声処理部８により得られた収音音声についての圧縮オーディオデータとにより、所定形式のＡＶファイルを形成するための制御処理を実行するようにされる。このＡＶファイルは、圧縮ビデオデータを再生して出力される動画像に対して、圧縮オーディオデータを再生して出力される音声の再生時間軸が同期したものとなっている。なお、実際にＡＶファイルを形成するための構成としては、ＣＰＵ１０がプログラムを実行して得られるデジタル信号処理となるソフトウェア構成とされてもよいし、あるいは、ＡＶファイルを形成するためのハードウェアを備えるとともに、ＣＰＵ１０がこのハードウェアについての動作を制御する構成としてもよい。
上記ＡＶファイルとしてのデータは、記録用データとして、例えばＣＰＵ１０の制御によってメディアコントローラ１３に転送される。また、ＣＰＵ１０は、ビデオ信号処理部４によって生成された写真画像としての所定形式の静止画データファイルについても、記録用データとしてメディアコントローラ１３に転送することができる。
【００１９】
音声入出力部９としては、音声信号入力端子などを備えて外部のオーディオ機器などからオーディオ信号を入力するようにも構成することができる。上記音声信号入力端子から入力されたオーディオ信号については、音声処理部８は、所定形式によるデジタルオーディオデータファイルに変換するようにされる。ＣＰＵ１０は、このようなデジタルオーディオデータファイルのデータについても、記録用データとしてメディアコントローラ１３に転送することができる。
【００２０】
メディアコントローラ１３は、ＣＰＵ１０との連携により、所定のメディア（記憶媒体）に対応して、データ処理に関する制御処理を実行可能に構成される。ここでいうメディアに対するデータ処理とは、メディアのフォーマット処理や、メディアの記憶領域に対するファイル及びファイル管理のための情報などの書き込み／読み出し処理など、メディアに記憶されるべきデータに関連する何らかの処理をいう。
【００２１】
本実施の形態では、メディアコントローラ１３に対しては、ＨＤＤ（ハードディスク）１４を接続した例を示している。ＨＤＤは、周知のようにして記憶媒体として磁気ディスクを備える記憶デバイスであり、現状においては最もビット単価が安価で、また好記録密度な記憶媒体の１つとされ、比較的低コストでギガバイトクラスの大容量が得られる。また、周知のようにして、記憶媒体である磁気ディスクに対する物理的なデータの読み出し／書き込みは、磁気ヘッドにより、磁気ディスク上に形成されるトラックをトレースしながら磁界印加、磁界検出を行うことによって実現される。
また、この場合のＨＤＤ１４としては、例えばデジタルビデオカメラ１に固定的に内蔵されるものとされている。ただし、デジタルビデオカメラ１（ホスト）に対して装脱可能な、所定の規格に従ったリムーバブル形態とされてもよい。
【００２２】
メディアコントローラ１３は、先に説明したようにして、記録用データが転送されてくるのに応じて、この記録用データを、メディアコントローラ１３と接続されているメディア（ＨＤＤ１４）のうちから対象として選択されているメディアに対してさらに転送する。データが転送されたメディアでは、メディアコントローラ１３側からの指示に応じて記憶領域に対してデータを書き込んで記憶させる。このようにしてメディアに記憶されるデータがファイルとして記憶管理されることになる。なお、メディアに記憶されるファイルの管理は所定方式のファイルシステムによって行われる。
【００２３】
また、例えばメディアに記憶されているファイルのうちで、ＡＶファイルを再生するときには、ＣＰＵ１０及びメディアコントローラ１３は、指定されたＡＶファイルにアクセスして読み出しを行う。このようにして読み出されるＡＶファイルは、例えばＣＰＵ１０の処理により、圧縮ビデオデータと圧縮オーディオデータとに分離され、圧縮ビデオデータについてはビデオ信号処理部４に受け渡し、圧縮オーディオ信号については、音声処理部８に受け渡すようにされる。
この場合のビデオ信号処理部４及び音声処理部８は、それぞれ、上記のようにして転送されてきた圧縮ビデオデータ、圧縮オーディオデータについて、復調処理を含む所要の再生信号処理を実行する。これにより、圧縮ビデオデータを再生した画像を表示部７にて表示するとともに、この画像の再生時間に同期して、圧縮オーディオデータを再生して得られる音声信号を、音声入出力部９が有するとされるスピーカにより音声として出力させたり、ヘッドフォン端子から出力させることができる。
【００２４】
また、例えばメディアから再生されたオーディオデータファイルは、音声処理部８の音声信号処理を経た後に、音声入出力部９を介して、外部に対して所定形式のオーディオ信号、オーディオデータとして出力することも可能とされている。この場合、音声入出力部９としては、音声処理部８から出力される所定のオーディオ信号、オーディオデータの形式に対応するオーディオ出力端子を備えることになる。
【００２５】
ＣＰＵ(Central Processing Unit)１０は、プログラムを実行することでデジタルビデオカメラ１についての各種制御処理を実行する。ＲＯＭ１１は、ＣＰＵ１０が実行する各種プログラムのほか、ＣＰＵ１０が処理を実行するのに使用する各種設定情報などが記憶されている。ＲＡＭ１２は、ＣＰＵ１０がプログラムに従った処理を実行するときの作業領域として使用されるもので、各種の演算処理結果などのデータが保持される。
また、不揮発性メモリ１２ａは、例えばフラッシュメモリなどをはじめとした、電源供給が停止しても記憶内容が消去されない性質のメモリ素子により形成され、ＣＰＵ１０の制御によって、データの書き込み／読み出しが実行される。この不揮発性メモリ１２ａに記憶されるべきデータ（情報）としては、適宜内容の変更が行われる設定情報などが一般的であるが、特に限定されるものではなく、実際のデジタルビデオカメラ１の仕様などに応じて所要の各種の情報を記憶することとされればよい。
【００２６】
この場合の操作入力部１５は、デジタルビデオカメラ１に備えられる各種操作子を一括して示しているものとされる。例えば、この操作入力部１５における操作子としては、写真撮影時に操作されるシャッターボタン、撮影モードなどを選択する操作子、パラメータのアップ／ダウンを行うための操作子などが含まれる。
【００２７】
通信部１６は、ＣＰＵ１０の制御に応じて、所定のデータ通信方式により外部デバイスと通信を行うためのハードウェア、ソフトウェアを実装して構成される部位である。本実施の形態の実際としては、この通信部１６には、USB(Universal Serial Bus)が採用される。そのうえで、本実施の形態のデジタルビデオカメラ１としては、USBマスストレージクラスを実装しているものとされる。
このようにしてUSBマスストレージクラスに対応していることで、例えば本実施の形態のデジタルビデオカメラ１と、パーソナルコンピュータなどの外部情報処理機器とをUSBにより接続すると、外部情報処理機器側では、デジタルビデオカメラ１側のメディアであるＨＤＤ１４を、外部のリムーバブルメディアとしてマウントしてアクセスすることが可能になる。
【００２８】
なお、本願発明の下では、通信部１６が対応するデータ通信方式としては、有線、無線を問わず特に限定されるべきものではなく、また、対応するデータ通信方式の数も限定されるべきものでない。現状であれば、データ通信方式としては、上記USB以外では、有線であればEthernet（商標）などのネットワーク、IEEE(the Institute of Electrical and Electronic Engineers)1394などのデータバス規格などを挙げることができる。また、無線であれば、Bluetooth（商標）などのデバイス間近距離無線通信、IEEE802.11a/b/gなどの無線ＬＡＮ(Local Area Network)規格を挙げることができる。
【００２９】
電源部１７は、デジタルビデオカメラ１における各種のハードウェアデバイスに対して動作電源を供給するもので、例えばバッテリや電源アダプタからの電力供給を受けて動作する電源回路などを備えて構成される。
【００３０】
上記のようにして、本実施の形態のデジタルビデオカメラ１では、撮像／収音により得られる動画としてのＡＶファイルや、写真としての静止画ファイルを、メディア（ＨＤＤ１４）に対して記憶させることができるようになっている。
【００３１】
メディアに記憶されるファイルは、通常は、所定フォーマットによるファイルシステムにより管理されることになるのであるが、本実施の形態としては、ＦＡＴ(File Allocation Table)ファイルシステムにより管理されるものとしている。ＦＡＴファイルシステムは、周知のようにして、ツリー型のディレクトリ構造によりファイルを管理するようにされており、また、データの書き込み／読み出しについては、クラスタといわれる論理的な最小データ管理単位により行うものとされている。クラスタは、メディアにおける物理的なデータ書き込み／読み出しの最小単位であるセクタを所定数にまとめたものが１単位となる。
【００３２】
なお、本実施の形態において、上記のようにしてファイルシステム(ＦＡＴ)により管理されてメディアに記憶されるファイルのうちで、ＡＶファイル（動画ファイル）や、写真などの静止画ファイルについては、再生出力される情報内容（コンテンツ）がユーザにとって意味のあるものであることに由来して、コンテンツファイルといわれるファイル種別(種類)に含まれることとして、例えば、システム関連などの種類のファイルとは区別する。
【００３３】
そのうえで、本実施の形態としては、ＨＤＤ１４に記憶されるファイルとして、上記コンテンツファイルを専門に管理するための管理情報内容を有する、コンテンツ専用の管理ファイル（以降は、単に管理ファイルという）を含めることとしている。
さらに本実施の形態では、上記管理ファイルのバックアップファイルも生成して、ＨＤＤ１４に記憶させることとしている。
【００３４】
図２は、本実施の形態のデジタルビデオカメラ１におけるＦＡＴファイルシステムにより構築されるＨＤＤ１４のディレクトリ構造を示している。
ＨＤＤ１４内のディレクトリ構造としては、例えば図示するようにして、ルート（Root）ディレクトリの直下の階層に、管理ファイルディレクトリ、静止画用ディレクトリ、動画用ディレクトリを配置するようにされる。
これらのディレクトリのうちで、静止画用ディレクトリと動画用ディレクトリがコンテンツファイルを格納するディレクトリとなる。つまり、静止画用ディレクトリには、写真などとしての1以上の静止画ファイルが格納される。また、動画用ディレクトリには、前述したＡＶファイルなどとしての動画ファイルが格納される。
また、管理ファイルディレクトリには、管理ファイルと、この管理ファイルのバックアップファイルが格納される。後述するようにして、本実施の形態の管理ファイルの実際としては、例えば、プロパティファイル、サムネイルファイル、メタデータファイルの集合から成るものとされる。また、管理ファイルのバックアップファイルは、プロパティファイル及びメタデータファイルについてのバックアップファイルからなるものとされる。
【００３５】
サムネイルファイルは、画像データを含むために相応に大きなファイルサイズになる。このことから、サムネイルファイルについては、バックアップをとらなければそれだけ記憶容量が節約できることになる。また、管理ファイルとファイルシステムの整合が取れていればいつでも再構築（復旧）が可能である。これらのことを理由に、サムネイルファイルは、バックアップファイルには含めないこととしている。
【００３６】
もちろん、例えば、記憶媒体が非常に大きな容量を有していることなどにより、特に記憶容量の節約に関して考慮する必要がない、あるいは、システムの仕様などの事情で、サムネイルファイルをバックアップすることがより優先されるような場合には、バックアップファイルにサムネイルファイルを含めることについて特に問題はない。
また、本実施の形態の実際として、管理ファイルディレクトリは、通常の使用では不可視のディレクトリとして設定されている。従って、この管理ファイルディレクトリに格納される管理ファイル及びバックアップファイルも不可視ファイルとなる。これらの管理ファイル、バックアップファイルは、システム側がコンテンツ管理に使用するファイルであることから、例えばユーザによって不用意に消去、書き換えなどが行われないようにすることが好ましい。そこで、本実施の形態では、上記のようにしてこれらのファイルを不可視ファイルとして管理している。
【００３７】
図３は、本実施の形態の管理ファイルの構造例を示している。
管理ファイルとしては、上記もしたように、プロパティファイル、サムネイルファイル、及びメタデータファイルにさらに分けられる。本実施の形態では、これらプロパティファイル、サムネイルファイル、及びメタデータファイルの集合を管理ファイルとして扱っている。なお、これらプロパティファイル、サムネイルファイル、及びメタデータファイルのうちで、必須のファイルはプロパティファイルとされ、サムネイルファイルとメタデータファイルはオプションとされる。
【００３８】
プロパティファイルは、図示するようにして、ファイルヘッダと、１以上のファイルエントリ（１〜ｎ）の集合として形成される。個々のファイルエントリは、コンテンツファイルに１対１で対応するものとされ、対応するコンテンツファイルに関連した基本的な情報を格納する。エントリファイルの構造については後述する。
【００３９】
サムネイルファイルは、１以上のサムネイルスロットを備えて形成される。１つのサムネイルスロットは、原則として１つのコンテンツファイルに対応して、この対応するコンテンツファイルを示す代表画像であるサムネイル画像データを格納する。
【００４０】
また、メタデータファイルは、１以上のメタデータスロットから成る。１つのメタデータスロットも、１つのコンテンツファイルに対応すべきものとされている。タイトルスロットには、例えばテキスト形式のデータ（コメントなどに使用できる）、コンテンツファイルのグルーピングを示す情報など、任意の情報項目を格納できるものとされている。
【００４１】
プロパティファイルにおけるファイルヘッダの内部構造としては、ここでの図示は省略しているが、例えば、現プロパティファイルの作成日時、更新日時を示す情報、ファイルエントリのサイズを示す情報、格納するファイルエントリの数を示す情報、及びサムネイルファイルリスト、メタデータファイルリストなどを含む。
サムネイルファイルリストは、サムネイルファイルの作成日時、更新日時を示す情報、サムネイルスロットのサイズを示す情報、サムネイルスロットの格納数を示す情報などを格納する。
メタデータファイルリストは、メタデータファイルの作成日時、修正日時を示す情報、メタデータスロットのサイズを示す情報、メタデータスロットの格納数を示す情報などを格納する。
【００４２】
また、プロパティファイルにおけるファイルエントリの構造としては、例えば図示するようにして、ファイルポインタ、メタデータポインタ、サムネイルポインタ、ファイル名、ファイルサイズ、作成日時、更新日時などの情報を有して成る。
ファイルポインタは、対応するコンテンツファイルを指し示すポインタの情報となる。このポインタの実際としては、例えばファイルシステム側で管理するパスにより、対応するコンテンツの所在を特定して示すようにされる。
サムネイルポインタは、サムネイルファイルにおいて、現ファイルエントリに対応付けられるサムネイルスロット（つまり、現ファイルエントリのファイルポインタが示すコンテンツファイルに対応するサムネイルスロット）を指し示す。サムネイルファイルは、例えば固定長のサムネイルスロットを論理的に連結するようにして形成される。そこで、サムネイルポインタとしては、例えばサムネイルファイルにおけるサムネイルスロットの配置順を指定することで、１つのサムネイルスロットを特定できることになる。
なお、サムネイルファイル内のサムネイルスロットに格納されるサムネイル画像データは、表示部７にて表示させるファイル一覧画像を表示させるときにファイルを示すアイコン（サムネイル画像）として表示させるようにして使用することができる。
【００４３】
メタデータポインタは、メタデータファイルにおいて、現ファイルエントリに対応付けられるメタデータスロット（つまり、現ファイルエントリのファイルポインタが示すコンテンツファイルに対応するメタデータスロット）を指し示す。メタデータファイルも、例えば固定長のメタデータスロットを論理的に連結するようにして形成されることから、メタデータポインタとしても、例えばメタデータファイルにおけるメタデータスロットの配置順を指定することで、１つのメタデータスロットを特定できることになる。
【００４４】
また、ファイルエントリ内のファイル名、ファイルサイズ、作成日時、更新日時は、それぞれ、現ファイルエントリのファイルポインタが示すコンテンツファイルの、ファイル名、サイズ、作成日時、更新日時の情報を格納する。
【００４５】
また、ここでは図示していないが、ファイルエントリは、上記したファイルポインタ、メタデータポインタ、サムネイルポインタ、ファイル名、ファイルサイズ、作成日時、更新日時以外の情報を格納することができる。一例として、例えば本実施の形態の管理ファイルを使用するシステムが、ＧＰＳ(Global Positioning System)などの測位システムを実装しているような場合には、この測位システムにより測位された位置情報などもファイルエントリの情報要素に含めて格納するようにされる。
【００４６】
ここまでの説明から分かるように、デジタルビデオカメラ１のメディア（ＨＤＤ１４）に記憶されるコンテンツファイルの各々は、ファイルエントリ内のファイルポインタによって、そのファイルエントリと対応付けられていることになる。そして、このファイルエントリのサムネイルポインタを参照することで、１つのサムネイルスロットが特定されるが、このサムネイルスロットは、上記ファイルポインタにより対応付けられるコンテンツファイルと対応していることになる。また、このファイルエントリのメタデータポインタにより指定される１つのメタデータスロットも、上記ファイルポインタにより対応付けられるコンテンツファイルと対応していることになる。
つまり、管理ファイルによっては、メディアに記憶されている１つのコンテンツファイルと、このコンテンツファイルに対応付けられたサムネイル画像データ（サムネイルスロット）、及びこのコンテンツファイルに関連する任意の内容の情報（メタデータスロット）とを、プロパティファイルのポインタを軸として対応付けるようにして管理している。
【００４７】
このようなファイル管理の情報を、コンテンツファイルを処理するアプリケーションが利用することで、コンテンツファイルの管理は、例えばファイルシステムのみに依存する場合よりも効率的なものとなる。例えば、ファイル検索にあたっては、ファイルエントリに格納する情報や、メタデータスロットに格納する情報などを検索条件として加えることで、ファイルシステムに基づく場合よりも多くの検索条件を入力して検索を行うことが可能になる。つまり、より高い検索機能が与えられる。また、ＨＤＤ１４に記憶させたコンテンツファイルを表示部７に表示させるような場合においても有利となる。例えば、サムネイル画像の表示時には、サムネイルファイルからサムネイル画像を読み出して再生出力することができるので、その都度、ＨＤＤ１４のコンテンツファイルのデータにアクセスしてサムネイル画像を生成する必要が無く、その分、リスト画面表示が速くなる。また、ファイルエントリに格納する情報や、メタデータスロットに格納する情報などを利用して、リスト表示として多様な付属情報も提示することができる。
【００４８】
図４は、これまでの説明のようにして、ＦＡＴファイルシステムによるファイル管理と、管理ファイルによるコンテンツファイルの管理を行うようにされた場合のシステム構成を階層モデルにより示している。
先ず、この階層モデルとしては、ソフトウェア層と、その下層となるハードウェア層に大別される。
ソフトウェア層は、この場合には、メディアに対してホスト（実施の形態ではデジタルビデオカメラ１）となるデバイスにおいて、ＣＰＵが実行するプログラム、及び各種ファームウェア、ミドルウェアなどにより実現されるソフトウェア処理が対応するものとされる。この場合のソフトウェア層は、基本的には、図示するように、上層から下層にかけて、アプリケーションファイルシステム、デバイスドライバの各層が位置したうえで、管理ファイル制御システムが位置するようにされる。
ハードウェア層には、メディア（ＨＤＤ１４）そのものの物理的な記憶領域が位置するものとして考えることができる。
【００４９】
この場合のアプリケーションは、ファイルについての各種処理機能（記録、再生、更新など）を有し、ファイルレベルでのアクセス要求を管理ファイル制御システムに対して行う。
【００５０】
ファイルシステムは、このファイルシステムとしての機能を実現するソフトウェアが対応する。本実施の形態では、ＦＡＴファイルシステムを採用することとしているので、ファイルシステムの機能を提供するソフトウェアとしても、ＦＡＴファイルシステムに対応して構成されるものとなる。
周知のようにしてＦＡＴファイルシステムは、記憶ファイルをツリー型のディレクトリ構造により管理し、また、ファイルをクラスタ単位の集合として管理するようにされている。このようなファイル管理、データ管理は、ディレクトリエントリ、及びＦＡＴ（File Allocation Table）といわれるテーブル情報から成る管理情報（ファイルシステム管理情報）により実現される。ディレクトリエントリは、メディア上におけるファイル、ディレクトリ（サブディレクトリ）の所在をクラスタレベルで示す情報であり、ＦＡＴは、ディレクトリ、ファイルを成すクラスタレベルでのチェイン（リンク、連結）を示す情報である。これらファイルシステム管理情報（ディレクトリエントリ、ＦＡＴ）へのアクセス、また、ファイルの読み出し（再生）、書き込み（追記、更新）、などのファイル操作結果に応じたファイルシステム管理情報の更新などの、ファイルシステム管理情報そのものに対しての操作は、このファイルシステムの階層により行うものとされる。
そして、ファイルシステムでは、アプリケーション（及び後述する管理ファイル制御システム）からのファイルレベルによるアクセス要求を、ＦＡＴファイルシステムのフォーマットにおけるデータの管理単位となるクラスタのレベルに変換して、デバイスドライバに対してアクセス要求を行う。
【００５１】
デバイスドライバは、コントロール対象のデバイスとなるメディアをコントロールするためのソフトウェアが対応し、上記ファイルシステムからのＦＡＴファイルシステムフォーマットに従ったクラスタレベルによるアクセス要求を、メディア上におけるデータの書き込み、読み出し単位であるセクタのレベルに変換して、メディアへのアクセス要求を行う。
【００５２】
この場合のメディアは、論理的にはＦＡＴファイルシステムに従ってフォーマット（初期化）されたものとなる。図１では、ＨＤＤがここでのメディアに相当する。そして、メディアは、デバイスドライバからのセクタレベルのアクセス要求に応答して、指定されたセクタアドレスからデータを読み出して、デバイスドライバに返す。つまり、セクタレベルでのアクセス応答を実行する。
デバイスドライバは、メディアからのセクタレベルでのアクセス応答、つまりセクタ単位でのデータの受け取りを行い、この受け取ったデータについて、クラスタ単位によるデータとして扱ってファイルシステムに受け渡す（クラスタレベルでのアクセス応答）。
ファイルシステムは、デバイスドライバから受け取ったデータを、ファイルレベルのデータとしてアプリケーションに受け渡すようにされる。アプリケーションは、ファイルとして受け取ったデータについて、例えばユーザによる操作入力などに応じたアプリケーションレベルでの所要の処理を実行する。
【００５３】
また、管理ファイル制御システムは、図３に示した管理ファイルの生成、メディアへの読み出し、書き込みなどのファイル操作機能を実現するソフトウェアが対応する。例えばアプリケーションが、管理ファイルを利用してコンテンツファイルを検索するような場合には、管理ファイル制御システムによりメディアから読み出させて取り込んだ管理ファイルを参照することになる。
また、アプリケーションのファイル操作として、コンテンツファイルについての記録、削除、更新などのファイル操作を行う場合には、管理ファイル制御システムを経由して、アクセス要求、読み出しデータの受け取りを行うものとされる。この場合には、アプリケーションと管理ファイル制御システムは、例えばファイル名や、相互に取り決めたファイルＩＤなどを用いて、ファイルレベルでの通信を行うようにされればよい。
また、管理ファイル制御システムは、上記したようなアプリケーションによるファイル操作結果に応じて、この操作結果が反映されるようにして管理ファイルの更新（書き換え）を行うようにされる。このようにして、管理ファイル制御システムは、管理ファイルの操作を行うようにされている。また、本実施の形態では、図２により説明したようにして、管理ファイルのバックアップファイルも存在し、このバックアップファイルも、アプリケーションによるコンテンツファイルの操作結果に応じて更新する必要がある。このようなバックアップファイルのファイル操作も、管理ファイル制御システムが実行する。
管理ファイル制御システムが、例えば管理ファイルのアクセス要求を行うときには、アプリケーションと同様にして、ファイルレベルにより、ファイルシステムに対して要求を行うことになる。ファイルシステムより下層では、先の説明と同様にしてアクセス要求とデータの受け渡しを行って、管理ファイルのデータを管理ファイル制御システムに返すようにされる。
【００５４】
従来技術における課題としても述べたが、上記のようにしてファイルシステム（ＦＡＴ：基本ファイル管理手段）により記憶媒体に記憶されるファイルの管理を行うようにした上で、このファイルのうち、コンテンツファイル（特定種類のファイル）については管理ファイルによっても管理されるように構成した場合には、ファイルシステム側でのファイル管理内容と管理ファイルによるファイル管理内容について相互に整合が得られていることが必要になる。
【００５５】
上記したようなファイル管理内容の不整合は、例えばコンテンツファイルの操作に応じてファイルシステムと管理ファイルを書き換えている途中に電源が遮断されるなどの障害により、ファイルシステムと管理ファイルの書き換え処理が強制的に中断されてしまった場合などに生じる。具体例として、ファイルシステムの更新を正常に終了した後に管理ファイルの書き換えを行っており、このときに処理が中断されたとすると、この管理ファイルの内容は、更新前のままの状態を記憶保持している状態、若しくはファイルそのものが破壊された状態となり、更新を正常終了したファイルシステムとの整合がとれなくなる。
しかしながら、通常では、電源が投入されたときにおいて、その前回の電源停止がどのような状態で行われたのかを知ることはできない。つまり、電源が投入された段階では、ファイルシステムと管理ファイルとで整合がとれているかどうかについて知ることができない。この場合において、ファイルシステム側と管理ファイルとのファイル管理内容の整合性を確認するためには、例えばファイルシステムにより記憶媒体に記憶されているコンテンツファイルに一通りアクセスし、管理ファイルのファイル管理内容との一致／不一致について比較していくことになる。このような処理は、例えばＨＤＤなどの記憶媒体への頻繁なアクセスと比較処理とを繰り返すことになるので、相応の時間を要する。また、コンテンツファイル数が多くなるほど処理時間も増加する。そして、このような処理は、電源投入時における起動処理の１つとして行うことが一般的であることから、起動時間が長くなるなどの不利点を招く。
【００５６】
そこで、上記したような不都合を解決するための技術構成として、ファイルシステム側によるファイル管理内容と管理ファイルのファイル管理内容に関しての状態（ファイル管理内容状態）を記述したステイタス情報を、不揮発性の記憶領域（本実施の形態であれば、ＨＤＤ１４または不揮発性メモリ１２ａ）に記憶保持させることとし、例えば起動時においては、このステイタス情報を参照することで、ファイルシステムと管理ファイルの整合性について判定するようにすることが考えられる。上記ステイタス情報は、例えばコンテンツファイルの操作などに応じて、ファイルシステム管理情報と管理ファイルの書き換え処理を実行しているときに、その処理経過に応じて変化する状態に応じて、内容を随時変更させていく。
【００５７】
図５を参照して、ファイル操作に応じたファイルシステム側の管理内容の変更（更新）、及び管理ファイルの書き換え処理（ファイル管理内容更新処理）の流れと、ステイタス情報の内容との対応例について説明する。なお、ここでは、後述する本実施の形態としてのファイルシステム及び管理ファイルの書き換え処理との差異を明確にするために、本実施の形態において存在する管理ファイルのバックアップファイルは存在しないことを前提とした処理手順となっている。
【００５８】
図５（ａ）には、例えばコンテンツファイル操作に応じたファイル管理内容更新処理の手順例が示され、図５（ｂ）には、図５（ａ）に示される手順に応じた、ファイルシステム側によるファイル管理内容と管理ファイルのファイル管理内容に関しての状態（ファイル管理内容状態）についての遷移が示される。
先ず、この場合における図５（ａ）の手順１としての状態は、ファイルシステムにより記憶媒体に記憶されているものとして管理されるコンテンツファイルが、コンテンツファイルＡ、Ｂの２つとされており、かつ、管理ファイルによっても、コンテンツファイルＡ、Ｂのそれぞれについて適正に管理している状態にあるとされている。また、コンテンツファイル操作に関連した処理の流れにおいてこの状態をみた場合には、特にコンテンツファイルの操作については行われていない、「定常」の処理状況にあるものとされる。
そして、このときには上記もしているように、双方が、コンテンツファイルＡ，Ｂを適正に管理している。つまり、このときのファイル管理内容状態としては、図５（ｂ）に示すように、現実の記録状態（ファイルシステム以下のレベルでの記録状態）に対して「整合」している状態にあるといえる。
【００５９】
そして、上記図５（ａ）の手順１としての状態の下で、ファイル操作として、コンテンツファイルＣの追加が行われるものとする。このファイル操作に応じては、先ず、手順１に続く手順２（処理状況：「コンテンツファイル追加中」）により、実のコンテンツファイルＣについての処理が行われる。つまり、コンテンツファイルＣとしてのデータを実際にＨＤＤ１４に対して書き込むとともに、コンテンツファイルＣのデータについての書き込み結果が反映されるようにして、ファイルシステム管理情報についての書き換えを実行する。
このときは、例えばファイルシステム以下のレベルではコンテンツファイルＣが作成されているとみることのできる状況であるのに対して、管理ファイルには、コンテンツファイルＣに関する情報が全く反映されていない状態である。このために、このときの実コンテンツファイルの記録状態と管理ファイルとは、整合がとれていないことになる。つまり、この手順２のときには、図５（ｂ）に示されるファイル管理内容状態は、「不整合」であることになる。
【００６０】
次の図５（ａ）の手順３は、上記手順２によるコンテンツファイルＣの追加記録が完了し、次の管理ファイルの書き換えを開始するまでのインターバルの期間となる。このときは、特にデータ書き換えのためにＣＰＵが処理を実際に実行しているタイミングではないことから、「定常」の処理状況であることになる。しかし、ファイルシステムと管理ファイルのファイル管理内容を比較してみると、ファイルシステム管理情報によっては、コンテンツファイルＡ、Ｂに加えて、コンテンツファイルＣも適正管理されている状態であるのに対して、管理ファイルでは、未だ、コンテンツファイルＡ、Ｂのみを管理する状態のままとなっている。従って、図５（ｂ）に示されるファイル管理内容状態は、「不整合」となる。
【００６１】
続く図５（ａ）の手順４は、管理ファイルによりコンテンツファイルＣを適正管理するように、この管理ファイルを書き換える処理となる。つまり、このときの処理状況としては「管理ファイル更新中」となる。また、このときの管理ファイルの内容は、書き換え途中の不完全な状態となっている。つまり、管理ファイルの内容としては、正常ではない。そこで、図５（ｂ）に示されるファイル管理内容状態は、「管理ファイル異常」として扱う。
【００６２】
そして、上記手順４によるファイルシステム管理情報の書き換えが完了し、手順５として示す「定常」の処理状況に至ったとされると、ファイルシステムと管理ファイルの両者が、コンテンツファイルＡ、Ｂ、Ｃを適正管理する内容を有することになる。つまり、図５（ｂ）のファイル管理内容状態は「整合」に復帰する。
【００６３】
ステイタス情報としては、図５（ａ）に示す手順１〜５に応じた処理状況の遷移に応じて、図５（ｂ）に示すようにしてその内容を書き換えていく（変更していく）ようにする。そして、例えば電源が投入されて起動するごとに、そのときに記憶保持されているステイタス情報の内容を参照するようにされる。
例えば、手順１の「定常」の処理状況において、電源が遮断されるなどの障害が発生して処理を終了した、あるいは手順１の場合であれば、この状態で通常に電源をオフとすることが行われたとされると、ステイタス情報としては、「整合」を示す内容が記憶保持された状態で終了することになる。すると、次の電源起動時においてステイタス情報を参照すると、この「整合」を示す内容が認識されることになる。
ステイタス情報が「整合」を示していれば、特にファイルシステム及び管理ファイル間の整合性復帰のための処理などを実行することなく通常に起動処理を完了させる。この場合、前回の電源オン時において最後に追加されたコンテンツファイルＣは存在していないが、ファイルＡ、Ｂが正常に管理されている状態から機器の使用を開始することができる。
【００６４】
これに対して、手順２または手順３の「コンテンツファイル追加中」「定常」の処理状況の中途において、不意の電源の遮断などの障害が発生して中断終了したとされると、「不整合」を示すステイタス情報が記憶され、次回の起動時において、この「不整合」を示す内容が参照されることになる。このようにして「不整合」であることが認識された場合には、ファイルシステム管理情報と、管理ファイルの内容を比較してその内容の差分を求める。そして、この差分が解消されるように、ファイルシステム管理情報、若しくは管理ファイルの内容を書き換えるようにされる。
また、手順４の「管理ファイル更新中」の処理状況中にて障害が発生して中途終了した場合には、「管理ファイル異常」を示すステイタス情報が記憶され、次回の起動時において、この「管理ファイル異常」を示す内容が参照されることになる。
この場合には、管理ファイルの状態として、２つの場合を考えることができる。１つは、管理ファイルがコンテンツファイルＡ、Ｂのみを適正管理して、コンテンツファイルＣを管理していない状態であり、もう１つは、管理ファイルそのものが破壊された場合である。前者は、例えばメモリ上で管理ファイルの内容の書き換えを実行中の場合など、未だ記憶媒体（ＨＤＤ１４）の管理ファイルの更新処理を実行していない段階で中断終了した場合に生じる。後者は、メモリ上での管理ファイルの書き換えを終了して、その内容を記憶媒体に書き込んでいる途中などに中断終了した場合などに生じる。
前者の場合には、ファイルシステムと管理ファイルの内容を比較することで、管理ファイル側においてコンテンツファイルＣが管理されていないことが、差分として認識される。従って、この場合にも、先の手順３と同様にして、コンテンツファイルＣについては削除して、コンテンツファイルＡ，Ｂのみを適正管理した状態で整合を取るようにしてファイルシステム管理情報などを書き換えることができる。あるいは、管理ファイルによってもコンテンツファイルＣを適正管理するように、管理ファイルの書き換えを行うことも可能とされる。
後者のようにして管理ファイル自体が破壊されてしまっているときには、管理ファイルを再作成する。このためには、ファイルシステムを利用して記憶媒体に記憶されるすべてのコンテンツファイルにアクセスして管理ファイル作成に必要な情報を収集し、これらの情報を利用して管理ファイルを作成する。そして、この作成した管理ファイルを、改めて記憶媒体に記憶させる。このようにして、破壊された管理ファイルが正常復帰する。なお、このときには、バックアップファイルも、再作成された管理ファイルに一致した内容を有するように更新される。
【００６５】
また、手順５の「定常」の状況の下で処理が終了した場合の次の電源起動時においては、ステイタス情報が「整合」となっているので、特にファイルシステム及び管理ファイル間の整合性復帰のための処理などを実行することなく通常に起動処理を完了させる。この場合には、コンテンツファイルＡ，Ｂ，Ｃが適正管理された状態で、起動後の動作に移行する。
【００６６】
このように、図５により説明したようにしてステイタス情報を使用することとすれば、先ずはステイタス情報を参照するだけで、ファイルシステムと管理ファイルの内容が整合しているか否かを判定できることになる。これにより、例えば起動時における整合性の判定のために、記憶媒体に記憶されるコンテンツファイルにアクセスする必要はなくなり、起動時間が短縮されることになる。
また、図５にて説明したステイタス情報は、整合以外の状態として、「不整合」と「管理ファイル異常」の２つの状態を区分していることから、この状態区分に応じて、整合性を復帰させるための適切な処理を選択することができるものであり、整合性復帰の処理も効率的になる。
【００６７】
ただし、上記もしたように、「管理ファイル異常」とされて管理ファイルが破壊された状態となったときには、管理ファイルをはじめから再作成することになる。再作成の処理にあたっては、記憶媒体に記憶される管理対象のコンテンツファイルのすべてにアクセスして必要な情報の収集を行う必要があることから、相応の時間を要することになる。つまり、管理ファイルが破壊されてしまった状態での起動の場合には、起動時間が長くなってしまうことになる。
【００６８】
そこで、本実施の形態としては、図５の構成を基として、管理ファイルが破壊された状態での起動についても、その起動時間がより短縮される構成を提案するものである。かかる本実施の形態としての構成について、以降説明していくこととする。
【００６９】
本実施の形態としては、先に図２などにより明示したように、管理ファイルとともに、管理ファイルのバックアップファイルも、記憶媒体であるＨＤＤ１４に記憶させることとしている。
一般に、バックアップファイルは、バックアップ元のオリジナルのファイルが何らかの原因で破壊、消失してしまったときに、その内容を復元するために用意されるものであり、このために、例えば記憶媒体に記憶されるオリジナルのファイルと同一内容を有するべきものとされている。この点では、本実施の形態のバックアップファイルも同様である。つまり、本実施の形態のバックアップファイルは、ＨＤＤ１４に記憶されるオリジナルの管理ファイルと常に一致した内容を有するように更新が行われるべきものとされる。そして、管理ファイルが破壊、消失してしまったときには、管理ファイルを再作成するときに、このバックアップファイルの内容を利用するようにされる。
このようにしてバックアップファイルを利用可能となることで、管理ファイルをはじめから再作成するのに、図５の場合のようにして記憶媒体に記憶されるコンテンツファイルのすべてにアクセスする必要はなくなる。また、バックアップファイルの内容を利用した管理ファイルの作成は、例えばより具体的には、バックアップファイルの内容のデータを、管理ファイル形式のデータ構造にコピーするというような処理によって行うことができる、このような処理は、記憶媒体に記憶されるコンテンツファイルのすべてにアクセスすることと比較すれば非常に短時間である。つまり、管理ファイルのバックアップファイルを備えることで、管理ファイルが破壊、消失したときの復帰に要する時間は短縮され、これに応じて、例えば起動時間も大幅に短縮されることになる。
【００７０】
上記のようにして、本実施の形態としては、管理ファイルのバックアップファイルを設けることとしている。このために、コンテンツファイルの操作に応じて、ファイルシステム管理情報、管理ファイルを更新した場合には、バックアップファイルについても更新を行う必要があることになる。また、管理ファイルについての整合性の判定は、ファイルシステム以下のレベルのデータ管理状況と管理ファイルのみだけではなく、これにバックアップファイルを加えた三者間で行うことが必要になる。そのうえで、整合性の判定には、図５に準じたステイタス情報を利用することになる。
【００７１】
図６は、本実施の形態としての、或るコンテンツファイル操作例に応じた、ファイルシステム、管理ファイル、及びバックアップファイルの書き換え処理の流れと、ステイタス情報が示すべき状態との対応を示している。
なお、この場合にも、図５と同様に、図６（ａ）には、コンテンツファイル操作に応じた処理手順例が示され、図６（ｂ）には、図６（ａ）に示される手順に応じた、管理ファイルの内容状態についての遷移が示される。なお、図６（ｂ）に示されるファイル管理内容状態には、この管理ファイルに対応するバックアップファイルも含むものとして考えるべきものとなる。
また、この場合のコンテンツファイル操作例としては、図５の場合と同様に、コンテンツファイルＡ，Ｂを管理している状態から、コンテンツファイルＣを新規に記録する場合を挙げることとする。
【００７２】
この場合の図６（ａ）の手順１として、「定常」の処理状況となっている状態は、ファイルシステムにより記憶媒体に記憶されているものとして管理されるコンテンツファイルが、コンテンツファイルＡ、Ｂの２つとされており、かつ、管理ファイルによっても、コンテンツファイルＡ、Ｂのそれぞれについて適正に管理している状態にあるとされている。このようにして、はじめに管理対象となるコンテンツファイルの内容は、図５の場合と同様となっている。さらに、この場合には、管理ファイルのバックアップファイルも、現在の管理ファイルに一致する内容を有しているものとされ、コンテンツファイルＡ、Ｂのそれぞれを適正管理する内容となっている。
従って、このときには、ファイルシステム、管理ファイル、バックアップファイルの三者の何れも、コンテンツファイルＡ，Ｂを適正管理していることになる。つまり、ファイル管理内容状態としては、図６（ｂ）に示すようにして、ファイルシステム（及びバックアップファイル）と「整合」している状態にあることになる。
【００７３】
この場合にも、上記図６（ａ）の手順１としての状態の下でのファイル操作としては、コンテンツファイルＣの追加記録を行うこととしている。このファイル操作に応じた手順１に続く手順２としては、図５の場合と同様にして、「コンテンツファイル追加中」の処理状況となるものであり、ＨＤＤ１４へのコンテンツファイルＣの実データの書き込みを実行させると共に、ファイルシステム管理情報（ディレクトリエントリ、ＦＡＴ）について、コンテンツファイルＣを登録するための書き換えを実行する。
このときには、図５のときと同様に、例えばファイルシステム以下のレベルではコンテンツファイルＣが作成されているとみることのできる状況であるのに対して、管理ファイルには、コンテンツファイルＣに関する情報が全く反映されていない状態となる。従って、この場合の手順２のときにも、図６（ｂ）に示されるファイル管理内容状態は、「不整合」となる。
【００７４】
次の図６（ａ）の手順３は、上記手順２によるコンテンツファイルＣの追加に応じたファイルシステムの書き換えが完了し、次の管理ファイルの書き換えを開始するまでのインターバルの期間としての「定常」の処理状況となる。このときに、ファイルシステム管理情報によっては、コンテンツファイルＡ、Ｂに加えて、コンテンツファイルＣも適正管理されている状態であるのに対して、管理ファイル及びバックアップファイルの内容は、未だ、コンテンツファイルＡ、Ｂのみを管理する状態のままとなっている。従って、図６（ｂ）に示されるファイル管理内容状態は、「不整合」に変化する。
【００７５】
続く図６（ａ）の手順４は、管理ファイルによりコンテンツファイルＣが適正管理されるように、この管理ファイルを書き換える処理となり、処理状況としては「管理ファイル更新中」となる。このときも、図５の手順４と同様に、管理ファイルの内容は、書き換え途中の不定的な状態となっていることから、図６（ｂ）に示される管理ファイルの状態としては、「管理ファイル異常」となる。
【００７６】
手順５は、上記手順４によるファイルシステム管理情報の書き換えが完了して「定常」の処理状況に至った段階である。図５の場合には、この段階で、ファイルシステムと管理ファイルの両者が、コンテンツファイルＡ、Ｂ、Ｃを適正管理する内容を有することとなって、ファイルシステム及び管理ファイルの内容状態は「整合」に復帰していた。
しかしながら、図６の場合には、ファイルシステムと管理ファイルは、上記と同じくコンテンツファイルＡ、Ｂ、Ｃを適正管理する内容になっているが、バックアップファイルについては、コンテンツＡ、Ｂのみを管理する、以前の内容のままとなっている。このために、管理ファイルの状態としては、この管理ファイルに対応するバックアップファイルが、管理ファイルに対して不整合となっていることになる。この状態は「バックアップ異常」として扱うようにされる。
【００７７】
そこで、次の手順６としては、バックアップファイルによってもコンテンツファイルＣが適正管理されるようにバックアップファイルを書き換える、「バックアップ更新中」の処理状況に移行する。このようにして、バックアップファイルの内容を実際に書き換えている状態では、その内容は不定的であり、未だ、コンテンツファイルＣが適正管理される状態には至っていない。このために、管理ファイル（及びバックアップファイル）の状態としては、手順５に引き続き「バックアップ異常」となる。
【００７８】
そして、上記手順６によるファイルシステム管理情報の書き換えが完了し、手順７としての「定常」の処理状況に至ったとされると、ファイルシステム、管理ファイル、及びバックアップファイルの三者が、コンテンツファイルＡ、Ｂ、Ｃを適正管理する内容を有することになり、図６（ｂ）の状態は「整合」に復帰する。
【００７９】
本実施の形態のステイタス情報としては、上記図６（ｂ）に示すようにして、図６（ａ）の処理状況の遷移に応じて、その内容を変更していくようにすればよい。そして、本実施の形態の場合にも、このステイタス情報を不揮発性の記憶領域（ＨＤＤ１４、不揮発性メモリ１２ａなど）に記憶保持させておくこととして、電源が投入されて起動するごとに、そのときに記憶保持されているステイタス情報の内容を参照する。
【００８０】
例えば、この場合においても、手順１の「定常」の処理状況において電源オフ操作、あるいは電源が遮断されるなどして処理を終了したとされると、ステイタス情報としては、「整合」を示す内容が記憶保持された状態で終了し、次の電源起動時においては、ステイタス情報として、この「整合」を示す内容が認識される。そこで、この場合には、ファイルシステム、管理ファイル、バックアップファイル間の整合性復帰のための処理を実行することなく通常に起動処理を完了させる。この場合、前回の電源オン時において最後に追加されたコンテンツファイルＣは存在していないが、ファイルＡ、Ｂが正常に管理されている状態から機器の使用を開始できる。
【００８１】
また、手順２又は手順３の「コンテンツファイル追加中」「定常」の処理状況の中途で、何らかの障害の発生により中断終了したのであれば、「不整合」を示すステイタス情報が記憶されることになり、次回の起動時において、この「不整合」を示す内容が参照される。このようにして「不整合」であることが認識された場合には、図５と同様に、ファイルシステム管理情報と、管理ファイルと、バックアップファイルとの内容を比較して、その内容の差分が解消されるように、ファイルシステム管理情報、管理ファイル、及びバックアップファイルのうちで所要のものの内容を書き換えるようにされる。
この手順２又は手順３の不整合の状態では、管理ファイルとバックアップファイルは、コンテンツファイルＡ，Ｂのみを適正管理しており、コンテンツファイルＣは存在していないのに対して、ファイルシステム管理情報側では、コンテンツファイルＡ，Ｂに加えてコンテンツファイルＣを管理する内容が、不完全、又は完全な状態で保持されているという、内容状態にあることになる。
そこで、この手順２又は手順３の不整合の状態に応じた、ファイルシステム管理情報、管理ファイル、バックアップファイル等の内容変更の仕方であるが、１つには、一律にコンテンツファイルＣを追加記録する以前の、コンテンツファイルＡ，Ｂのみが適正管理されている状態に、正常に戻してしまうようにすることが考えられる。つまり、ファイルシステムのファイル管理情報を、管理ファイル及びバックアップファイルの内容に一致させるようにして書き換えるものである。
ただし、ファイルシステムのファイル管理情報において、コンテンツファイルＣを管理する内容が完全な状態で保持されており、また、アプリケーション側で、最後のファイル操作がコンテンツファイルＣを追加記録するものであることが分かっているのであれば、コンテンツファイルＣが適正管理される状態で整合がとれるように、これらファイルシステム管理情報、管理ファイル、及びバックアップファイル等の内容を変更してもよい。このためには、ファイルシステムを利用して、ＨＤＤ１４に記憶されるコンテンツファイルＣにアクセスして、このコンテンツファイルＣについての管理ファイル作成に必要な情報を収集し、この収集した情報を利用して、コンテンツファイルＣが適正管理されるように管理ファイル更新のための書き換えを行う。さらに、この更新された管理ファイルの内容が反映されるように、バックアップファイルも更新するものである。
【００８２】
また、手順４の「管理ファイル更新中」の処理状況の中途にて終了した場合には、「管理ファイル異常」を示すステイタス情報が記憶され、次回の起動時において、この「管理ファイル異常」を示す内容が参照される。
この場合にも、図５の手順４と同様にして、管理ファイルの状態としては、管理ファイルはコンテンツファイルＡ、Ｂを適正管理しているが、コンテンツファイルＣを管理する内容は存在しない、あるいは不完全なために、コンテンツファイルＣについては管理が為されていない状態の場合と、管理ファイルそのものが破壊された場合、との２つの可能性を考えるべきことになる。そして、前者の場合には、図５の場合と同様にして、管理ファイルによってもコンテンツファイルＣを適正管理するように、管理ファイルの書き換えを行うようにされる。また、後者のようにして、管理ファイル自体が破壊されてしまっているときには、管理ファイルを再作成することになる。
【００８３】
そして、本実施の形態の場合には、上記のようにして管理ファイルを再作成するのにあたっては、例えばバックアップファイルを読み出し、その内容を管理ファイル形式にコピーするようにして作成するようにされる。このようにして管理ファイルの再作成のためにバックアップファイルを利用することで、図５のようにして、ファイルシステムを利用して記憶媒体に記憶されるすべてのコンテンツファイルにアクセスする必要はなくなり、管理ファイル再作成に要する時間は大幅に短縮され、これに伴って、起動時間の短縮も図られることになる。
【００８４】
また、図６の手順５又は手順６の「定常」「バックアップ更新中」の処理状況の中途で、何らかの障害発生により中断終了したのであれば、「バックアップ異常」を示すステイタス情報が記憶されることになり、次回の起動時においては、「バックアップ異常」であることが認識される。
この「バックアップ異常」の状態では、ファイルシステム管理情報と管理ファイルは、コンテンツファイルＡ，Ｂ，Ｃを適正管理して整合している状態にあるが、バックアップファイルのみがコンテンツファイルＣを適正管理していない内容状態となっているか、あるいは、バックアップファイルが破壊されている状態であることになる。そこで、この場合には、バックアップファイルが管理ファイルと一致した内容を有するものとなるように、バックアップファイルの書き換え、あるいは再作成を行うようにされる。このためには、管理ファイルのデータ内容から、必要なデータ部分をコピーするようにして、バックアップファイルの書き換え又は再作成の処理を行うようにすればよい。このようにして、バックアップファイルを再作成する場合にも、例えばファイルシステムを利用して記憶媒体に記憶されるすべてのコンテンツファイルにアクセスする必要はない。
【００８５】
また、手順７の「定常」の状況の下で処理が終了した場合の次の電源起動時においては、ステイタス情報が「整合」となっているので、特にファイルシステム、管理ファイル、及びバックアップファイルの間での整合性復帰のための処理などを実行することなく、通常に起動処理を完了させる。この場合には、コンテンツファイルＡ，Ｂ，Ｃが適正管理された状態で、起動後の動作に移行する。
【００８６】
上記図６（ｂ）に示したようにして変更されるステイタス情報としては、例えば、システム領域のデータ、あるいはファイルシステムにより管理可能な何らかの形式のファイルとして、不揮発性の記憶領域に記憶保持されればよい。本実施の形態のデジタルビデオカメラ１であれば、例えばＨＤＤ１４、あるいは不揮発性メモリ１２ａに保持させればよいことになる。
【００８７】
また、本実施の形態のステイタス情報の最も基本的な形態としては、例えば図６（ｂ）に示す状態遷移を示す１つの単位情報をステイタス情報として用意し、これを不揮発性の記憶領域に記憶保持させることとすればよい。
しかしながら、図６（ａ）に示す処理を実際に実行するのにあたっては、後述もするようにして、図６（ａ）の流れの中での処理を制御するソフトウェア階層は同一ではない。例えば図２の階層構造との対応では、図６の手順２に対応したコンテンツファイルの追加記録処理のための制御（ファイルシステムに対する制御）は、アプリケーションが行う。これに対して、手順４、６などに対応する管理ファイルの更新、バックアップファイルの更新などの処理は、管理ファイル制御システムが制御する。
【００８８】
このような実情を考慮すると、図６（ａ）に示される処理の流れに応じたステイタス情報の管理を同一のソフトウェア階層により行うことは、かえって効率的でないということがいえる。
例えば、アプリケーションにより、ステイタス情報を一元的に管理しようとすると、手順２のコンテンツの追加は、自身でその実行タイミングをほぼ正確に把握できるので、適正にステイタス情報の内容を変更できるが、手順４以降の処理の実行タイミングを認識するには、管理ファイル制御システムからの通知を受ける必要がある。このために、例えば通知のための通信のタイムラグなどにより、アプリケーション側でのステイタス情報の変更タイミングと、実際の処理タイミングとの誤差が大きくなってしまうなどの不利点が生じてくる。
【００８９】
そこで、本実施の形態の実際としては、図６（ｂ）に示す、処理経過に応じたステイタス情報の遷移を、２つのステイタス情報要素を利用して管理するようにされる。この点について、図７を参照して説明する。
図７（ａ）（ｂ）には、それぞれ、図６（ａ）と同じ処理手順例と、図６（ｂ）と同じファイル管理内容状態の遷移が示されている。そして、図７（ｃ）には、一方のステイタス情報要素である、上位処理層側ステイタス情報の内容遷移が示され、図７（ｄ）には、もう一方のステイタス情報要素である下位処理層側ステイタス情報の内容遷移が示される。
上位処理層側ステイタス情報は、アプリケーションが管理、操作するステイタス情報要素であって、本実施の形態のデジタルビデオカメラ１の場合には、アプリケーションからの制御により、不揮発性メモリ１２ａに記憶保持される。
下位処理層側ステイタス情報は、アプリケーションに対しては下位として扱われる、管理ファイル制御システムが管理、操作するステイタス情報要素であって、ＨＤＤ１４に記憶保持される。
【００９０】
先ず、図７（ａ）の手順１の「定常」の状況の段階では、上位処理層側ステイタス情報と下位処理層側ステイタス情報は、ともに「整合」を示している。そして、手順２による「コンテンツ追加中」の処理状況となって、アプリケーションの制御によりファイルシステムの更新を実行させるタイミングになったとされると、アプリケーションは、上位処理層側ステイタス情報を「不整合」に変更する。また、この手順２が終了して手順３としての「定常」の状況になったときにも、上位処理層側ステイタス情報は、「不整合」の内容を示すことになる。
一方の下位処理層側ステイタス情報であるが、手順２によりアプリケーションがファイルシステムを更新している段階では、まだ管理ファイル（又はバックアップファイル）の操作を行っていないことから、管理ファイル制御システムは、下位処理層側ステイタス情報の操作も行わない。このために、下位処理層側ステイタス情報としては、手順１に引き続き、手順２から手順３まで、「整合」を示したままの状態である。
【００９１】
そして、手順４に遷移して、管理ファイル制御システムが管理ファイルを更新するための制御を行うべきタイミングになったとされると、管理ファイル制御システムは、下位処理層側ステイタス情報を、これまでの「整合」を示す内容から、「管理ファイル異常」を示す内容に変更する。
そして、上記手順４による管理ファイルの更新が完了して、手順５としての「定常」の状況に遷移したとされると、管理ファイル制御システムは、ここで下位処理層側ステイタス情報の内容を「バックアップ異常」に変更する。また、これに続いて手順６によりバックアップファイルを更新しているときにも、管理ファイル制御システムは、手順５の開始時からの「バックアップ異常」の内容を維持させる。
【００９２】
上記のようにして、手順４から手順６までにより、管理ファイル制御システムが管理ファイルの更新と、バックアップファイルの更新とを行っている間においては、アプリケーションでは、上位処理層側ステイタス情報については特に変更を行わない。このために、手順４から手順６に対応する期間の上位処理層側ステイタス情報は、手順２の開始タイミングに応じて設定された「不整合」の内容が維持されることになる。
【００９３】
そして、手順６としてのバックアップファイルの更新を終了して、手順７としての「定常」の状況に遷移したとされるのに応じて、管理ファイル制御システムは、下位処理層側ステイタス情報の内容を「バックアップ異常」から「整合」に変更する。また、アプリケーションも、上位処理層側ステイタス情報を「不整合」から「整合」の状態に戻すようにされる。
【００９４】
そして、例えば電源起動時などにおける管理ファイルの整合性の判定にあたっては、図７（ｃ）（ｄ）にわたって破線で括って示しているステイタス情報要素の内容を、ステイタス情報が示す内容として扱うようにされる。つまり、手順１から手順３までの間の状態で処理が中途終了したとされる場合の次の電源起動時においては、ステイタス情報の内容として、上位処理層側ステイタス情報の内容を採用して整合性判定を行う。また、手順４から手順７までの間の状態で処理が中途終了したとされる場合の次の電源起動時においては、ステイタス情報の内容として、下位処理層側ステイタス情報の内容を採用して整合性判定をおこなう。確認のために述べておくと、下位処理層側ステイタス情報において、手順２，３に対応して設定される「整合」の内容は、無効となるものである。
このようにして手順ごとに対応して採択するステイタス情報の内容を、上位処理層側ステイタス情報と下位処理層側ステイタス情報から選べば、図７（ｂ）に示す、本来のステイタス情報が有するべき内容の遷移と一致することになる。
【００９５】
図８は、上記図７（ａ）に示した処理手順と、図７（ｃ）（ｄ）に示されるステイタス情報（上位処理層側ステイタス情報、及び下位処理層側ステイタス情報）の変更の処理を、アプリケーション、管理ファイル制御システム、及びファイルシステムの階層間の処理として示すものである。
図７の例では、コンテンツファイルＣの追加記録となっている。これに応じて、先ず、アプリケーションが、ステップＳ１０１としての手順により、管理ファイル制御システムに対してコンテンツファイルの記録を要求する。このステップＳ１０１の処理の開始が、図７における手順１の状態から、手順２に遷移したときに相当する。
【００９６】
また、アプリケーションは、上記ステップＳ１０１により管理ファイル制御システムに対してコンテンツファイル（図７ではコンテンツファイルＣとなる）の記録要求を行うとともに、ステップＳ１０２として示すように、ファイル操作内容を示す操作内容情報がコンテンツファイルの記録を意味するものとなるように書き換える処理を実行する。この操作内容情報は、上記ステップＳ１０２としての手順からも分かるように、アプリケーションが管理するもので、例えば不揮発性メモリ１２ａに記憶保持されるべきものとする。ステップＳ１０３は、操作内容情報を不揮発性メモリ１２ａに更新書き込みしたことに応じて下位処理層から応答が返され、これをアプリケーションが受ける手順となる。
【００９７】
操作内容情報は、例えば図７との対応では、次のようにして利用することができる。ここで、図７の手順３の状況において処理の中途終了が生じたとすると、次回起動時において、ステイタス情報は「不整合」を示しており、その不整合の状態としては、ファイルシステムはコンテンツファイルＡ，Ｂ，Ｃを管理しているのに対して、管理ファイルとバックアップファイルはコンテンツファイルＡ，ＢのみでコンテンツファイルＣは管理していない状態である。
この状態は、本実施の形態の実際としては、例えば後述する図９の手順５の処理状況において処理が中途終了した場合の状態と同様となる。この図７の処理は、コンテンツファイルＣを記録するファイル操作に応じたものであるから、可能であれば、コンテンツファイルＣが適正管理される状態で整合性を復帰させることが好ましい。一方の図９の処理は、後述するように、コンテンツファイルＣを削除するファイル操作に応じたものとなるので、可能であれば、コンテンツファイルＣは削除されて、コンテンツファイルＡ，Ｂのみが適正管理される状態で整合性を復帰させることが好ましい。
例えば、操作内容情報が存在しなければ、上記した不整合の状態であるときに、それがコンテンツファイルＣを追加記録しているときの中断によるものであるのか、あるいはコンテンツファイルＣを削除しているときの中断によるものであるのかを判定することは難しい。そこで、本実施の形態のようにして操作内容情報を設けて、不揮発性メモリ１２ａに記憶保持させておくようにすれば、電源起動時において、操作内容情報を読み込んで参照することで、起動前の最後のファイル操作が何であるのかを認識できることになり、例えばファイルシステム管理情報と管理ファイル（及びバックアップファイル）の整合性を復帰させるときにも、より適切なファイル管理内容となるようにすることが可能になる。
【００９８】
また、操作内容情報は、図１０により後述するようにして起動処理を実行するのにあたり、最後のコンテンツファイル操作が追加記録と削除の何れであるのかに応じて、その処理を分岐させるときに、最後のコンテンツファイル操作が何であったのかを判定するための情報としても利用される。
【００９９】
また、アプリケーションは、上記ステップＳ１０２、Ｓ１０３（応答）により操作内容情報を書き換えると、続けて、ステップＳ１０４、Ｓ１０５（応答）により、上位処理層側ステイタス情報の内容を、これまで「整合」とされていた状態から、「不整合」に変更して、不揮発性メモリ１２ａに記憶し直す処理を実行する。
【０１００】
また、ステップＳ１０１のコンテンツファイルの記録要求を受けた管理ファイル制御システムでは、ステップＳ１０６により、コンテンツファイル作成のための要求をファイルシステムに対して行う。ファイルシステムがステップＳ１０７により、この要求に応じた応答を行うと、この応答を受けた管理ファイル制御システムは、さらにステップＳ１０８によりアプリケーションに対して応答を返す。
【０１０１】
ステップＳ１０８による応答を受けたアプリケーションは、ステップＳ１０９により、管理ファイル制御システムに対して、今回のコンテンツファイルの記録に応じた管理ファイルへのコンテンツ登録を要求する。管理ファイル制御システムは、この要求に応じた処理として、ここでは、先ず、ステップＳ１１０により、下位処理層側ステイタス情報について、これまでの「整合」から、「管理ファイル異常」を示すものとなるように変更するための制御を実行する。このステップＳ１１０の制御により下位処理層側ステイタス情報の変更が完了すると、下位処理層からの応答が返されてくるので、管理ファイル制御システムは、この応答をステップＳ１１１により受け取る。なお、ここでは、ＨＤＤ１４に記憶される下位処理層側ステイタス情報は、ファイルシステムが管理可能なファイル形式ではなく、システム領域に格納される情報であることとしており、このために、図８では、下位処理層側ステイタス情報の変更、書き換え処理にあたっては、ファイルシステムを経由していない状態で示している。
【０１０２】
次に、管理ファイル制御システムは、ステップＳ１１２により、今回のコンテンツファイルの記録に応じた管理ファイルの更新（書き換え）のための処理を行う。つまり、例えば管理ファイル制御システムは、ＨＤＤ１４からファイルシステム経由で読み込んだ管理ファイルについて、今回のコンテンツファイル記録に応じた変更を行い、この変更内容が、ＨＤＤ１４に記憶される管理ファイルの内容に反映されるように、ＨＤＤ１４に対するアクセス、データ記録をファイルシステム経由で行う。このＨＤＤ１４に記憶される管理ファイルの更新が完了すると、管理ファイル制御システムの下位層からは応答が返される。管理ファイル制御システムは、ステップＳ１１３により、この応答を受け取ると、さらにステップＳ１１４により、アプリケーションに対して応答を返すようにされる。
【０１０３】
上記ステップＳ１１４により管理ファイル制御システムから返された応答を受け取ることで、アプリケーションは、ステップＳ１０９により要求した管理ファイルへのコンテンツファイルの登録が正常に終了したことを認識する。そして、次にアプリケーションは、ステップＳ１１５によりバックアップファイル更新のための要求を管理ファイル制御システムに対して行う。
【０１０４】
バックアップファイル更新要求を受けた管理ファイル制御システムは、バックアップファイル更新の処理に先だって、ステップＳ１１６により、下位処理層側ステイタス情報の内容を、これまでの「管理ファイル異常」から「バックアップ異常」に変更して記憶し直させる処理を実行する。このバックアップファイルの記憶が完了したとされると、ステップＳ１１７により下位処理層から返される応答を受け取る。
【０１０５】
そして、上記した下位処理層側ステイタス情報の更新が完了したとされると、管理ファイル制御システムは、ステップＳ１１８により、ファイルシステムを利用して、バックアップファイル更新のための処理を実行する。つまり、例えばファイルシステムを利用したＨＤＤ１４に対するバックアップファイルの読み出し、書き込みを伴って、上記ステップＳ１１２にて更新した管理ファイルの内容が反映されるようにバックアップファイルの更新を行う。この処理の応答は、ステップＳ１１９の手順として返される。
【０１０６】
上記のようにしてバックアップファイルの更新が完了すると、さらに管理ファイル制御システムは、ステップＳ１２０により、これまで「バックアップ異常」を示していた下位処理層側ステイタス情報について、「整合」を示すようにして変更を行う。この処理に対する応答は、ステップＳ１２１として返される。
【０１０７】
上記ステップＳ１２１により応答を受け取った管理ファイル制御システムは、ステップＳ１２２により、アプリケーションに対してさらに応答を返すようにされる。アプリケーションは、この応答を受け取ることで、ステップＳ１１５により要求したバックアップファイルの更新が正常に実行されたことを認識することになる。
すると、アプリケーションは、ステップＳ１２３として示すように、上位処理層側ステイタス情報について、これまでの「不整合」から「整合」に変更するための処理を実行する。この処理に応じた下位処理層からの応答はステップＳ１２４により返される。
続いてアプリケーションは、ステップＳ１２５として示すようにして、これまでコンテンツファイルの記録を示していた操作内容情報について、クリアするための処理を実行する。この処理に対する応答は、ステップＳ１２６により行われる。
【０１０８】
例えば図７においては、手順７から手順８への遷移に応じて、上位処理層側ステイタス情報と下位処理層側ステイタス情報のいずれも、「整合」を示す内容に戻すようにされているが、図８から理解されるように、下位処理層側ステイタス情報が整合に戻るのは、アプリケーションがステップＳ１２２により応答を受けて後のタイミングとなる。これに対して、下位処理層側ステイタス情報が、「バックアップ異常」から「整合」に戻るのは、ステップＳ１１８、Ｓ１１９によりバックアップファイルの更新が完了してほぼ直後のタイミングとなっている。つまり、図７の手順７に対応する、「整合」の内容を示すステイタス情報としては、上位処理層側ステイタス情報よりも下位処理層側ステイタス情報のほうが、より実際の処理に近いタイミングで変更されていることが分かる。
また、下位処理層側ステイタス情報が、「整合」から「管理ファイル異常」に変更されるタイミング（ステップＳ１１０の処理タイミング）は、ステップＳ１０９による管理ファイルへのコンテンツ登録（管理ファイルの更新）要求に応じたものとして、Ｓ１１２の管理ファイル更新処理とともに実行されるものとなっている。同様に、下位処理層側ステイタス情報が、「管理ファイル異常」から「バックアップ異常」に変更されるタイミング（ステップＳ１１６の処理タイミング）も、ステップＳ１１５によるバックアップファイルの更新要求に応じたものとして、Ｓ１１８のバックアップファイル更新処理とともに実行されるものとなっている。つまり、下位処理層側ステイタス情報が、「管理ファイル異常」若しくは「バックアップ異常」の内容を有しているタイミングは、管理ファイルを実際に書き換えているタイミング、若しくはバックアップファイルを実際に書き換えているタイミングとほぼ一致しているものとみてよいことになる。
仮に、これらの「管理ファイル異常」、「バックアップ異常」などの状態を、上位処理層側ステイタス情報により管理しようとすれば、管理ファイル制御システムが、管理ファイル更新、若しくはバックアップファイルの更新を実行したことの応答を受けてから、ステイタス情報内容の変更を行うことになる。つまり、ステイタス情報として「管理ファイル異常」、「バックアップ異常」を示しているタイミングは、実際の処理状況タイミングに対して相応にずれることになってしまい、ステイタス情報としての信頼性が損なわれることになる。
【０１０９】
ところで、図７のコンテンツファイル操作の手順は、コンテンツファイルの追加記録について例示しているが、この図７の手順に従って、コンテンツファイル削除のファイル操作も行える。具体例として、手順１の「平常」とされる状態において、コンテンツファイルＡ，Ｂ，Ｃが適正管理されているものとして、この状態から、コンテンツファイルＣを削除するものとする。この場合、手順２においては、先ず、ファイルシステム上でコンテンツファイルＣが削除されるように処理を行う（コンテンツ削除中）。次いで、手順３の「定常」の状態から移行する手順４としては、管理ファイルについて、コンテンツファイルＣが削除されて、コンテンツファイルＡ，Ｂのみが適正管理されるように、その内容を変更することになる。そして、手順５の「定常」の状態から移行する手順６において、手順４により変更された管理ファイルと同じ内容となるようにして、バックアップファイルを更新するようにされる。このような処理手順であれば、手順７の「定常」の状況時には、ファイルシステム管理情報、管理ファイル、バックアップファイルが、コンテンツファイルＣは削除されてコンテンツファイルＡ，Ｂのみを管理した状態で整合が得られていることになる。
【０１１０】
しかしながら、上記した図７に準じた手順によりコンテンツファイルの削除を実行した場合には、次のような不都合が生じ得る。
図７に準じた手順によりコンテンツファイルの削除を実行している場合として、手順２のファイルシステム側でのコンテンツの削除処理を実行している途中で、電源の遮断などにより処理が中断されたとする。このときの不整合の状態としては、ファイルシステム管理情報としては、コンテンツファイルＣを管理する情報が完全な状態では残っていないが、一方の管理ファイルは、この段階では書き換えが行われていないことから、コンテンツファイルＣを管理する内容が正常に残っているという状態になる。
【０１１１】
これまでの説明のようにして、上記のような不整合が生じていれば、管理ファイル又はファイルシステム管理情報の書き換えなどにより、整合復帰のための処理が実行される。そして、上記の場合には、ファイルシステム管理情報のほうでは、コンテンツファイルＣを管理する情報は喪失していることと同じであるので、管理ファイル（及びバックアップファイル）についてコンテンツファイルＣを削除するようにして整合を図ることになる。
しかしながら、ファイルシステムレベルでのファイルの削除は、ファイルシステム管理情報上での書き換えによって実現しているので、コンテンツファイルＣの実データそのものは、ＨＤＤ１４に完全な状態で記録されている可能性が高い。このことからすると、最後のファイル操作がコンテンツファイルＣを削除する目的のものであったにせよ、その後の電源起動後において、コンテンツファイルＣが適正管理されるように復帰させることが好ましいという考え方を採ることもできる。コンテンツファイルＣが復帰管理されたとしてもなお、ユーザがコンテンツファイルＣを削除したいと考えるのであれば、再び、削除の操作を行えばよい。
【０１１２】
そこで、本実施の形態としては、コンテンツファイルの削除中に処理が中断された場合でも、次回の起動時において、この削除対象であったコンテンツファイルができるだけ復活して管理されるべきであるとの考えに基づいて、コンテンツファイルの削除を行うときには、図９により示す手順を実行することとしている。図９（ａ）には、コンテンツファイル削除に応じた処理手順例が示され、図９（ｂ）には、ファイル管理内容状態が示される、また、図９（ｃ）（ｄ）には、それぞれ上位処理層側ステイタス情報と、下位処理層側ステイタス情報の遷移が示される。
【０１１３】
先ず、図９（ａ）の手順１の「定常」の状況の段階では、ファイルシステムによりコンテンツファイルＡ，Ｂ，ＣがＨＤＤ１４に記憶されているものとして管理していると共に、管理ファイル、及びバックアップファイルによっても、これらコンテンツファイルＡ，Ｂ，Ｃを適正に管理している状態としている。従って、ファイル管理内容状態としては、図９（ｂ）に示すように、「整合」していることになる。また、上位処理層側ステイタス情報と下位処理層側ステイタス情報は、ともに「整合」を示す。
そして、手順２以降により、コンテンツファイルＣを削除するための処理を開始していくことになるのであるが、手順２としては、先ず、管理ファイルについて、コンテンツファイルＣを削除して、コンテンツファイルＡ，Ｂのみを管理する内容となるようにして変更する。この「管理ファイル更新中」のときには、管理ファイルは、書き換え処理中であることによって不完全な状態にあるものとみることができるので、ファイル管理内容状態は、図９（ｂ）に示すように「管理ファイル異常」となる。この手順２が終了すると、次の手順３において、管理ファイルがコンテンツファイルＡ，Ｂのみを管理する内容を有した状態での「定常」の処理状況となる。このときは、管理ファイルがファイル操作（コンテンツファイルＣの削除）に応じた正常な状態に成っているのに対して、そのバックアップファイルは、コンテンツファイルＣが削除されずに残っている状態にある。このために、ファイル管理内容状態は、図９（ｂ）に示すように、対応するバックアップファイルが異常であることを示す「バックアップ異常」となる。
【０１１４】
そこで、上記のようにして先ず管理ファイルを更新した後は、次の手順４によって、上記手順３における管理ファイルの内容が反映されるようにしてバックアップファイルを更新する、「バックアップ更新中」とされる処理状況に移行する。このときには、バックアップファイルが書き換え中であり不完全な状態にあることから、図９に示すように「バックアップ異常」を引き継ぐ。
【０１１５】
手順４を終了して、手順５の「定常」となった状態では、管理ファイルとバックアップファイルについては、整合がとれている。しかしながら、ファイルシステムによっては、コンテンツファイルＣが適正管理されている状態にある。このため、図９（ｂ）に示すファイル管理内容状態状態としては、ファイルシステム管理情報に対して整合がとれていないとして、「不整合」とされる。
【０１１６】
そこで、次の手順６により、ファイルシステム管理情報としてもコンテンツファイルＣが削除された内容となるようにして、ファイルシステム管理情報を更新する。この手順６としての処理状況は、「コンテンツ削除中」となる。このときも、ファイルシステム管理情報は書き換え中であって、コンテンツファイルＣが適切に削除された内容が得られている状態ではないことから、図９（ｂ）に示すファイル管理内容状態は、「不整合」を継続する。
そして、上記手順６としてのファイルシステム管理情報の書き換えが完了して手順７の「定常」の状態に遷移したとされると、管理ファイル（及びバックアップファイル）と同様に、ファイルシステム管理情報によっても、コンテンツファイルＣが削除され、ＨＤＤ１４に記憶されるコンテンツファイルＡ，Ｂのデータを正常管理する内容を有することとなって、「整合」の状態が得られることになる。
【０１１７】
また、上記した処理手順の流れに応じて、上位処理層側ステイタス情報と、下位処理層側ステイタス情報の内容は、図９（ｃ）（ｄ）のように変更される。
先ず、手順１の状態では、上位処理層側ステイタス情報と下位処理層側ステイタス情報は共に「整合」を示している。そして、手順２が開始されると、上位処理層側ステイタス情報としては、「不整合」に変更される。また、下位処理層側ステイタス情報については、管理ファイルが更新されることに応じて、「管理ファイル異常」に変更される。
【０１１８】
また、手順２の管理ファイル更新の処理が完了して手順３の「定常」の状態に遷移すると、先に説明したように、「バックアップ異常」の状態となる。そこで、下位処理層側ステイタス情報については、手順２の管理ファイル更新の処理が完了して、手順３の状態に切り替わるとされるタイミングに応じて、「管理ファイル異常」から「バックアップ異常」に変更される。
また、手順４によりバックアップファイルを更新しているときも、「バックアップ異常」の状態であり、従って、下位処理層側ステイタス情報は手順３からの「バックアップ異常」を継続することになる。
そして、上記手順４のバックアップファイルの更新が完了して手順５の「定常」の状態に遷移すると、下位処理層側ステイタス情報については、「不整合」に変更され、さらに次の手順６におけるコンテンツファイル削除のためのファイルシステム管理情報の書き換え時においても、同じ「不整合」を継続する。
なお、上位処理層側ステイタス情報については、手順２に遷移して「不整合」とされてから、手順６としての処理手順が完了するまで、同じ「不整合」を継続する。
【０１１９】
そして、手順６のファイルシステム管理情報の書き換えが完了して手順７の「定常」の状態に遷移すると、上位処理層側ステイタス情報と下位処理層側ステイタス情報は、ともに「整合」に変更される。
【０１２０】
そして、例えば電源起動時などにおける整合性の判定にあたっては、図９（ｃ）（ｄ）にまたがって破線で括って示しているステイタス情報要素の内容を、ステイタス情報が示す状態として扱うようにされる。つまり、手順１から手順４までの間の状態で処理が中途終了したとされる場合の次の電源起動時においては、ステイタス情報の内容として、下位処理層側ステイタス情報の内容を採用して管理情報群の整合性判定をおこなう。また、手順５から手順７までの間の状態で処理が中途終了したとされる場合の次の電源起動時においては、ステイタス情報の内容として、下位処理層側ステイタス情報の内容を採用して整合性判定をおこなうようにされる。
【０１２１】
図１０は、上記図９（ａ）に示した処理手順と、図９（ｃ）（ｄ）に示されるステイタス情報（上位処理層側ステイタス情報、及び下位処理層側ステイタス情報）の変更の処理を、アプリケーション、管理ファイル制御システム、及びファイルシステムの階層間の処理として示している。
【０１２２】
図９の例では、コンテンツファイルＣの削除がファイル操作となっており、手順２としては、管理ファイルからコンテンツファイルＣを削除することとしている。このために、先ずアプリケーションは、ステップＳ２０１としての手順により、管理ファイル制御システムに対して、管理ファイルからのコンテンツファイルの登録内容の削除を要求する。
【０１２３】
また、アプリケーションは、上記ステップＳ２０１の処理を実行すると共に、ステップＳ２０２として示すように、操作内容情報がコンテンツファイルの削除を意味するものとなるように書き換える処理を実行する。不揮発性メモリ１２ａ上の操作内容情報の更新が終了すると、その応答が下位処理層から返され、これをアプリケーションがステップＳ２０３により受け取る。
【０１２４】
また、アプリケーションは、上記ステップＳ２０２、Ｓ２０３（応答）により操作内容情報を書き換えると、続けて、ステップＳ２０４、Ｓ２０５（応答）により、上位処理層側ステイタス情報の内容を、これまで「整合」とされていた状態から、「不整合」に変更して、不揮発性メモリ１２ａに記憶し直す処理を実行する。
【０１２５】
また、ステップＳ２０１のコンテンツファイルの記録要求を受けた管理ファイル制御システムでは、ステップＳ２０６により、下位処理層側ステイタス情報について、これまで「整合」とされていた状態から、「管理ファイル異常」に変更するための処理を実行する。下位処理層側ステイタス情報の更新が完了すると、下位処理層から応答が返され、管理ファイル制御システムは、ステップＳ２０７により応答受信する。
【０１２６】
続いて、管理ファイル制御システムは、今回のコンテンツファイルの削除に応じた管理ファイルの更新（書き換え）のための処理を行う。つまり、管理ファイル制御システムは、ＨＤＤ１４からファイルシステム経由で読み込んだ管理ファイルについて、今回のコンテンツファイルの削除に応じた変更（例えばコンテンツファイルＣの登録削除）を行い、この変更内容が、ＨＤＤ１４に記憶される管理ファイルの内容に反映されるように、ＨＤＤ１４に対するアクセス、データ記録をファイルシステム経由で行う。このＨＤＤ１４に記憶される管理ファイルの更新が完了すると、管理ファイル制御システムの下位層からは応答が返される。管理ファイル制御システムは、ステップＳ２０９により、この応答を受け取ると、さらにステップＳ２１０により、アプリケーションに対して応答を返す。
【０１２７】
ステップＳ２１０による応答を受けたアプリケーションは、先のステップＳ２０１により要求した管理ファイルからのコンテンツファイルの登録削除が完了したことを認識する。続いて、アプリケーションは、ステップＳ２１１により、管理ファイル制御システムに対して、バックアップファイルの更新を要求する。
バックアップファイル更新要求を受けた管理ファイル制御システムは、バックアップファイル更新の処理に先だって、ステップＳ２１２により、下位処理層側ステイタス情報の内容を、これまでの「管理ファイル異常」から「バックアップ異常」に変更して記憶し直させる処理を実行する。このバックアップファイルの記憶が完了したとされると、ステップＳ２１３により下位処理層から返される応答を受け取る。
【０１２８】
そして、上記した下位処理層側ステイタス情報の更新が完了したとされると、管理ファイル制御システムは、ステップＳ２１４により、ファイルシステムを利用してバックアップファイル更新のための処理を、実行する。つまり、ファイルシステムを利用したＨＤＤ１４に対するバックアップファイルの読み出し、書き込み操作として、上記ステップＳ２０８にて更新した管理ファイルの内容が反映されるようにバックアップファイルの更新を行う。この処理の応答は、ステップＳ２１５の手順として返される。この応答を受信した管理ファイル制御システムは、さらにステップＳ２１６により、アプリケーションに対して応答を返す。
【０１２９】
上記ステップＳ２１６により管理ファイル制御システムから返された応答を受け取ることで、アプリケーションは、ステップＳ２１１により要求したバックアップファイルの更新が正常に終了したことを認識する。そして、次にアプリケーションは、ステップＳ２１７により、ファイルシステムレベルでのコンテンツファイルの削除を要求する。
【０１３０】
上記コンテンツファイルの削除要求を受けた管理ファイル制御システムでは、先ず、コンテンツファイルの削除処理の前に、ステップＳ２１８により、下位処理層側ステイタス情報の内容を、これまでの「バックアップ異常」から「不整合」を示すようにして変更する。この処理に対する応答は、ステップＳ２１９として返される。
【０１３１】
そして、上記した下位処理層側ステイタス情報の更新が完了したとされると、管理ファイル制御システムは、ステップＳ２２０により、コンテンツファイルの削除を、ファイルシステムに対する制御を伴って実行する。つまり、管理ファイル制御システムは、削除対象のコンテンツファイルが実際に削除されるように、ファイルシステム管理情報の内容を書き換えさせる。この処理に対する応答は、ステップＳ２２１として返される。
そして、管理ファイル制御システムは、上記ステップＳ２２１による応答を受信すると、さらにステップＳ２２１により、下位処理層側ステイタス情報について、「整合」を示すようにして変更する。この処理に対する応答は、ステップＳ２２３として管理ファイル制御システムに帰らされる。この応答を受信した管理ファイル制御システムは、さらに、ステップＳ２２４によりアプリケーションに対して応答を返す。アプリケーションは、この応答を受け取ることで、ステップＳ２１７により要求したコンテンツファイルの削除要求が正常に実行されたことを認識することになる。
【０１３２】
この後、アプリケーションは、ステップＳ２２５として示すように、上位処理層側ステイタス情報について、これまでの「不整合」から「整合」に変更するための処理を実行する。この処理に応じた下位処理層からの応答はステップＳ２２６により返される。
続いてアプリケーションは、ステップＳ２２７として示すようにして、これまでコンテンツファイルの記録を示していた操作内容情報について、クリアするための処理を実行する。この処理に対する応答は、ステップＳ２２８により行われる。
【０１３３】
図１１のフローチャートは、デジタルビデオカメラ１の起動時における、ファイルシステム管理情報、管理ファイル、バックアップファイル間の整合性復帰のための処理の手順例を示している。
この図に示す処理手順は、コンテンツファイルの記録操作に応じては図７及び図８により説明した処理手順を実行し、削除操作に応じては図９及び図１０により説明した処理手順を実行するものとされていることを前提とする。また、この図に示す処理は、例えばＣＰＵ１０などのプログラム実行機能を持つハードウェアデバイスが、図２に示すソフトウェア層（アプリケーション、管理ファイル制御システム、ファイルシステム、及びデバイスドライバ）としてのプログラムを実行することで実現される。このようなプログラムは、例えば、ＲＯＭ１１、不揮発性メモリ１２ａ、あるいはＨＤＤ１４などに記憶される。あるいは、プログラムを例えばリムーバブルの記憶媒体に記憶させておいて、後から、この記憶媒体を使用してインストールするようにしてデジタルスチルカメラ１に対して記憶させることもできる。また、ネットワーク上のサーバなどにおける記憶装置に記憶させておき、ネットワーク経由でダウンロードするようにして取得してデジタルスチルカメラ１にインストールするようなことも考えられる。
【０１３４】
図１１においては、先ずステップＳ３０１により、最後に電源供給が停止されたとき（ここでの電源供給の停止は、通常の電源オフと、障害的な電源の遮断による停止との両者の意を含む）のコンテンツファイル操作の内容を判別する。
このためには、図８、図１０に示した操作内容情報を利用する。つまり、不揮発性メモリ１２ａにアクセスして操作内容情報を参照し、その内容が、どのようなコンテンツファイルの操作内容を示しているのかを認識する。先の図８，図１０の説明から理解されるように、不揮発性メモリ１２ａに記憶保持される操作内容情報は、コンテンツファイルの操作として、最後の電源供給停止時においてどのようなことを実行中であったのかを示す。なお、ここでは、説明を簡単にするために、操作内容情報としては、「コンテンツファイルの記録」「コンテンツファイルの削除」及びコンテンツファイルの記録、削除を含めて特にファイル操作を行っていない「平常」の３つのうちのいずれかのファイル操作内容を示しているものとする。
【０１３５】
先ず、ステップ３０１において、コンテンツファイル操作の内容が「平常」であると判別された場合には、そのままこの図に示す処理を終了して抜けることになる。つまり、特に整合性復帰のための処理手順を実行することなく、通常の起動処理を実行する。
【０１３６】
これに対して、ステップＳ３０１において、コンテンツファイル操作の内容が「コンテンツファイルの記録」であると判別された場合には、ステップＳ３０２以降の処理に進む。コンテンツファイル操作の内容が「コンテンツファイルの記録」であると判別された場合には、最後の電源停止は、コンテンツファイルの記録処理中における障害的な電源遮断であると推定される。
【０１３７】
ステップＳ３０２においては、ステイタス情報を参照してその内容を判別する。
本実施の形態にあって、１つのステイタス情報としての単位は、図７（ｃ）（ｄ）及び図９（ｃ）（ｄ）に示しているように、上位処理層側ステイタス情報と下位処理層側ステイタス情報とを複合して形成される。ステップＳ３０２における処理としては、先ず、不揮発性メモリ１２ａに記憶保持される上位処理層側ステイタス情報を参照するようにされる。コンテンツファイルの記録操作に関しては、図７（ｃ）（ｄ）から分かるように、上位処理層側ステイタス情報が「整合」を示してさえいれば、この段階で、ファイルシステム管理情報、管理ファイル、及びバックアップファイルが相互に整合した状態としてＨＤＤ１４に記憶されていることになる。そこで、この場合には、そのままこの図に示す処理を抜ける。
【０１３８】
一方、上位処理層側ステイタス情報が「不整合」を示していることが判別されたのであれば、ステップＳ３０２の処理として、さらにＨＤＤ１４に記憶される下位処理層側ステイタス情報にアクセスして、その内容を参照するようにされる。下位処理層側ステイタス情報は、コンテンツファイル記録操作に対応しては、図７、図８に示されるようにして「整合」「管理ファイル異常」「バックアップ異常」の３種の内容を有する。
そして、上位処理層側ステイタス情報が示す内容と、下位処理層側ステイタス情報が示す内容とを比較してみる。すると、図７（ｃ）（ｄ）の関係から分かるように、上位処理層側ステイタス情報は「不整合」を示し、下位処理層側ステイタス情報が「整合」を示している状態では、手順２，３の処理途中で終了していることになるので、上位処理層側ステイタス情報の内容である「不整合」の状態であることになる。そこで、ステップＳ３０２の処理として、上位処理層側ステイタス情報と下位処理層側ステイタス情報の内容が上記の状態であることを認識した場合には、ステイタス情報の内容としては「不整合」であると判別して、ステップＳ３０３の処理に進むようにされる。
【０１３９】
ステップＳ３０３においては、不整合の要因となっているコンテンツファイルを検索する。この検索の意味は、不整合の要因となっているコンテンツファイルの存在の有無の確認と、このようなコンテンツファイルが存在する場合には、そのコンテンツファイルの特定を行うことである。そして、次のステップＳ３０４により、上記ステップＳ３０３の検索結果により、不整合の要因となっているコンテンツファイルの存在の有無についての判別を行うようにされる。
上記ステップＳ３０３、Ｓ３０４としての処理にあっては、ファイルシステム管理情報と管理ファイルの内容を比較して、その差分を得るようにされる。図７の手順２，３の処理実行中において中途終了した場合においては、さらに２つの場合を考えることができる。
１つは、ファイルシステム管理情報の更新が終了している場合である。この場合には、ファイルシステム管理情報によっては、最後に記録したコンテンツファイルを正常管理しているが、管理ファイルでは管理していない状態となっている。このため、ファイルシステム管理情報と管理ファイルの内容を比較することで、最後に記録したコンテンツファイルが管理ファイルにより管理されていないことが認識される。そこで、ステップＳ３０４としては、不整合の要因となっているコンテンツファイルが存在し、かつ、このコンテンツファイルが、最後に記録したコンテンツファイルであることが認識され、ステップＳ３０４として肯定の判別結果が得られる。
もう１つは、ファイルシステム管理情報の更新が終了していない場合である。この場合、ファイルシステム管理情報と管理ファイルのいずれによっても最後に記録したコンテンツファイルは管理されていない状態にある。このとき、最後に記録していたコンテンツファイルは存在していないものの、ファイルシステム管理情報と管理ファイルの内容に関しての整合はとれている。そこで、この場合には、ステップＳ３０４として否定の判別結果を得ることになる。
【０１４０】
先ずステップＳ３０４により肯定の判別結果が得られた場合には、その不整合の状態を解消して整合性を復帰させるための処理として、ステップＳ３０５、Ｓ３０６の処理を実行する。
ステップＳ３０５では、不整合の要因であるとして特定されたコンテンツファイル、つまり、最後に記録されたものとしてファイルシステムにより管理されているコンテンツファイルを、管理ファイルに登録する。そして、次のステップＳ３０６において、ステップＳ３０５の処理によりその内容が更新された管理ファイルの内容が反映されるようにして、バックアップファイルについても更新を行う。これらの処理が完了すると、最後に記録していたコンテンツファイルが正常に管理される状態で整合性が復帰される状態が得られることになる。
また、ステップＳ３０４にて否定の判別結果が得られた場合には、このまま、図に示す処理を抜ける。この場合には、ファイルシステム及び管理ファイル（及びバックアップファイル）による管理内容としては、最後に記録していたコンテンツファイルは存在しないことになってはしまうが、両者の整合はとれている状態で起動されることになる。
【０１４１】
また、ステップＳ３０２における前述の処理により、下位処理層側ステイタス情報が「管理ファイル異常」であるとの判別結果が得られた場合にはステップＳ３０７以降の処理に進む。
下位処理層側ステイタス情報が「管理ファイル異常」を示している場合には、図７の手順４により管理ファイルそのものが書き換え中での処理中断であったために、管理ファイルの内容が破壊されているなどの不正な状態にあるということになる。しかし、バックアップファイルは、最後に記録していたコンテンツファイルが反映される前の内容で完全な状態で記憶されている。そこで、そこで、この場合には、ステップＳ３０７により、バックアップファイルの内容をコピーするようにして、管理ファイルの再作成を行う。
上記のようにして管理ファイルが再作成された段階では、管理ファイル（及びバックアップファイル）によっては、最後に記録していたコンテンツファイルを管理していないが、ファイルシステム管理情報では、最後に記録していたコンテンツファイルを管理している状態となっており、不整合が生じている。そこで、ステップＳ３０８により、このとき不整合の要因となっている、最後に記録していたコンテンツファイルを管理ファイルに登録する。そして、続くステップＳ３０９により、上記ステップＳ３０８により更新された管理ファイルの内容が反映されるようにして、バックアップファイルについても更新を行う。これにより、最後に記録していたコンテンツファイルが正常管理した状態で整合性復帰が図られることになる。
【０１４２】
また、ステップＳ３０２において下位処理層側ステイタス情報が「バックアップ異常」であるとの認識が得られた場合にはステップＳ３１０の処理を実行する。
このようにして参照した下位処理層側ステイタス情報が「バックアップ異常」を示している場合には、図７の手順６によりバックアップファイルの書き換え実行中に処理が中断されていることになるので、バックアップファイルは、例えば破壊されているなどの不正な状態にある。一方、オリジナルの管理ファイルは、先の手順４による更新が完了して正常な状態でＨＤＤ１４に記憶管理されている。そこで、ステップＳ３１０では、管理ファイルの内容をコピーするようにしてバックアップファイルの再作成を行う。従って、この場合にも最後に記録していたコンテンツファイルが正常管理した状態で整合性復帰が図られることになる。
【０１４３】
また、ステップＳ３０１において、コンテンツファイル操作内容が「コンテンツファイルの削除」であると判別された場合には、ステップＳ３１１以降の処理に進む。コンテンツファイル操作の内容が「コンテンツファイルの削除」であると判別された場合には、最後の電源停止は、コンテンツファイルの削除処理中における障害的な電源遮断であると推定される。
【０１４４】
ステップＳ３１１においては、先のステップＳ３０２に準じて、ステイタス情報を参照してその内容を判別するようにされる。
そして、この場合においても、先ず、上位処理層側ステイタス情報を参照して、その内容が「整合」を示しているか否かについて判別する。「整合」を示しているのであれば、図９からも分かるように、ファイルシステムによるファイル管理内容と、管理ファイル、及びバックアップファイルによるファイル管理内容が相互に整合した状態としてＨＤＤ１４に記憶されていることが導き出されるので、この場合には、そのままこの図に示す処理を抜ける。
【０１４５】
一方、上位処理層側ステイタス情報が「不整合」を示していることが判別されたのであれば、この場合にも、ステップＳ３１１の処理としては、さらにＨＤＤ１４に記憶される下位処理層側ステイタス情報にアクセスして、その内容を参照する。コンテンツファイルの削除操作に応じた下位処理層側ステイタス情報は、図９、図１０に示されるようにして、「整合」「不整合」「管理ファイル異常」「バックアップ異常」の３種の内容を有する。この場合、コンテンツファイルの記録操作に応じた場合のように、無効な「整合」を示すことはない。
そこで、ステップＳ３１１としては、下位処理層側ステイタス情報について、「管理ファイル異常」、「バックアップ異常」、あるいは「不整合」のいずれの内容を示しているのかについて判別することになる。
【０１４６】
ステップＳ３１１により、先ず「管理ファイル異常」であることを判別した場合には、ステップＳ３１２の処理を実行する。
下位処理層側ステイタス情報が「管理ファイル異常」を示している場合には、図９の手順２により管理ファイルの書き換え実行中に処理が中断されていることになるので、管理ファイルは、不正な状態にある。一方、そのバックアップファイルは、最後の削除処理の対象となっていたコンテンツファイルを残した正常な状態で例えばＨＤＤ１４に記憶管理されている。また、ファイルシステム管理情報についても、最後の削除処理の対象となっていたコンテンツファイルを残した正常な状態となっている。そこで、ステップＳ３１２では、バックアップファイルの内容をコピーするようにして管理ファイルの再作成を行う。これにより、最後の削除対象となっていたコンテンツファイルが適正に管理される状態で、整合性の復帰が図られることになる。
なお、この場合には、管理ファイルが不正な状態となって元の確かな内容を認識することは困難であり、また、ファイルシステム管理情報と、バックアップファイルとでは、最後の削除対象となっていたコンテンツファイルが残っている状態で整合していることから、差分の情報を得て最後の削除対象となっていたコンテンツファイルを特定することも難しい。ただし、例えば操作内容情報に、操作対象となっていたファイルを、例えばファイルシステムレベルで特定できるような情報を格納しておけば、最終的に、最後の削除対象となっていたコンテンツファイルを削除して管理した状態で整合復帰を図ることは可能になる。
【０１４７】
また、ステップＳ３１１により、「バックアップ異常」であることを判別した場合には、ステップＳ３１３、Ｓ３１４の処理を実行する。
「バックアップ異常」が判別される場合には、図９の手順３、４のいずれか手順の中途で処理が中断されていることになる。従って、バックアップファイルは、正常にＨＤＤ１４に記憶管理されているものの、未だ、最後に削除していたコンテンツファイルが登録管理されたままの状態であるか、不正な状態で記憶されているかのどちらかとなる。いずれにせよ、最後に削除対象としていたコンテンツファイルが削除済みとされた内容となっている管理ファイルとは整合していない状態である。
そこで、ステップＳ３１３としては、先ず、管理ファイルの内容の一部（バックアップファイルとの差分）、あるいは全てをコピーするようにしてバックアップファイルの更新、若しくは再作成を行う。そして、次のステップＳ３１４により、ファイルシステムレベルでの不整合コンテンツの削除を実行するようにされる。
これにより、最後の削除対象となっていたコンテンツファイルを削除して管理した状態で整合復帰が図られることになる。
【０１４８】
ただし、図９のコンテンツファイルの削除手順としたことの根拠として説明したように、最後削除対象としていたコンテンツファイルをできるだけ残すという仕様とする場合には、最後に削除対象としていたコンテンツファイルを残した状態での整合復帰を図ることも可能である。このためには、先ず、上記ステップＳ３１３と同様の処理によって、先ず管理ファイルを、バックアップファイルに整合した正常な内容に戻す。そのうえで、ファイルシステム管理情報と、この管理ファイルとの比較により、差分として、最後の削除対象になっていたコンテンツファイルの存在を求め、このコンテンツファイルを管理ファイルに登録し、これに応じたバックアップファイルの更新を行うようにされる。
【０１４９】
また、ステップＳ３１１において「不整合」であることを判別した場合には、ステップＳ３１５以降の処理を実行する。不整合であるとの判別結果が得られるのは、図９の手順５，６の中途で処理が中断された場合となる。
【０１５０】
ステップＳ３１５においては、不整合の要因となっているコンテンツファイルを検索する。このためには、例えばステップＳ３０３の場合と同様にして、ファイルシステム管理情報と管理ファイルの内容を比較して、その差分を得るようにされる。手順５，６において処理が中断した場合には、実際には、不整合とされる状態になる場合と、整合している状態となる場合とがある。つまり、例えば手順５において処理が中断した場合には、ファイルシステム管理情報の書き換えを実行する前の段階であることから、管理ファイルによっては最後の削除対象になっていたコンテンツファイルは既に削除された状態となっているが、ファイルシステム管理情報によっては適正に管理された状態のままとなっている、という不整合の状態となる。この状態のとき、ステップＳ３１５の検索結果に応じたステップＳ３１６の判定結果としては、肯定の判別結果が得られることになる。そこで、この場合にはステップＳ３１７に進んで、ファイルシステムレベルで、最後の削除対象になっていたコンテンツファイルが現実に削除されるものとして管理されるように、ファイルシステム管理情報を更新する。これにより、最後の削除対象になっていたコンテンツファイルは削除済みとされた状態での整合性の復帰が図られる。
なお、ファイルシステム管理情報が、最後の削除対象になっていたコンテンツファイルを削除していない状態で正常に管理している内容を有している場合には、管理ファイルとバックアップファイルについて、この最後の削除対象になっていたコンテンツファイルを登録するようにして更新を行うことで、最後の削除対象のコンテンツファイルが削除されずに適正に残っている状態で整合性の復帰を図ることも可能である。
また、手順６にて処理が中断したときには、ファイルシステム管理情報上で、削除対象になっていたコンテンツファイルを管理する情報が消失している状態となる場合もあるものとされる。この場合には、最後の削除対象になっていたコンテンツファイルが適正に削除された状態で整合が得られていることになる。この場合には、ステップＳ３１６において、否定の判別結果が得られることとなり、特に整合性復帰の処理を実行することなくこの図の処理を抜ける。
【０１５１】
続いては、これまでに説明した本実施の形態に関しての変形例について説明する。
図１２は、コンテンツファイル操作に応じた処理手順として、本実施の形態の変形例とされるものを示している。この場合におけるコンテンツファイル操作は、図７と同様にして、ファイルの追加記録となっている。また、図１２（ａ）（ｂ）（ｃ）（ｄ）は、図７（ａ）（ｂ）（ｃ）（ｄ）と同一の内容となっている。
そして、この変形例としては、図１２（ｅ）として示すように、サブステイタス情報が設けられており、コンテンツファイル操作時には、このサブステイタス情報についても変更操作が行われるものとしている。
サブステイタス情報は、これまでの実施の形態において説明したステイタス情報（上位処理層側ステイタス情報及び下位処理層側ステイタス情報）に対して補助的な機能を有するもので、本実施の形態のデジタルビデオカメラ１では、不揮発性メモリ１２ａに輝北保持されるべきものとなる。また、このサブステイタス情報についての書き換え操作は、管理ファイル制御システムが行うこととしている。
【０１５２】
このサブステイタス情報は、手順１の「定常」の状態までは「整合」の内容を示すようにされているが、手順２に移行するタイミングで、「不整合」を示すようにして変更される。そして、手順６が終了するまでは、この「不整合」の内容を維持し、手順７に移行するタイミングで「整合」を示す内容に戻すようにされる。つまり、このサブステイタス情報は、手順２〜６までの、ファイル操作に応じたファイルシステムレベルでの処理、及び管理ファイル、バックアップファイルの更新などのための一連の処理が実行されているとする期間に対応して、「不整合」を示すようにされた情報となる。
【０１５３】
図１３は、上記図１２の処理手順を、アプリケーション、管理ファイル制御システム、及びファイルシステムの階層間の処理として示している。なお、この図において、図８と同様となる手順については同一のステップ符号を付して、ここでの説明は省略し、図８との相違点についてのみ述べる。
【０１５４】
ステップＳ１０１によっては、アプリケーションが管理ファイル制御システムに対してコンテンツファイルの記録を要求する。図８の手順の場合、管理ファイル制御システムは、この要求に応じて、ステップＳ１０６によりコンテンツファイル作成のための要求をファイルシステムに対して行うようにされているのであるが、ここでは、ステップＳ１０６の手順に先立って、ステップＳ１０５−１、Ｓ１０５−２（応答）により、サブステイタス情報について、それまで「整合」とされていた内容から、「不整合」を示す内容に変更する処理を実行する。
【０１５５】
また、管理ファイル制御システムは、図８の手順では、ステップＳ１２０、Ｓ１２１（応答）により、下位処理層側ステイタス情報を「バックアップ異常」から「整合」に書き換える処理を終了させたのに続き、ステップＳ１２１−１、Ｓ１２１−２（応答）により、サブステイタス情報について、これまでの「不整合」から「整合」に戻すようにして変更する処理を実行し、この処理を終了したタイミングで、ステップＳ１２２により、バックアップファイル更新要求に対する応答をアプリケーションに返すようにされる。
【０１５６】
図１４のフローチャートは、上記のようにしてサブステイタス情報が設けられる変形例についての、起動時における整合性復帰のための処理手順を示している。なお、この図に示されるステップＳ４０１〜Ｓ４１７については、図１１に示したステップＳ１０１〜Ｓ１１７と同様となることから、ここでの説明は省略する。
【０１５７】
図１４の処理手順では、最初にステップＳ４００としての判定処理が設けられている。ステップＳ４００は、不揮発性メモリ１２ａに記憶保持されているサブステイタス情報にアクセスしてその内容を参照し、「整合」と「不整合」の何れを示しているのかについての判別を行う。
サブステイタス情報が「整合」の内容を有している場合とは、図１２，図１３から分かるように、手順１、若しくは手順７とされる状態の下で電源が停止されたということになる。従って、管理ファイル及びバックアップファイルと、ファイルシステムレベルとの間でのコンテンツファイル管理については整合がとれているということになる。そこで、ステップＳ４００にて「整合」であるとの判別結果が得られた場合には、特に整合性復帰のための処理を実行することなく、この図１４の処理を抜けるようにされる。これに対して、ステップＳ４００にて「不整合」であるとの判別結果が得られた場合には、手順２〜６までの処理の流れのなかで電源が停止されていることから、整合性が失われているとみてよい状態（「不整合」「管理ファイル異常」「バックアップ異常」）となっている可能性があることになる。そこで、ステップＳ４０１以降の処理を実行することになる。
【０１５８】
このようにして、サブステイタス情報は、ステップＳ４０１以降の整合性復帰処理を実行する必要性の有無を最初に判断するために利用される。サブステイタス情報は、先に説明したように不揮発性メモリ１２ａに対して記憶保持させることとしている情報である。これに対して、メインとなるステイタス情報は、上位処理層側ステイタス情報と下位処理層側ステイタス情報とを複合して形成される構造であって、上位処理層側ステイタス情報は不揮発性メモリ１２ａに記憶されるが、下位処理層側ステイタス情報はＨＤＤ１４に記憶させることとしている。
不揮発性メモリ１２ａは、例えばＣＰＵ１０が内部データバス経由で直接的にアクセスできるフラッシュメモリなどの半導体記憶素子であることから、ＨＤＤ１４と比較すれば、そのアクセス速度は相当に高い。つまり、不揮発性メモリ１２ａに記憶されるサブステイタス情報に先ずアクセスしてその内容を参照することで、整合性復帰のための処理を実行すべきか否かの判定を、起動処理の過程において高速に行えることになる。これにより、起動処理としてはより効率的なものとなって、例えば起動時間の短縮も期待される。
【０１５９】
ところで、上位処理層側ステイタス情報も、不揮発性メモリ１２ａに記憶保持され、また、例えば図１２の手順１，７に対応しては「整合」で、手順２〜７により一連の処理が実行されている期間においては「不整合」を示す。この点では、上位処理層側ステイタス情報は、サブステイタス情報と同じとなる。従って、例えば図１４のステップＳ４００の判定処理にあたって、上位処理層側ステイタス情報を参照するように構成することも可能である。しかしながら、図１４のステップＳ４００の判定処理には、下記の理由によりサブステイタス情報を利用したほうが有利である。
【０１６０】
先に図１３により説明したように、上位処理層側ステイタス情報は、アプリケーションの操作によりその内容変更が行われ、サブステイタス情報は管理ファイル制御システムにより内容変更が行われる。
アプリケーションによる上位処理層側ステイタス情報についての「整合」から「不整合」への変更タイミング、あるいは「不整合」から「整合」への変更タイミングは、アプリケーションレベルでのコンテンツファイルの記録要求の発行（Ｓ１０１）タイミングと、この要求に応じて下位処理層から返される応答受信タイミングとに基づいたものとなる。
これに対して、管理ファイル制御システムによるサブステイタス情報についての「整合」から「不整合」への変更タイミング、あるいは「不整合」から「整合」への変更タイミングは、それぞれ、コンテンツファイル作成要求（Ｓ１０６）、あるいは、バックアップファイル更新処理（Ｓ１１８）のタイミングに前後したものとなる。つまり、アプリケーションよりも物理層に近いレベルでの処理タイミングに応じて、サブステイタス情報の内容は変更される。このことから、上位処理層側ステイタス情報とサブステイタス情報との内容変更のタイミングを比較した場合には、サブステイタス情報のほうが、例えば図１２（ａ）などに示している手順の流れに応じた実際の処理タイミングにより近く、信頼性が高いということがいえる。従って、ステップＳ４００による整合性復帰処理の可否判定に、サブステイタス情報を利用することのほうが、その判定結果としてもより高い信頼性が期待できることになる。
【０１６１】
続いては、本実施の形態におけるバックアップファイルの書き換え処理について説明しておくこととする。
本実施の形態としては、図１５に示すようにして、バックアップファイルのオリジナルである管理ファイルについては、所定の固定長によるブロック単位の集合として扱うようにされる。同様に図１５に示すように、バックアップファイルについても、ブロックの集合により形成する。
なお、この図では、管理ファイルとバックアップファイルを形成するブロックについて、０〜Ｎまでの論理的な番号を与えている。ブロックは、本実施の形態の場合であれば、ファイルシステムの管理単位であるクラスタの所定数にまとめたものを１単位とするようにされる。
【０１６２】
ここで、図示するようにして、管理ファイルにおけるブロック１の一部、ブロック２の一部、及びブロック４の一部（２カ所となっている）についてデータ更新が行われたものとする。そして、このようにして更新された管理ファイルの内容をバックアップファイルに反映させるためには、データ部分の更新があったブロック（更新ブロック）を、バックアップファイルのブロック構造における同じブロック番号に上書きコピーするようにされる。
例えば、管理ファイルの更新内容をバックアップファイルに反映させるための書き換え処理としては、単純に、管理ファイルを形成する全てのデータを、バップアップファイルの構造にコピーするようにしてもよい。このような処理は、アルゴリズムは単純でよいが、更新されていないデータ部分についても必ずコピーすることになるという点で効率的でない。特に、管理ファイルのサイズが大きくなってくると、コピーに要する時間が増加して処理速度を低下させることにつながる。
これに対して、図１５にて説明したようにして、更新されたデータ部分を含むブロックのみをコピーさせる処理とすれば、更新データ部分を含まないブロックのデータはコピーされることがないので、必要最小限のコピー処理で済む。これにより、コピーに要する時間の増加も抑えられ、処理速度の向上が期待できる。
また、データの書き換えの最小単位をブロック単位としていることで、処理アルゴリズムとしてはできるだけ簡易となるようにすることができる。また、１つのブロック内に複数箇所のデータ更新部分が含まれることもしばしばあることから、１つのブロックをコピーすることにより、一度に複数のデータ更新部分をバックアップファイルに反映させることができるという効率性の良さも得られる。
【０１６３】
図１６は、上記図５により説明したバックアップファイルのより具体的な更新手順例について、記憶装置アクセスの手順を含めて示した図である。
この図においては、先ず図１６（ａ）に、ＨＤＤ１４に記憶されている管理ファイルが示されている。なお、この図においても、管理ファイル（及びバックアップファイル）についてはブロック単位で形成される構造により示している。
例えばコンテンツファイル操作などに応じて管理ファイルを更新するときには、更新のためのデータ書き換え処理をメモリ上で実行するようにされる。なお、ここでいうメモリは、図１との対応では、ＲＡＭ１２となる。そこで、管理ファイルの更新にあたっては、図１６（ａ）と図１６（ｂ）により示すようにして、管理ファイルのデータの読み込みを実行する。つまり、ＨＤＤ１４に記憶されている管理ファイルのデータから、今回の更新に必要とされるデータ部分をブロック単位により読み出し、メモリに書き込むようにしてコピーする。そして、図１６（ｃ）に示すようにして、このメモリ上において、管理ファイルの更新を実行する。なお、図１６（ｃ）には、図１５（ａ）と同じ更新内容が示されている。このようにして、メモリ上での管理ファイルのデータの更新を完了させると、図１５（ｃ）から図１５（ｄ）への流れとして示すように、管理ファイルの書き出しが行われる。つまり、メモリ上で内容が更新されたブロックのデータを、再度、ＨＤＤ１４の管理ファイルの構造に対してコピーするようにして書き込みを行う。この段階が終了することで、管理ファイルの更新が完了したことになる。
【０１６４】
そして、管理ファイルが更新されたのに応じては、その内容が反映されるようにしてバックアップファイルを更新することになる。このために、図１６（ｄ）から図１６（ｅ）への処理の流れとして示すように、バックアップのためのデータ読み込みを行う。つまり、図１６（ｄ）に示すようにして更新された状態でＨＤＤ１４に記憶される管理ファイルから、更新されたブロックのみを読み出して、図１６（ｅ）に示すように、メモリへのコピー（書き込み）を行う。
そして、図１６（ｅ）から図１６（ｆ）への遷移として示すように、バックアップファイルの書き出しを行う。つまり、メモリに保持させた更新されたブロックのデータを、ＨＤＤ１４に記憶されているバックアップファイルの対象ブロックにコピーするようにして書き込みを行う。
【０１６５】
また、図１７により、本実施の形態のバックアップファイルの更新手順の他の例を示す。
先ず、図１７（ａ）（ｂ）（ｃ）（ｄ）としての処理の流れは、図１６（ａ）（ｂ）（ｃ）（ｄ）と同様となる。つまり、先ずは、ＨＤＤ１４に記憶される管理ファイルから更新に必要とされるデータをブロック単位で読み出し、メモリ上にコピーすることが行われる（管理ファイルの読み込み）。そして、このメモリ上に保持されたデータについて、ファイル操作結果に応じて更新（データの書き換え）を行い、この更新されたブロック単位のデータをＨＤＤ１４に書き込んで記憶させるようにする。
【０１６６】
そして、上記した管理ファイルの更新に応じて、その内容が反映されるようにバックアップファイルを更新するのにあたっては、図１７（ｅ）、（ｆ）の手順を行う。
つまり、図１７（ｃ）に示すようにしてメモリ上で管理ファイルの更新が行われた後において、この図１７（ｃ）から図１７（ｅ）への遷移として示すようにして、更新が行われたブロック単位のデータを、同じメモリ上における別の領域にコピーするようにしてさらに保持させるようにする。そして、図１７（ｅ）から図１７（ｆ）への遷移として示すように、このバックアップ用にメモリ内コピーされたブロック単位のデータを、ＨＤＤ１４に記憶されているバックアップファイルの対象ブロックにコピーするようにして書き込みを行うことで、バックアップファイルの書き出しの処理とするものである。
【０１６７】
このような図１７の手順とすることで、図１６の手順とする場合よりも、バックアップファイルの更新はより効率的で、高速なものとなる。つまり、図１６では、図１６（ｄ）から図１６（ｅ）への遷移として示すバックアップのためのデータ読み込みのために、ＨＤＤ１４にアクセスして更新されたブロックの読み出しを行っている。これに対して、図１７の手順では、図１７（ｃ）（ｅ）の手順と示すように、メモリ内において更新されたブロックデータのコピーを行うことで、バックアップ用の差分のデータを用意しているので、このバックアップ用の差分データをＨＤＤ１４にアクセスして読み込む手順は必要が無くなる。
このようにして図１７に示す手順では、図１６と比較してＨＤＤ１４にアクセスしてデータ読み込みを実行する手順が１つ省かれることになる。現状において、ＨＤＤなどに対するアクセス時間は、例えばＲＡＭ、フラッシュメモリなどの半導体メモリ素子などへのアクセス時間に比較すると相当に長くなる。一方の図１７では、図１７（ｃ）（ｄ）により、更新されたブロックのデータを、バックアップ用にメモリにコピーしているが、この処理は、同じメモリ（ＲＡＭ）上での処理であることから、ＨＤＤ１４に対するアクセスと比較すれば短時間である。
このようにして図１７の手順では、ＨＤＤ１４へのアクセス回数を減らすことで、バックアップファイルの更新処理について、その所要時間が短縮され、また、例えばＨＤＤの物理的故障の可能性の低下も期待できるなど、効率化が図られているものである。
【０１６８】
なお、本願発明としては、これまでに説明した実施の形態としての構成に限定されるべきものではない。
例えば、本願発明に基づくステイタス情報としての情報単位は、実施の形態では、少なくとも上位処理層側ステイタス情報と下位処理層側ステイタス情報の複合体として形成されるものとして、それぞれを、ハードウェア的に異なる記憶媒体に記憶させることとしているが、例えばアクセス速度の相違や、システム階層などの都合による記憶媒体アクセスの効率のことなどを考慮しなければ、これらのステイタス情報をどの記憶媒体に記憶させるのかということについては、特に制限はない。また、先にも説明したように、１つの情報単位により実体的なステイタス情報としての構造がとられてもよいものである。
また、管理ファイル（及びバックアップファイル）についてのファイルシステムによる管理態様、また、管理ファイルのフォーマット、仕様などとしては、図２、図３により説明した以外にも考えられる。また、上記実施の形態では、管理ファイルによっては、画像、音声等を情報内容とするコンテンツファイルを管理するものとしたが、管理ファイルが管理対象とするファイル種別については特に限定しない。例えば文書ファイルなどとされてもよい。また、実際の機器の用途などによっては、管理ファイルの管理対象となる特定種類のファイルが、ファイルシステム（基本ファイル管理手段）により管理される全種類のファイルと一致する可能性も考えられる。また、これに伴い、本願発明が適用される装置としては、デジタルビデオカメラに限定されるものではなく、他の各種機器に適用可能である。
【図面の簡単な説明】
【０１６９】
【図１】本発明の実施の形態としての情報処理装置であるデジタルビデオカメラの構成例を示すブロック図である。
【図２】本実施の形態における、ファイルシステムによるコンテンツファイル、管理ファイル、及びバックアップファイルの管理態様例をディレクトリ構造により示す図である。
【図３】管理ファイルの構造例を模式的に示す図である。
【図４】実施の形態のデジタルビデオカメラにおける、メディア（ＨＤＤ）アクセスに関するシステム構成を階層モデルにより示す図である。
【図５】コンテンツファイル操作に応じたファイルシステム管理情報と管理ファイルの書き換え手順例と、書き換えに応じたファイルシステムによる管理状態と管理ファイルによる管理状態との整合性についての遷移例を示す図である。
【図６】コンテンツファイル操作に応じたファイルシステム管理と、管理ファイル及びバックアップファイルの書き換えについての手順例と、書き換えに応じたファイルシステムと管理ファイルとによるファイル管理状態の整合性についての遷移例を示す図である。
【図７】コンテンツファイルの記録操作に応じたファイルシステム管理と、管理ファイル及びバックアップファイルの書き換えについての手順例と、書き換えに応じたステイタス情報についての遷移例を示す図である。
【図８】コンテンツファイルの記録操作に応じたファイルシステム管理、管理ファイル及びバックアップファイルの書き換えについての手順例を、システム階層間の処理として示す図である。
【図９】コンテンツファイルの削除操作に応じたファイルシステム管理と、管理ファイル及びバックアップファイルの書き換えについての手順例と、書き換えに応じたステイタス情報についての遷移例を示す図である。
【図１０】コンテンツファイルの削除操作に応じたファイルシステム管理、管理ファイル及びバックアップファイルの書き換えについての手順例を、システム階層間の処理として示す図である。
【図１１】デジタルビデオカメラの起動時における、ファイルシステム管理情報、管理ファイル、バックアップファイル間の整合性復帰のための処理の手順例を示すフローチャートである。
【図１２】コンテンツファイルの記録操作に応じたファイルシステム管理と、管理ファイル及びバックアップファイルの書き換えについての手順例と、書き換えに応じたステイタス情報及びサブステイタス情報についての遷移例を示す図である。
【図１３】図１２に例示したコンテンツファイルの記録操作に応じたファイルシステム管理、管理ファイル及びバックアップファイルの書き換えについての手順例を、システム階層間の処理として示す図である。
【図１４】サブステイタス情報が設けられる場合の、ファイルシステム管理情報、管理ファイル、バックアップファイル間の整合性復帰のための処理の手順例を示すフローチャートである。
【図１５】実施の形態におけるバックアップファイルの書き換え処理概念を示す図である。
【図１６】実施の形態としてのバックアップファイル書き換えの手順例を示す図である。
【図１７】実施の形態としてのバックアップファイル書き換えについての他の手順例を示す図である。
【符号の説明】
【０１７０】
１  デジタルビデオカメラ、２  光学系部、３  光電変換部、４  ビデオ信号処理部、５  画像入出力部、６  カメラ機能部、７  表示部、８  音声処理部、９  音声入出力部、１０  ＣＰＵ、１１  ＲＯＭ、１２  ＲＡＭ、１２ａ  不揮発性メモリ、１３  メディアコントローラ、１４  ＨＤＤ、１５  操作入力部、１６  通信部
【図１】
2007179436.tif 000003
【図２】
2007179436.tif 000004
【図３】
2007179436.tif 000005
【図４】
2007179436.tif 000006
【図５】
2007179436.tif 000007
【図６】
2007179436.tif 000008
【図７】
2007179436.tif 000009
【図８】
2007179436.tif 000010
【図９】
2007179436.tif 000011
【図１０】
2007179436.tif 000012
【図１１】
2007179436.tif 000013
【図１２】
2007179436.tif 000014
【図１３】
2007179436.tif 000015
【図１４】
2007179436.tif 000016
【図１５】
2007179436.tif 000017
【図１６】
2007179436.tif 000018
【図１７】
2007179436.tif 000019