PC用途やAV用途などの異なったプラットフォームにおいて、共通利用できる汎用のディスク媒体が存在する事は、ユーザにとって大きなメリットがある。例えば、AVディスクレコーダなどで記録されたディスクが、PCに接続したディスクドライブでアクセスできたり、その逆のアクセスが容易に行える事は、AVディスクレコーダで記録したAVデータをPCでアクセスしたり編集したりする事ができ、編集結果などをまたAVディスクレコーダなどで容易に再生できたりする事を意味する。また1つのディスクに、AVデータを記録したり、PCのアプリケーションソフトを入れたりと、AV用途とPC用途とで共有して利用する事も考えられる。
しかし、AV用途で記録されるデータとPC用途で記録されるデータの性質は異なるものである。例えば、ディスクに記録されたAVデータを再生する場合、AVデータをディスクから読み出し、決まった時間にディスプレイに表示をしなければならない。決まった時間に表示ができない場合は、再生画面が途切れ再生画面がおかしくなる事を意味し、許容されるものではない。
ディスク媒体はランダムアクセス性に優れている為、一連のデータであってもディスク上において連続的に配置されている必要はなく、ディスク上の空き領域を有効に利用し、分断して記録されていても構わない。例えばPC用途の場合、文章データファイルがディスク上で分断して記録されていたとしても、そのファイルを読み出す際に各分断点においてシークやトラックジャンプが発生し、その期間ディスクからのデータの読み出しが中断し、連続的にデータが読み出せる場合と比較してデータの読み出し時間が多少かかる程度で、機能面での問題は全く無い。
しかし、AV用途においては前述した通り、再生しようとするデータがディスク上で分断して記録されていると、各分断点でデータの読み出しの中断が発生し、問題が発生する可能性がある。一般的に、ディスクから読み出されたAVデータは一度バッファメモリにある程度貯蓄され、シークやトラックジャンプなどのデータ読み出しの中断が発生したとしても、バッファメモリに貯蓄されたデータで補う事により、即再生画面が途切れる事を防いでいる。しかし、バッファメモリによって再生画面の途切れを吸収するのも、繁雑にシークやトラックジャンプが発生すると対応しきれなくなってしまう。よって、AVデータをディスクに記録する場合は、データの読み出し中断が発生するシークやトラックジャンプが発生しない、データの連続的な記録が望まれる事になる。
ここで、1つのディスクをAV用途とPC用途とで共用で利用する事を考えると、それぞれの用途のデータを、それぞれ異なる領域に記録したいという要求が発生する。これは、連続的にデータを記録したいAVデータが記録されているディスク領域に、AVデータと比較した場合、データ量が遥かに小さいPC用途のデータが無造作に記録されていくと、AVデータの連続記録を妨げる要因となり、場合によってはAVデータの記録再生に支障を与える可能性があるからである。
また、AV用途であっても、記録するデータはAVデータだけではなく、それらを再生するための管理情報ファイルや、静止画像など色々な種類のデータが存在する。同一用途であっても性質の異なるデータを記録するので、記録するデータの種類に応じて領域を分けて管理したいという要求が発生する。例えば、論理ファイルシステムの管理情報を記録する領域、AVデータを再生するための管理情報などを記録する領域、AVデータ自体を記録する領域、静止画を記録する領域と言ったものが考えられる。
1つのディスクを複数の領域に分けて使用するために、従来から、以下のような方法がある。まず、第1に、領域を明確に分けるという意味では、論理ファイルシステムのパーティション機能が存在する。例えばAV用途とPC用途用のパーティションを定義する事によって、それぞれの専用領域を設ける事が可能となる。
図16に示す例では、ディスクをパーティション1、パーティション2、パーティション3と3つに分割している様子を示している。
第2の方法として、パーティション機能を用いない場合は、AV用途とPC用途の領域を論理ファイルシステムでは管理せずに、実装レベルのアプリケーション層の管理情報として領域を管理する事が考えられる。例えば、それぞれの領域の位置情報を記録した管理情報ファイルをディスクに記録し、そのファイルを読み込む事で領域の位置情報を把握する事が可能となる。図17に示す例では、AREA.DATというファイルに領域1、領域2、領域3の位置情報が記録されている。よって、AREA.DATというファイルを解釈できるアプリケーションのみが領域の範囲を把握する事が可能となる。
上記した第1の方法とは異なり、ここでの領域1〜3は論理ファイルシステム上では1つのパーティションで構成され、その中で、領域に区分されていることになる。
第3に、1つのファイルやデータを記録する領域を予約すると言った用途で、実際にデータを記録する事なくその領域があたかも使われているかのようにダミーファイルを作成する事も考えられる。図18にある領域内に記録されるファイルがそれぞれの使用する予定である領域をDUMMY1.DAT、DUMMY2.DAT、DUMMY3.DATという3つのダミーファイルによって確保しているものである。
このようにダミーデータとして、予め記録されるデータと同じサイズのデータを書き込んでおき、所定のデータ種別のファイルを書き込む際に、そのダミーデータを削除して、その位置にファイルを書き込むことによって、データ種別ごとにファイルを連続して書き込むことができる。
以下、本発明の領域管理方法に関する実施形態について、図面とともに詳細について説明する。本実施例は、ディスク装置として、AV記録再生を目的としたディスクを用いた携帯型のビデオカメラやビデオデッキ、PCに接続された外部記憶装置などを想定するものである。ディスク媒体は、リムーバブルディスクが好ましいが、ハードディスクなどの据え付け型であっても構わない。また、説明の都合上ディスクに用いる論理ファイルシステムとしてOSTA(Optical Storage Technology Association)の規格であるUDF(Universal Disk Format)を想定するが、その他の汎用論理ファイルシステムであっても構わない。
一般的なディスク装置の構成を図1に示す。データ入力出力部1はカメラなどから入力される映像信号を取り込んだり、再生するデータをモニタ等に出力したりする。データ処理部2は、例えばMPEG符号をエンコードしたり、デコードしたりする信号処理等を行う処理部であり、処理されたデータはメモリ3に格納される。データを記録する場合は、ディスク制御部5において、ディスク6を制御しディスク上の目的の箇所にデータが記録され、再生時には、ディスク6を制御しディスク上の目的の箇所からデータが読み出されてメモリ3に格納される。各処理部はシステム制御部4によって制御される。
このようなディスク装置において、ディスクの領域を分割して管理したい場合は、論理ファイルシステムにおけるパーティション機能を用いるのが一般的である。しかし、前述したように、一度パーティションを区切ってしまうとパーティションの大きさを変更したり、あるパーティションを他のパーティションと連結させて大きさを拡大すると言った事は容易に行なえない。本実施例ではパーティション機能によっての領域の分割は行なわないので、図2に示すようにディスクのユーザ領域全域を管理するように1つのパーティションを作成する。作成したパーティション内に、ある特定の情報を記録するための領域を定義するものとする。パーティション機能を利用しない事と、汎用ファイルシステムであるUDFを用いるため、1つのパーティション内に複数の領域を管理するような論理ファイルシステムレベルの管理情報は存在しない。ここで重要になってくるのが、1つのディスクを複数のプラットフォームで使用する可能性がある事である。例えば、AV用途で記録されたディスクをPCのドライブでアクセスしたりする事が考えられる。従って、AVアプリケーションと言った特定のアプリケーションのみで理解できるような情報での領域確保だけでは不十分である。つまり、ある特定の情報を記録するための領域を定義するという事は、AV用途においてデータの種類に応じた記録領域を管理するだけではなく、PCアプリケーションなどからのアクセスがあったとしても、確保された領域への書き込みを抑制しなければならない事を意味する。これを実現するためには、確保された領域が論理ファイルシステムから見た場合に既にデータが記録されており、使われているものとして見えなければならない。
そこで、本発明では任意の数のある特定の情報を記録するための連続領域を確保するために、領域内においてデータが記録されておらず未使用な部分を管理する形でダミーファイルを作成するものとする。つまり、領域内の未使用部分にダミーファイルが管理するディスク上のデータがあたかも書き込まれているかのようにするわけである。
UDFでは、ボリュームレベルの管理情報とファイルシステムレベルの管理情報に分かれ、ここでは関連するファイルシステムレベルの管理情報について簡単に説明する。ボリュームレベルの管理情報によって定義されるパーティション内において、空き領域を管理するSpace Bitmap Descriptorと、パーティション内のディレクトリ構造の基本情報やROOTディレクトリを管理するFile Entryへのポインタ情報を含むFile Set Descriptor、File Set Descriptorが終了した事を示すTerminating Descriptor、ROOTディレクトリのFile Entryがファイルシステムレベルの管理情報として基本的に記録される。
Space Bitmap Descriptorとは、パーティション内で管理する全ての論理ブロックに対して1bitをそれぞれ割り当て、対応する論理ブロックが使われているか使われていないかを、bit情報が0か1かで判断するものである。ここでの論理ブロックとは、ファイルシステムにおける最小アクセス単位であり、UDFパーティション内において各論理ブロックに対して昇順に論理ブロック番号が付加される。
ディレクトリが定義されると、ディレクトリを管理するFile Entryがディレクトリ内に含まれるファイルやディレクトリに対応するFile Identifier Descriptorの集合の記録位置を管理する事になる。File Identifier Descriptorには、ファイルやディレクトリの名前や属性情報と対応するFile Entryが記録されているアドレス情報が格納される。File Entryには、日付などの属性情報とこのファイル(File Entry)が管理しているディスク上のデータの位置情報、あるいはディレクトリの場合には、ディレクトリ情報(File Identifier Descriptorの集合)が記録されている位置情報を管理している。このように、File EntryとFile Identifier Descriptorを辿って行く事によってディレクトリ階層を把握する事が可能となる。またこれらの情報は、UDFファイルシステムの管理情報であり、通常はデバイスドライバが利用するだけで、通常はユーザから見えない情報となる。図4にUDFにおけるディレクトリ階層を表現するためのFile EntryとFile Identifier Descriptorの関係を示す。
ダミーファイルによる領域確保の1つの例として、図2に、任意の数のある特定の情報を記録するための連続領域として領域1、2、3を定義し、連続領域2にファイルであるFILE1.DAT、FILE2.DAT、FILE3.DATが記録されている様子を示す。実際のディスクでは、FILE1.DATに対応するUDFの管理情報であるFE(File Entry)とデータ自体であるFile1が記録されている。この例ではファイルの管理情報であるFE(File Entry)へのポインタ情報を含むFile Identifier Descriptorは例えば領域1の中に記録されているものとして図示しない。
ディスク上の位置情報は、開始論理ブロック番号と論理ブロック数を示すAllocation Descriptorの集合で管理される。つまり、1つのファイル(File Entry)で管理するデータがディスク上で連続的に記録されている場合、Allocation Descriptorは1つ、2つに分断して記録されている場合はAllocation Descriptor 2つによってファイルの位置情報を管理する事になる。
FILE1.DATと同様にFILE2.DAT、FILE3.DATに対応するFE(File Entry)と対応する実データが確保されている連続領域に記録されている。ここで、確保した連続領域内でデータが記録されていない未使用な部分に、ダミーファイルDUMMY1.DATを作成する。つまり未使用部分にデータがあたかも書き込まれているようにダミーファイルDUMMY1.DATを作成し、FE(File Entry)のAllocation Descriptorで管理するわけである。また、UDFファイルシステムの管理情報で空き領域を管理するSpace Bitmap Descriptorに関してもダミーファイルDUMMY1.DATの管理している部分は使われているものとして扱う。
また、使用過程において、例えば図3におけるFILE2.DATが削除された場合、通常はFILE2.DATに対応するFE(File Entry)とデータが記録されていた箇所はSpace Bitmap Descriptorによって未使用な部分であるとし、解放される。しかし本発明では、図に示すように削除された部分は解放せずに、前述したダミーファイルDUMMY1.DATが管理する部分として扱う。この際、DUMMY1.DATのFE(File Entry)内のAllocation Descriptorを更新して、DUMMY1.DATが2つの分断から構成されるファイルとする事になる。
ダミーファイルを作成するのにあたって、確保した連続領域を利用するアプリケーションが理解できるダミーファイルの名前を規定しておく。図の例では、確保した連続領域内でのダミーファイルはDUMMY1.DATとして規定されている。つまり、あるアプリケーションからみると、このDUMMY1.DATは空き領域であると理解するのである。
このように常に、確保した連続領域内の未使用部分を管理するようにダミーファイルを作成する事によって、この領域を使用するアプリケーション以外にとって、この領域内は常に全て使用されているものとして扱われ、データが書き込まれる事はない。また、他のアプリケーションからのデータの書き込みを抑制するだけではなく、ダミーファイルを規定したアプリケーションにとっては、ダミーファイルの情報を取得する事によって、容易に確保した領域内の未使用部分の大きさや位置を把握する事ができるという効果もある。例えば、未使用部分の大きさは、ダミーファイルのファイルサイズを参照すればわかり、位置情報はダミーファイルのFE(File Entry)内のAllocation Descriptorを参照する事によって容易に把握する事が可能である。つまり、ダミーファイルがそのまま、確保した領域内の未使用部分になるわけである。
また、ダミーファイルを理解できるアプリケーションが複数のメーカーによって実装されている場合、各メーカー間で必ずしも確保する連続領域の大きさが同一であるとは限らない。この場合にも、ダミーファイルの情報を参照するだけで、確保している領域内の未使用部分を把握できるので領域の大きさを規定しなくてもメーカー間の互換も取る事が可能となる。また、必要に応じて、領域内に記録されるべきファイルとダミーファイルの情報から、領域の大きさを把握する事が可能となる。
ここで、新規に特定の情報を記録するための所定サイズの連続領域を確保する場合の処理について詳細を図5に示すフローチャートを用いて説明する。ステップS1において、連続領域を確保する要求が発生すると、ステップS2において、UDF論理ファイルシステムの管理情報であるSpace Bitmap情報を参照する事によってディスク上の空き領域を把握する。ステップS3において、確保しようとする連続領域がディスク上の任意の箇所に確保できない場合は、ステップS5においてエラー処理を行ない処理を終了する。また、ステップS3において、確保しようとする連続領域がディスク上の任意の箇所に確保できる場合は、ステップS4において、確保する連続領域を管理する形でダミーファイルを作成し処理を終了する。具体的にはダミーファイルが作成されるディレクトリのディレクトリ情報にダミーファイルのFile Entryへのポインタ情報である、File Identifier Descriptorを追加し、ダミーファイルのデータの位置情報や属性情報を管理するFile Entryを記録する。この際、File Entry内のAllocation Descriptorに、確保した領域の位置情報である開始論理ブロック番号と論理ブロック数を記録する。
ここで、実際にファイル作成要求が発生した場合の処理について説明する。ファイル作成要求があった場合、そのファイルをどの領域に書き込むことが可能であるかを判断する。例えば、図2に示すように領域1、領域2、領域3・・・と領域を分割している場合に、あるAVアプリケーションがファイルの書き込み要求をした場合、領域1に書き込むように対応づけられているとする。この判断は、例えばAVアプリケーションはDUMMY1.DATの位置に書き込むように、AVアプリケーション自体に定義しておくことによって行われる。例えば、AVアプリケーション以外のPCアプリケーションなどは、DUMMY1.DAT上に書き込むことはなく、他の領域などに書き込むことになる。
また、各アプリケーションにファイル種別に応じて書き込む領域(ダミーデータとの対応)を定義しておくことにより、例えばvideoデータはDUMMY1.DAT上に書き込むこととし、audioデータはDUMMY2.DAT上に書き込むように制御することも可能である。
つまり、所定のアプリケーションを所定の領域に書き込む、或いは所定の種別のファイルを所定の領域に書き込むことが可能となる。
次に、書き込む領域が決定した後、ダミーファイルによって確保された領域内にファイルを作成する場合の処理について詳細を図6に示すフローチャートを用いて説明する。
ステップS10においてファイル作成要求が発生すると、ステップS11においてダミーファイルの情報を取得する。具体的には、ダミーファイルとして規定されたファイル名より、対応するFile Entryを参照しその情報よりダミーファイルのファイルサイズや位置情報を把握する。ステップS12において、ダミーファイルのファイルサイズ、つまり確保した領域中の空きサイズが作成しようとしているファイルのサイズより大きいかどうかを判定する。ダミーファイルのサイズが作成しようとしているファイルのサイズより小さい場合は、確保された領域にファイルを作成するスペースがないので、ステップS15においてエラー処理を行ない、処理を終了する。ステップS12において、ダミーファイルのサイズが作成しようとしているファイルのサイズより大きい場合は、確保された領域にファイルが作成できるので、ステップS13において、ダミーファイルが管理する空き部分にファイルを作成する。
具体的には、作成するファイルが含まれるディレクトリのディレクトリ情報に、ファイルを管理するFile Entryへのポインタ情報であるFile Identifier Descriptorを追加し、ファイルのデータの位置情報や属性情報を管理するFile Entryを記録する。ステップS14において、ダミーファイルのFile Entryを更新し処理を終了する。この際、File Entry内のAllocation Descriptor情報から、新規作成したファイルに割り当てた部分を差し引く形で更新する。
ダミーファイルによって確保された領域内に存在するファイルのサイズの変更を伴う更新が発生する場合の処理について詳細を図7に示すフローチャート用いて説明する。
ステップS20において、ファイルサイズ変更を伴うファイル更新要求が発生すると、ステップS21においてファイルのサイズが大きくなるのか小さくなるのかを判定する。ファイルのサイズが縮小される場合は、ステップS28において、縮小するファイルのFile EntryのAllocation Descriptorを縮小したデータを管理するように更新する。ステップS29においてダミーファイルのFile EntryのAllocation Descriptorに縮小したファイルの箇所を追加する形で更新し処理を終了する。サイズが拡張される場合は、ステップS22においてダミーファイルの情報を取得し、確保されている領域内の空き部分を把握する。ステップS23において、ダミーファイルのサイズつまり確保されている領域内の未使用スペースの大きさと新たにファイルとして拡張されるデータサイズの比較を行なう。ダミーファイルのサイズの方が大きい場合、つまり確保された領域内に十分な空き部分がある場合、ステップS24において、ダミーファイルの管理する未使用スペースに拡張するデータを記録する。ステップS25において、拡張したファイルのFile EntryのAllocation Descriptorを更新する。ステップS26においてダミーファイルのFile EntryのAllocation Descriptorを更新し処理を終了する。ステップS23において、ダミーファイルのサイズより拡張するデータのサイズが大きい場合、つまり拡張するだけの空きスペースが残っていない場合は、ステップS27においてエラー処理を行ない処理を終了する。
ダミーファイルによって確保された領域内に存在するファイルを削除する場合の処理について詳細を図8に示すフローチャート用いて説明する。ステップS30において、ファイル削除要求が発生すると、ステップS31おいてファイルの削除処理を行なう。具体的には、削除するファイルが含まれているディレクトリのディレクトリ情報から対応するFile Identifier Descriptorを削除する。ステップS32においてダミーファイルのFile Entryを更新し処理を終了する。具体的には、削除したファイルが記録されていた部分を管理するように、ダミーファイルのAllocation Descriptorを更新する。
ダミーファイルによって確保された領域が足りなくなったりした事により、領域の大きさを拡張したい場合の処理について詳細を図9に示すフローチャート用いて説明する。
ステップS40において、領域拡張要求が発生すると、ステップS41においてSpace Bitmapよりディスクの空きスペースを把握する。ステップS42において、拡張する領域の隣接箇所に拡張したいだけの連続領域が存在するかどうかを判定する。存在する場合はステップS44においてダミーファイルのFile Entryをその拡張領域も含める形で更新する。隣接箇所に確保したいだけの連続領域が無い場合は、図5に示した連続領域確保処理を行ない処理を終了する。この場合は、拡張する領域が既存の領域と連続的では無くなる。もし連続領域でなければならない場合は、ステップS43において連続領域確保処理を行なわず、エラー処理を行なって処理を終了しても構わない。図10にある領域を拡張した場合の例を示す。この例では、領域1にFILE1.DAT、FILE2.DAT、FILE3.DATを記録し空き領域が無くなり、隣接した箇所を利用して領域を拡張しようとしたが、既に隣接領域2が確保されていた関係で、ディスク上の他の連続領域を確保した例である。領域1のダミーファイルはDUMMY1.DATというファイル名で、領域1の拡張領域はDUMMY2.DATというダミーファイルによって空きスペースが管理されている。ここで、ファイル名が規定されているので、DUMMY2.DATが存在する場合はディスク上の非隣接箇所に拡張した連続領域がある事を把握する事が可能となる。また、既存の連続領域を拡張したい場合に、隣接箇所が使われているために連続的に拡張できない場合、隣接するデータをディスク上の他の箇所へ移動し、領域を空けて連続的な拡張を行っても良い。
このように、論理ファイルシステムの機能であるパーティション機能を使っていないので、パーティションの大きさなどを変更する場合と比較して、ダミーファイルの更新だけで領域の大きさを変更することが可能となるので、遥かに単純な処理で行える。
なお、定義する連続領域においてダミーファイルで空きスペースを管理する際、図11に示すように必ず連続領域の最後の論理ブロックをダミーファイルで管理しなければならないという制限を付けても良い。つまり、連続領域において最後の1論理ブロックは、ダミーファイルが管理するスペースとして常に確保する。よって、連続領域として確保したい大きさに、1論理ブロックとダミーファイルを管理するFile Entryを記録する1論理ブロックの計2論理ブロックを余分に確保しておく事になる。よって、ダミーファイルDUMMY1.DATを管理するFile Entry内のAllocation Descriptorの中で、一番大きい論理ブロック番号が確保している連続領域の最後尾という事になる。このように構成することによって、連続領域の最後までデータファイルが記録された場合に、連続領域の境界がわからなくなるということを防止し、連続領域の境界の把握を容易に行うことが可能となる。
また確保する連続領域内に記録されるファイルが決まっている場合は、それらのFile Entry内のAllocation Descriptorとダミーファイルの情報から連続領域の範囲を把握する事が可能であるが、その連続領域に記録されるファイル名などが決まっていない場合は、ファイル名からどの連続領域に記録されているデータであるかを判断することができないため、ダミーファイルによって空きスペースは把握する事が可能であるが、確保された連続領域の範囲を把握する事はできない。よってこのような場合、図12に示すように必ず連続領域の先頭と最後尾の論理ブロックをダミーファイルで管理しなければならないという制限を付けても良い。つまり、連続領域において先頭と最後尾の1論理ブロックは、ダミーファイルが管理するスペースとして常に確保する。よって、連続領域として確保したい大きさに余分に2論理ブロックとダミーファイルのFile Entryを記録する1論理ブロックの計3論理ブロックを確保しておく事になる。
あるいは、図13に示すように、確保する連続領域の先頭はダミーファイルを管理するFile Entryでなければならず、最後尾の1論理ブロックはダミーファイルが管理するスペースとして確保するようにしても構わない。このように構成することによって、ダミーファイルDUMMY1.DATを管理するFile EntryのAllocation Descriptorの中で一番小さい論理ブロック番号あるいはダミーファイルのFile Entry自体が記録されている論理ブロック番号が確保している連続領域の先頭位置となり、一番大きい論理ブロック番号が逆に連続領域の最後尾の位置となり、管理している連続領域の範囲を容易に把握する事が可能となる。
ここで、本発明の実際の適用例について図14を用いて説明する。この図では、AVデータを記録するAV用途における領域管理の一例である。まず、領域としてファイルシステム管理情報領域、アプリケーション管理情報領域、データ領域に分割して管理するものとする。ファイルシステム管理情報領域には、UDFファイルシステムにおける基本管理情報である、Space Bitmap Descriptor(SBD)、File Set Descriptor(FSD)、Terminating Descriptor(TD)とAVアプリケーションによって規定されるディレクトリのFile Entry(FE)と、ディレクトリ内に定義されるファイルやディレクトリを管理するFile Entryへのポインタ情報である、File Identifier Descriptor(FID)を記録するものとする。この図の例では、ROOTディレクトリ、AVデータの管理情報を記録するAVMANディレクトリ、AVデータを記録するAVDATディレクトリを管理するFile Entryと、それぞれのディレクトリ内で定義されるファイルのFile Identifier Descriptor(FID)の集合が記録されている。そして、ダミーファイルLOGI.DMYがファイルシステム管理情報領域における未使用部分を管理している。
アプリケーション管理情報領域は、AVデータを再生するための管理情報などのAVアプリケーションの管理情報が記録される領域である。この領域には、AVデータの管理情報である、AVINFO1.DATおよびAVINFO2.DATが記録されており、ディスクにはそれぞれに対応するFile Entryとデータの実体が記録されている。ファイルシステム管理情報領域と同様に、ダミーファイルAPPL.DMYがアプリケーション管理情報領域における未使用部分を管理している。このような構成のディスクをユーザがアクセスすると、図15に示すようなディレクトリ階層として見える事になる。
データ領域には、AVデータであるAV1.DATおよびAV2.DATが記録されており、ディスクにはそれぞれに対応するFile Entryとその実体が記録されている。この図の例では、データ領域に関しては、ダミーファイルによるデータ領域の領域確保は行なっていないが、必要に応じてダミーファイルを定義して領域を確保しても構わない。
このように、ファイルシステム管理情報領域の未使用箇所は、ダミーファイルLOGI.DMYによって管理され、アプリケーション管理情報領域の未使用箇所はダミーファイルAPPL.DMYによって管理されており、これらの領域を使用するAVアプリケーションにとっては、それぞれ対応する領域の空き領域を管理しているものとして扱われる。例えばこのような状況のディスクをPCに接続されたディスクドライブでアクセスした場合には、ファイルシステム管理情報領域とアプリケーション管理情報領域には、空きスペースが無い状態でファイルが記録されているように扱われるため、領域が確保されているのと等価になる。よって、これらの領域にデータが書き込まれる事が無くなる。
また、この時PCアプリケーションからAVアプリケーションで使用しているディレクトリやAVデータの管理情報などが削除されては困るので、これらのファイルやディレクトリの属性として書き込み禁止を設定しても良い。つまり、PCアプリケーションはデータ領域の空き領域にしか書き込むことができないこととなる。また、当然ダミーファイル自体が削除されても困るので、同様に書き込み禁止属性を設定しても良い。またダミーファイルはPCアプリケーションから見えないようにするために、隠しファイル属性を設定しても良い。仮にダミーファイルが誤って消されてしまった場合には、現在定義されているファイルやディレクトリの論理ファイルシステムの管理情報と空き領域を管理しているSpace Bitmap Descriptorの情報からダミーファイルを再構築する事も可能である。