(57)【特許請求の範囲】
【請求項１】
複数アプリケーションにより使用可能な記憶媒体に関して、該記録媒体に記録する実データを格納するためのデータ領域と該実データに関する管理情報を格納するための領域とを確保し、該実データをファイルとして管理するファイル管理方法であって、
第１のアプリケーションにより、前記記録媒体内に第１の実データに関する第１の管理情報を格納するための第１の領域を確保する工程と、
前記第１のアプリケーションにより、前記第１の領域中の未使用領域をダミーファイルとして設定する工程と、を有し、
前記ダミーファイルは、
前記第１のアプリケーションによる前記データ領域への前記第１の実データの書込時には使用済み領域を意味し、該第１のアプリケーションによる該第１の実データに関する前記第１の管理情報の書込時には空き領域を意味し、且つ、
前記第１のアプリケーション以外の第２のアプリケーションによる前記記憶媒体の使用時には使用済み領域を意味するファイル名によって規定されていることを特徴とするファイル管理方法。
【請求項２】
前記管理情報を格納する領域が複数確保され、前記ダミーファイルのファイル名が該管理情報を格納する前記領域毎に異なることを特徴とする請求項１に記載のファイル管理方法。
【請求項３】
前記第１の管理情報は、前記第１の実データを再生するためのアプリケーション管理情報であることを特徴とする請求項１に記載のファイル管理方法。
【請求項４】
前記第１の管理情報は、前記第１の実データを再生するためのアプリケーション管理情報のファイルのディレクトリ階層を管理するファイルシステム管理情報であることを特徴とする請求項１に記載のファイル管理方法。
【請求項５】
前記第１の管理情報は、前記第１の実データのファイルのディレクトリ階層を管理するファイルシステム管理情報であることを特徴とする請求項１に記載のファイル管理方法。
【請求項６】
前記第１の管理情報は、前記第１の実データのファイルと該第１の実データを再生するためのアプリケーション管理情報のファイルのディレクトリ階層を管理するファイルシステム管理情報であることを特徴とする請求項１に記載のファイル管理方法。
【請求項７】
前記ダミーファイルのファイル管理情報は、前記第１の領域内に存在することを特徴とする請求項１に記載のファイル管理方法。
【請求項８】
前記第１の管理情報の書込要求が発生した場合に、前記ダミーファイルのサイズと該書込要求のある前記第１の管理情報のサイズとを比較する工程と、
前記第１の管理情報を書き込むために必要な前記ダミーファイルのサイズが足りない場合には、前記第１の領域の隣接未使用領域を該ダミーファイルに含めることで該ダミーファイルを拡張する工程と、
を有することを特徴とする請求項１に記載のファイル管理方法。
【請求項９】
前記第１の管理情報の書込要求が発生した場合に、前記ダミーファイルのサイズと該書込要求のある前記第１の管理情報のサイズとを比較する工程と、
前記第１の管理情報を書き込むために必要な前記ダミーファイルのサイズが足りない場合には、前記第１の領域の非隣接未使用領域を非隣接ダミーファイルとして設定する工程と、を有し、
前記非隣接ダミーファイルのファイル名には、前記ダミーファイルと関連付けられたファイル名を規定することを特徴とする請求項１に記載のファイル管理方法。
【請求項１０】
前記隣接未使用領域は、前記第１の実データ又は第２の管理情報を移動させることで作成されることを特徴とする請求項８に記載のファイル管理方法。
【請求項１１】
前記第１の領域の後端は、常に前記ダミーファイルで構成されることを特徴とする請求項１に記載のファイル管理方法。
【請求項１２】
前記第１の領域の先端及び後端は、常に前記ダミーファイルで構成されることを特徴とする請求項１に記載のファイル管理方法。
【請求項１３】
前記ダミーファイルのファイル管理情報には、前記第２のアプリケーションに対して隠しファイル又は書き込み禁止ファイルを意味する属性を有することを特徴とする請求項１に記載のファイル管理方法。
【請求項１４】
前記第２のアプリケーションは、ＰＣアプリケーションであることを特徴とする請求項１３記載のファイル管理方法。
【請求項１５】
請求項１に記載のファイル管理方法を実行するファイル管理装置。
【請求項１６】
前記ダミーファイルを複数識別可能であることを特徴とする請求項１５に記載のファイル管理装置。
【発明の詳細な説明】
【０００１】
本発明は、一つの記録媒体に複数のアプリケーションからのファイルの書き込みを行う場合において、記録媒体を複数の領域に分割して利用するファイル管理方法及び装置に関する。
【０００２】
【従来の技術】
ＰＣ用途やＡＶ用途などの異なったプラットフォームにおいて、共通利用できる汎用のディスク媒体が存在する事は、ユーザにとって大きなメリットがある。例えば、ＡＶディスクレコーダなどで記録されたディスクが、ＰＣに接続したディスクドライブでアクセスできたり、その逆のアクセスが容易に行える事は、ＡＶディスクレコーダで記録したＡＶデータをＰＣでアクセスしたり編集したりする事ができ、編集結果などをまたＡＶディスクレコーダなどで容易に再生できたりする事を意味する。また１つのディスクに、ＡＶデータを記録したり、ＰＣのアプリケーションソフトを入れたりと、ＡＶ用途とＰＣ用途とで共有して利用する事も考えられる。
【０００３】
しかし、ＡＶ用途で記録されるデータとＰＣ用途で記録されるデータの性質は異なるものである。例えば、ディスクに記録されたＡＶデータを再生する場合、ＡＶデータをディスクから読み出し、決まった時間にディスプレイに表示をしなければならない。決まった時間に表示ができない場合は、再生画面が途切れ再生画面がおかしくなる事を意味し、許容されるものではない。
【０００４】
ディスク媒体はランダムアクセス性に優れている為、一連のデータであってもディスク上において連続的に配置されている必要はなく、ディスク上の空き領域を有効に利用し、分断して記録されていても構わない。例えばＰＣ用途の場合、文章データファイルがディスク上で分断して記録されていたとしても、そのファイルを読み出す際に各分断点においてシークやトラックジャンプが発生し、その期間ディスクからのデータの読み出しが中断し、連続的にデータが読み出せる場合と比較してデータの読み出し時間が多少かかる程度で、機能面での問題は全く無い。
【０００５】
しかし、ＡＶ用途においては前述した通り、再生しようとするデータがディスク上で分断して記録されていると、各分断点でデータの読み出しの中断が発生し、問題が発生する可能性がある。一般的に、ディスクから読み出されたＡＶデータは一度バッファメモリにある程度貯蓄され、シークやトラックジャンプなどのデータ読み出しの中断が発生したとしても、バッファメモリに貯蓄されたデータで補う事により、即再生画面が途切れる事を防いでいる。しかし、バッファメモリによって再生画面の途切れを吸収するのも、繁雑にシークやトラックジャンプが発生すると対応しきれなくなってしまう。よって、ＡＶデータをディスクに記録する場合は、データの読み出し中断が発生するシークやトラックジャンプが発生しない、データの連続的な記録が望まれる事になる。
【０００６】
ここで、１つのディスクをＡＶ用途とＰＣ用途とで共用で利用する事を考えると、それぞれの用途のデータを、それぞれ異なる領域に記録したいという要求が発生する。これは、連続的にデータを記録したいＡＶデータが記録されているディスク領域に、ＡＶデータと比較した場合、データ量が遥かに小さいＰＣ用途のデータが無造作に記録されていくと、ＡＶデータの連続記録を妨げる要因となり、場合によってはＡＶデータの記録再生に支障を与える可能性があるからである。
【０００７】
また、ＡＶ用途であっても、記録するデータはＡＶデータだけではなく、それらを再生するための管理情報ファイルや、静止画像など色々な種類のデータが存在する。同一用途であっても性質の異なるデータを記録するので、記録するデータの種類に応じて領域を分けて管理したいという要求が発生する。例えば、論理ファイルシステムの管理情報を記録する領域、ＡＶデータを再生するための管理情報などを記録する領域、ＡＶデータ自体を記録する領域、静止画を記録する領域と言ったものが考えられる。
【０００８】
１つのディスクを複数の領域に分けて使用するために、従来から、以下のような方法がある。まず、第１に、領域を明確に分けるという意味では、論理ファイルシステムのパーティション機能が存在する。例えばＡＶ用途とＰＣ用途用のパーティションを定義する事によって、それぞれの専用領域を設ける事が可能となる。
【０００９】
図１６に示す例では、ディスクをパーティション１、パーティション２、パーティション３と３つに分割している様子を示している。
【００１０】
第２の方法として、パーティション機能を用いない場合は、ＡＶ用途とＰＣ用途の領域を論理ファイルシステムでは管理せずに、実装レベルのアプリケーション層の管理情報として領域を管理する事が考えられる。例えば、それぞれの領域の位置情報を記録した管理情報ファイルをディスクに記録し、そのファイルを読み込む事で領域の位置情報を把握する事が可能となる。図１７に示す例では、ＡＲＥＡ．ＤＡＴというファイルに領域１、領域２、領域３の位置情報が記録されている。よって、ＡＲＥＡ．ＤＡＴというファイルを解釈できるアプリケーションのみが領域の範囲を把握する事が可能となる。
【００１１】
上記した第１の方法とは異なり、ここでの領域１〜３は論理ファイルシステム上では１つのパーティションで構成され、その中で、領域に区分されていることになる。
【００１２】
第３に、１つのファイルやデータを記録する領域を予約すると言った用途で、実際にデータを記録する事なくその領域があたかも使われているかのようにダミーファイルを作成する事も考えられる。図１８にある領域内に記録されるファイルがそれぞれの使用する予定である領域をＤＵＭＭＹ１．ＤＡＴ、ＤＵＭＭＹ２．ＤＡＴ、ＤＵＭＭＹ３．ＤＡＴという３つのダミーファイルによって確保しているものである。
【００１３】
このようにダミーデータとして、予め記録されるデータと同じサイズのデータを書き込んでおき、所定のデータ種別のファイルを書き込む際に、そのダミーデータを削除して、その位置にファイルを書き込むことによって、データ種別ごとにファイルを連続して書き込むことができる。
【００１４】
【発明が解決しようとする課題】
上記した第１の方法では、ＡＶ用途とＰＣ用途の領域をそれぞれパーティション機能によって分けそれぞれの専用領域を設ける事ができる。しかしながら、一般的にパーティションは、ディスクを初期化する際にパーティションの数や大きさなどを決めて作成するものであり、使用中にパーティションの構成を変更する事は容易に行なえるものではない。これは、パーティション毎に独立した論理的なアドレスや、空き領域の管理情報などを持っているのが一般的なので、構成を変更する場合は、多くの管理情報の再構成を行う必要があるからである。また、ユーザは初期化時にＡＶ用途とＰＣ用途にそれぞれどれぐらいの領域を確保するかを決めなければならない。しかし、使用していく過程で、どちらかの領域が足りなくなってしまう事が考えられる。
【００１５】
前述の通り、パーティションの大きさなどを変更するのが容易ではないため、例えば、ＰＣ用途の領域に空き領域が残っていたとしても、ＡＶ用途の領域が一杯になってしまった時点でそれ以上ＡＶデータを記録する事ができなくなり、ディスクを有効に利用する事ができず問題がある。また、同じＡＶ用途においても、論理ファイルシステムの管理情報を記録する領域、ＡＶデータを再生するための管理情報などが記録する領域、ＡＶデータを記録する領域、静止画を記録する領域と言ったように複数の領域に分けて管理を行ないたい場合もあり、これらの領域をそれぞれパーティションで管理を行なうと、パーティションの数が多いため、１つのパーティションが一杯になった場合に、ディスクが空いていたとしても、それ以上データ等が記録できなくなる可能性がそれだけ高くなり問題がある。
【００１６】
第２の方法のように、領域を、論理ファイルシステムで提供するパーティション機能では管理せず、実装レベルのアプリケーション層の管理情報として管理した場合、アプリケーションで領域を管理しているため、想定していないアプリケーションにとっては、この領域の位置情報が記録されている管理情報は何ら意味を持たない。それぞれ確保された領域は、論理ファイルシステムレベルで確保されているわけではないため、想定するアプリケーションのみでそのディスクを使用する場合は問題無いが、想定外のアプリケーションからアクセスされた場合は、領域を認識することができないため、確保した領域内に想定外のデータが記録される可能性があり、問題がある。
【００１７】
また、第３の方法のように、１つのファイルやデータを記録する領域を予約するためにダミーファイルを使う事により、領域を確保する事が可能である。この方法においては、例えば管理情報を記録するための連続領域を確保したい場合、今後記録されるファイルの大きさ、数を予測し、それと同じサイズ、数のダミーファイルを記録することで領域を確保しなければならない。よって、基本的にはファイルの想定される最大サイズでダミーファイルを作成することになり、実際書き込まれるファイルがダミーファイルのサイズより小さい場合、無駄が多く発生するという問題がある。
【００１８】
図１８に示す領域１において、書き込まれるファイルのサイズがそれぞれ１Ｍであると想定した場合、１Ｍのサイズのダミーファイルが作成されることになる。ここに０．８Ｍのファイルを書き込む場合は、まず最初のダミーファイル（ＤＵＭＭＹ１．ＤＡＴ）の位置に０．８Ｍのデータが書き込まれ、次に０．９Ｍのデータが書き込まれる場合は、次のダミーファイルの位置（ＤＵＭＭＹ２．ＤＡＴ）の位置に書き込まれるために、０．１Ｍの無駄な部分が発生するということになる。また、書き込まれるファイルのサイズが予測できない（最大サイズが見込めない）場合には、対応できないという問題がある。
【００１９】
そこで、本願発明は上記３つの方法における課題を解決するものであり、論理ファイルシステムによるパーティションの区分を行うことなく、所定の領域内に、所望のデータ以外が書き込まれることを防止することが可能となる。
【００２０】
【課題を解決するための手段】
本発明は、記録媒体と該記録媒体へのデータの入出力を管理する記録制御手段とを備える記録装置において、記録媒体において少なくとも１以上の領域を確保し、各領域の空き領域をそれぞれダミーファイルで管理する方法であり、当該領域にファイルを書き込む場合には、当該領域のダミーファイル上にファイルを書き込み、ダミーファイルのサイズを該領域の空き領域のサイズに更新することで上記課題を解決するものである。
【００２１】
【発明の実施の形態】
以下、本発明の領域管理方法に関する実施形態について、図面とともに詳細について説明する。本実施例は、ディスク装置として、ＡＶ記録再生を目的としたディスクを用いた携帯型のビデオカメラやビデオデッキ、ＰＣに接続された外部記憶装置などを想定するものである。ディスク媒体は、リムーバブルディスクが好ましいが、ハードディスクなどの据え付け型であっても構わない。また、説明の都合上ディスクに用いる論理ファイルシステムとしてＯＳＴＡ（Ｏｐｔｉｃａｌ  Ｓｔｏｒａｇｅ  Ｔｅｃｈｎｏｌｏｇｙ  Ａｓｓｏｃｉａｔｉｏｎ）の規格であるＵＤＦ（Ｕｎｉｖｅｒｓａｌ  Ｄｉｓｋ  Ｆｏｒｍａｔ）を想定するが、その他の汎用論理ファイルシステムであっても構わない。
【００２２】
一般的なディスク装置の構成を図１に示す。データ入力出力部１はカメラなどから入力される映像信号を取り込んだり、再生するデータをモニタ等に出力したりする。データ処理部２は、例えばＭＰＥＧ符号をエンコードしたり、デコードしたりする信号処理等を行う処理部であり、処理されたデータはメモリ３に格納される。データを記録する場合は、ディスク制御部５において、ディスク６を制御しディスク上の目的の箇所にデータが記録され、再生時には、ディスク６を制御しディスク上の目的の箇所からデータが読み出されてメモリ３に格納される。各処理部はシステム制御部４によって制御される。
【００２３】
このようなディスク装置において、ディスクの領域を分割して管理したい場合は、論理ファイルシステムにおけるパーティション機能を用いるのが一般的である。しかし、前述したように、一度パーティションを区切ってしまうとパーティションの大きさを変更したり、あるパーティションを他のパーティションと連結させて大きさを拡大すると言った事は容易に行なえない。本実施例ではパーティション機能によっての領域の分割は行なわないので、図２に示すようにディスクのユーザ領域全域を管理するように１つのパーティションを作成する。作成したパーティション内に、ある特定の情報を記録するための領域を定義するものとする。パーティション機能を利用しない事と、汎用ファイルシステムであるＵＤＦを用いるため、１つのパーティション内に複数の領域を管理するような論理ファイルシステムレベルの管理情報は存在しない。ここで重要になってくるのが、１つのディスクを複数のプラットフォームで使用する可能性がある事である。例えば、ＡＶ用途で記録されたディスクをＰＣのドライブでアクセスしたりする事が考えられる。従って、ＡＶアプリケーションと言った特定のアプリケーションのみで理解できるような情報での領域確保だけでは不十分である。つまり、ある特定の情報を記録するための領域を定義するという事は、ＡＶ用途においてデータの種類に応じた記録領域を管理するだけではなく、ＰＣアプリケーションなどからのアクセスがあったとしても、確保された領域への書き込みを抑制しなければならない事を意味する。これを実現するためには、確保された領域が論理ファイルシステムから見た場合に既にデータが記録されており、使われているものとして見えなければならない。
【００２４】
そこで、本発明では任意の数のある特定の情報を記録するための連続領域を確保するために、領域内においてデータが記録されておらず未使用な部分を管理する形でダミーファイルを作成するものとする。つまり、領域内の未使用部分にダミーファイルが管理するディスク上のデータがあたかも書き込まれているかのようにするわけである。
【００２５】
ＵＤＦでは、ボリュームレベルの管理情報とファイルシステムレベルの管理情報に分かれ、ここでは関連するファイルシステムレベルの管理情報について簡単に説明する。ボリュームレベルの管理情報によって定義されるパーティション内において、空き領域を管理するＳｐａｃｅ  Ｂｉｔｍａｐ  Ｄｅｓｃｒｉｐｔｏｒと、パーティション内のディレクトリ構造の基本情報やＲＯＯＴディレクトリを管理するＦｉｌｅ  Ｅｎｔｒｙへのポインタ情報を含むＦｉｌｅ  Ｓｅｔ  Ｄｅｓｃｒｉｐｔｏｒ、Ｆｉｌｅ  Ｓｅｔ  Ｄｅｓｃｒｉｐｔｏｒが終了した事を示すＴｅｒｍｉｎａｔｉｎｇ  Ｄｅｓｃｒｉｐｔｏｒ、ＲＯＯＴディレクトリのＦｉｌｅ  Ｅｎｔｒｙがファイルシステムレベルの管理情報として基本的に記録される。
【００２６】
Ｓｐａｃｅ  Ｂｉｔｍａｐ  Ｄｅｓｃｒｉｐｔｏｒとは、パーティション内で管理する全ての論理ブロックに対して１  ｂｉｔをそれぞれ割り当て、対応する論理ブロックが使われているか使われていないかを、ｂｉｔ情報が０か１かで判断するものである。ここでの論理ブロックとは、ファイルシステムにおける最小アクセス単位であり、ＵＤＦパーティション内において各論理ブロックに対して昇順に論理ブロック番号が付加される。
【００２７】
ディレクトリが定義されると、ディレクトリを管理するＦｉｌｅ  Ｅｎｔｒｙがディレクトリ内に含まれるファイルやディレクトリに対応するＦｉｌｅ  Ｉｄｅｎｔｉｆｉｅｒ  Ｄｅｓｃｒｉｐｔｏｒの集合の記録位置を管理する事になる。Ｆｉｌｅ  Ｉｄｅｎｔｉｆｉｅｒ  Ｄｅｓｃｒｉｐｔｏｒには、ファイルやディレクトリの名前や属性情報と対応するＦｉｌｅ  Ｅｎｔｒｙが記録されているアドレス情報が格納される。Ｆｉｌｅ  Ｅｎｔｒｙには、日付などの属性情報とこのファイル（Ｆｉｌｅ  Ｅｎｔｒｙ）が管理しているディスク上のデータの位置情報、あるいはディレクトリの場合には、ディレクトリ情報（Ｆｉｌｅ  Ｉｄｅｎｔｉｆｉｅｒ  Ｄｅｓｃｒｉｐｔｏｒの集合）が記録されている位置情報を管理している。このように、Ｆｉｌｅ  ＥｎｔｒｙとＦｉｌｅ  Ｉｄｅｎｔｉｆｉｅｒ  Ｄｅｓｃｒｉｐｔｏｒを辿って行く事によってディレクトリ階層を把握する事が可能となる。またこれらの情報は、ＵＤＦファイルシステムの管理情報であり、通常はデバイスドライバが利用するだけで、通常はユーザから見えない情報となる。図４にＵＤＦにおけるディレクトリ階層を表現するためのＦｉｌｅ  ＥｎｔｒｙとＦｉｌｅ  Ｉｄｅｎｔｉｆｉｅｒ  Ｄｅｓｃｒｉｐｔｏｒの関係を示す。
【００２８】
ダミーファイルによる領域確保の１つの例として、図２に、任意の数のある特定の情報を記録するための連続領域として領域１、２、３を定義し、連続領域２にファイルであるＦＩＬＥ１．ＤＡＴ、ＦＩＬＥ２．ＤＡＴ、ＦＩＬＥ３．ＤＡＴが記録されている様子を示す。実際のディスクでは、ＦＩＬＥ１．ＤＡＴに対応するＵＤＦの管理情報であるＦＥ（Ｆｉｌｅ  Ｅｎｔｒｙ）とデータ自体であるＦｉｌｅ１が記録されている。この例ではファイルの管理情報であるＦＥ（Ｆｉｌｅ  Ｅｎｔｒｙ）へのポインタ情報を含むＦｉｌｅ  Ｉｄｅｎｔｉｆｉｅｒ  Ｄｅｓｃｒｉｐｔｏｒは例えば領域１の中に記録されているものとして図示しない。
【００２９】
ディスク上の位置情報は、開始論理ブロック番号と論理ブロック数を示すＡｌｌｏｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒの集合で管理される。つまり、１つのファイル（Ｆｉｌｅ  Ｅｎｔｒｙ）で管理するデータがディスク上で連続的に記録されている場合、Ａｌｌｏｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒは１つ、２つに分断して記録されている場合はＡｌｌｏｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒ  ２つによってファイルの位置情報を管理する事になる。
【００３０】
ＦＩＬＥ１．ＤＡＴと同様にＦＩＬＥ２．ＤＡＴ、ＦＩＬＥ３．ＤＡＴに対応するＦＥ（Ｆｉｌｅ  Ｅｎｔｒｙ）と対応する実データが確保されている連続領域に記録されている。ここで、確保した連続領域内でデータが記録されていない未使用な部分に、ダミーファイルＤＵＭＭＹ１．ＤＡＴを作成する。つまり未使用部分にデータがあたかも書き込まれているようにダミーファイルＤＵＭＭＹ１．ＤＡＴを作成し、ＦＥ（Ｆｉｌｅ  Ｅｎｔｒｙ）のＡｌｌｏｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒで管理するわけである。また、ＵＤＦファイルシステムの管理情報で空き領域を管理するＳｐａｃｅ  Ｂｉｔｍａｐ  Ｄｅｓｃｒｉｐｔｏｒに関してもダミーファイルＤＵＭＭＹ１．ＤＡＴの管理している部分は使われているものとして扱う。
【００３１】
また、使用過程において、例えば図３におけるＦＩＬＥ２．ＤＡＴが削除された場合、通常はＦＩＬＥ２．ＤＡＴに対応するＦＥ（Ｆｉｌｅ  Ｅｎｔｒｙ）とデータが記録されていた箇所はＳｐａｃｅ  Ｂｉｔｍａｐ  Ｄｅｓｃｒｉｐｔｏｒによって未使用な部分であるとし、解放される。しかし本発明では、図に示すように削除された部分は解放せずに、前述したダミーファイルＤＵＭＭＹ１．ＤＡＴが管理する部分として扱う。この際、ＤＵＭＭＹ１．ＤＡＴのＦＥ（Ｆｉｌｅ  Ｅｎｔｒｙ）内のＡｌｌｏｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒを更新して、ＤＵＭＭＹ１．ＤＡＴが２つの分断から構成されるファイルとする事になる。
【００３２】
ダミーファイルを作成するのにあたって、確保した連続領域を利用するアプリケーションが理解できるダミーファイルの名前を規定しておく。図の例では、確保した連続領域内でのダミーファイルはＤＵＭＭＹ１．ＤＡＴとして規定されている。つまり、あるアプリケーションからみると、このＤＵＭＭＹ１．ＤＡＴは空き領域であると理解するのである。
【００３３】
このように常に、確保した連続領域内の未使用部分を管理するようにダミーファイルを作成する事によって、この領域を使用するアプリケーション以外にとって、この領域内は常に全て使用されているものとして扱われ、データが書き込まれる事はない。また、他のアプリケーションからのデータの書き込みを抑制するだけではなく、ダミーファイルを規定したアプリケーションにとっては、ダミーファイルの情報を取得する事によって、容易に確保した領域内の未使用部分の大きさや位置を把握する事ができるという効果もある。例えば、未使用部分の大きさは、ダミーファイルのファイルサイズを参照すればわかり、位置情報はダミーファイルのＦＥ  （Ｆｉｌｅ  Ｅｎｔｒｙ）内のＡｌｌｏｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒを参照する事によって容易に把握する事が可能である。つまり、ダミーファイルがそのまま、確保した領域内の未使用部分になるわけである。
【００３４】
また、ダミーファイルを理解できるアプリケーションが複数のメーカーによって実装されている場合、各メーカー間で必ずしも確保する連続領域の大きさが同一であるとは限らない。この場合にも、ダミーファイルの情報を参照するだけで、確保している領域内の未使用部分を把握できるので領域の大きさを規定しなくてもメーカー間の互換も取る事が可能となる。また、必要に応じて、領域内に記録されるべきファイルとダミーファイルの情報から、領域の大きさを把握する事が可能となる。
【００３５】
ここで、新規に特定の情報を記録するための所定サイズの連続領域を確保する場合の処理について詳細を図５に示すフローチャートを用いて説明する。ステップＳ１において、連続領域を確保する要求が発生すると、ステップＳ２において、ＵＤＦ論理ファイルシステムの管理情報であるＳｐａｃｅ  Ｂｉｔｍａｐ情報を参照する事によってディスク上の空き領域を把握する。ステップＳ３において、確保しようとする連続領域がディスク上の任意の箇所に確保できない場合は、ステップＳ５においてエラー処理を行ない処理を終了する。また、ステップＳ３において、確保しようとする連続領域がディスク上の任意の箇所に確保できる場合は、ステップＳ４において、確保する連続領域を管理する形でダミーファイルを作成し処理を終了する。具体的にはダミーファイルが作成されるディレクトリのディレクトリ情報にダミーファイルのＦｉｌｅ  Ｅｎｔｒｙへのポインタ情報である、Ｆｉｌｅ  Ｉｄｅｎｔｉｆｉｅｒ  Ｄｅｓｃｒｉｐｔｏｒを追加し、ダミーファイルのデータの位置情報や属性情報を管理するＦｉｌｅ  Ｅｎｔｒｙを記録する。この際、Ｆｉｌｅ  Ｅｎｔｒｙ内のＡｌｌｏｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒに、確保した領域の位置情報である開始論理ブロック番号と論理ブロック数を記録する。
【００３６】
ここで、実際にファイル作成要求が発生した場合の処理について説明する。ファイル作成要求があった場合、そのファイルをどの領域に書き込むことが可能であるかを判断する。例えば、図２に示すように領域１、領域２、領域３…と領域を分割している場合に、あるＡＶアプリケーションがファイルの書き込み要求をした場合、領域１に書き込むように対応づけられているとする。この判断は、例えばＡＶアプリケーションはＤＵＭＭＹ１．ＤＡＴの位置に書き込むように、ＡＶアプリケーション自体に定義しておくことによって行われる。例えば、ＡＶアプリケーション以外のＰＣアプリケーションなどは、ＤＵＭＭＹ１．ＤＡＴ上に書き込むことはなく、他の領域などに書き込むことになる。
【００３７】
また、各アプリケーションにファイル種別に応じて書き込む領域（ダミーデータとの対応）を定義しておくことにより、例えばｖｉｄｅｏデータはＤＵＭＭＹ１．ＤＡＴ上に書き込むこととし、ａｕｄｉｏデータはＤＵＭＭＹ２．ＤＡＴ上に書き込むように制御することも可能である。
【００３８】
つまり、所定のアプリケーションを所定の領域に書き込む、或いは所定の種別のファイルを所定の領域に書き込むことが可能となる。
【００３９】
次に、書き込む領域が決定した後、ダミーファイルによって確保された領域内にファイルを作成する場合の処理について詳細を図６に示すフローチャートを用いて説明する。
【００４０】
ステップＳ１０においてファイル作成要求が発生すると、ステップＳ１１においてダミーファイルの情報を取得する。具体的には、ダミーファイルとして規定されたファイル名より、対応するＦｉｌｅ  Ｅｎｔｒｙを参照しその情報よりダミーファイルのファイルサイズや位置情報を把握する。ステップＳ１２において、ダミーファイルのファイルサイズ、つまり確保した領域中の空きサイズが作成しようとしているファイルのサイズより大きいかどうかを判定する。ダミーファイルのサイズが作成しようとしているファイルのサイズより小さい場合は、確保された領域にファイルを作成するスペースがないので、ステップＳ１５においてエラー処理を行ない、処理を終了する。ステップＳ１２において、ダミーファイルのサイズが作成しようとしているファイルのサイズより大きい場合は、確保された領域にファイルが作成できるので、ステップＳ１３において、ダミーファイルが管理する空き部分にファイルを作成する。
【００４１】
具体的には、作成するファイルが含まれるディレクトリのディレクトリ情報に、ファイルを管理するＦｉｌｅ  Ｅｎｔｒｙへのポインタ情報であるＦｉｌｅ  Ｉｄｅｎｔｉｆｉｅｒ  Ｄｅｓｃｒｉｐｔｏｒを追加し、ファイルのデータの位置情報や属性情報を管理するＦｉｌｅ  Ｅｎｔｒｙを記録する。ステップＳ１４において、ダミーファイルのＦｉｌｅ  Ｅｎｔｒｙを更新し処理を終了する。この際、Ｆｉｌｅ  Ｅｎｔｒｙ内のＡｌｌｏｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒ情報から、新規作成したファイルに割り当てた部分を差し引く形で更新する。
【００４２】
ダミーファイルによって確保された領域内に存在するファイルのサイズの変更を伴う更新が発生する場合の処理について詳細を図７に示すフローチャート用いて説明する。
【００４３】
ステップＳ２０において、ファイルサイズ変更を伴うファイル更新要求が発生すると、ステップＳ２１においてファイルのサイズが大きくなるのか小さくなるのかを判定する。ファイルのサイズが縮小される場合は、ステップＳ２８において、縮小するファイルのＦｉｌｅ  ＥｎｔｒｙのＡｌｌｏｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒを縮小したデータを管理するように更新する。ステップＳ２９においてダミーファイルのＦｉｌｅ  ＥｎｔｒｙのＡｌｌｏｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒに縮小したファイルの箇所を追加する形で更新し処理を終了する。サイズが拡張される場合は、ステップＳ２２においてダミーファイルの情報を取得し、確保されている領域内の空き部分を把握する。ステップＳ２３において、ダミーファイルのサイズつまり確保されている領域内の未使用スペースの大きさと新たにファイルとして拡張されるデータサイズの比較を行なう。ダミーファイルのサイズの方が大きい場合、つまり確保された領域内に十分な空き部分がある場合、ステップＳ２４において、ダミーファイルの管理する未使用スペースに拡張するデータを記録する。ステップＳ２５において、拡張したファイルのＦｉｌｅ  ＥｎｔｒｙのＡｌｌｏｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒを更新する。ステップＳ２６においてダミーファイルのＦｉｌｅ  ＥｎｔｒｙのＡｌｌｏｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒを更新し処理を終了する。ステップＳ２３において、ダミーファイルのサイズより拡張するデータのサイズが大きい場合、つまり拡張するだけの空きスペースが残っていない場合は、ステップＳ２７においてエラー処理を行ない処理を終了する。
【００４４】
ダミーファイルによって確保された領域内に存在するファイルを削除する場合の処理について詳細を図８に示すフローチャート用いて説明する。ステップＳ３０において、ファイル削除要求が発生すると、ステップＳ３１おいてファイルの削除処理を行なう。具体的には、削除するファイルが含まれているディレクトリのディレクトリ情報から対応するＦｉｌｅ  Ｉｄｅｎｔｉｆｉｅｒ  Ｄｅｓｃｒｉｐｔｏｒを削除する。ステップＳ３２においてダミーファイルのＦｉｌｅ  Ｅｎｔｒｙを更新し処理を終了する。具体的には、削除したファイルが記録されていた部分を管理するように、ダミーファイルのＡｌｌｏｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒを更新する。
【００４５】
ダミーファイルによって確保された領域が足りなくなったりした事により、領域の大きさを拡張したい場合の処理について詳細を図９に示すフローチャート用いて説明する。
【００４６】
ステップＳ４０において、領域拡張要求が発生すると、ステップＳ４１においてＳｐａｃｅ  Ｂｉｔｍａｐよりディスクの空きスペースを把握する。ステップＳ４２において、拡張する領域の隣接箇所に拡張したいだけの連続領域が存在するかどうかを判定する。存在する場合はステップＳ４４においてダミーファイルのＦｉｌｅ  Ｅｎｔｒｙをその拡張領域も含める形で更新する。隣接箇所に確保したいだけの連続領域が無い場合は、図５に示した連続領域確保処理を行ない処理を終了する。この場合は、拡張する領域が既存の領域と連続的では無くなる。もし連続領域でなければならない場合は、ステップＳ４３において連続領域確保処理を行なわず、エラー処理を行なって処理を終了しても構わない。図１０にある領域を拡張した場合の例を示す。この例では、領域１にＦＩＬＥ１．ＤＡＴ、ＦＩＬＥ２．ＤＡＴ、ＦＩＬＥ３．ＤＡＴを記録し空き領域が無くなり、隣接した箇所を利用して領域を拡張しようとしたが、既に隣接領域２が確保されていた関係で、ディスク上の他の連続領域を確保した例である。領域１のダミーファイルはＤＵＭＭＹ１．ＤＡＴというファイル名で、領域１の拡張領域はＤＵＭＭＹ２．ＤＡＴというダミーファイルによって空きスペースが管理されている。ここで、ファイル名が規定されているので、ＤＵＭＭＹ２．ＤＡＴが存在する場合はディスク上の非隣接箇所に拡張した連続領域がある事を把握する事が可能となる。また、既存の連続領域を拡張したい場合に、隣接箇所が使われているために連続的に拡張できない場合、隣接するデータをディスク上の他の箇所へ移動し、領域を空けて連続的な拡張を行っても良い。
【００４７】
このように、論理ファイルシステムの機能であるパーティション機能を使っていないので、パーティションの大きさなどを変更する場合と比較して、ダミーファイルの更新だけで領域の大きさを変更することが可能となるので、遥かに単純な処理で行える。
【００４８】
なお、定義する連続領域においてダミーファイルで空きスペースを管理する際、図１１に示すように必ず連続領域の最後の論理ブロックをダミーファイルで管理しなければならないという制限を付けても良い。つまり、連続領域において最後の１論理ブロックは、ダミーファイルが管理するスペースとして常に確保する。よって、連続領域として確保したい大きさに、１論理ブロックとダミーファイルを管理するＦｉｌｅ  Ｅｎｔｒｙを記録する１論理ブロックの計２論理ブロックを余分に確保しておく事になる。よって、ダミーファイルＤＵＭＭＹ１．ＤＡＴを管理するＦｉｌｅ  Ｅｎｔｒｙ内のＡｌｌｏｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒの中で、一番大きい論理ブロック番号が確保している連続領域の最後尾という事になる。このように構成することによって、連続領域の最後までデータファイルが記録された場合に、連続領域の境界がわからなくなるということを防止し、連続領域の境界の把握を容易に行うことが可能となる。
【００４９】
また確保する連続領域内に記録されるファイルが決まっている場合は、それらのＦｉｌｅ  Ｅｎｔｒｙ内のＡｌｌｏｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒとダミーファイルの情報から連続領域の範囲を把握する事が可能であるが、その連続領域に記録されるファイル名などが決まっていない場合は、ファイル名からどの連続領域に記録されているデータであるかを判断することができないため、ダミーファイルによって空きスペースは把握する事が可能であるが、確保された連続領域の範囲を把握する事はできない。よってこのような場合、図１２に示すように必ず連続領域の先頭と最後尾の論理ブロックをダミーファイルで管理しなければならないという制限を付けても良い。つまり、連続領域において先頭と最後尾の１論理ブロックは、ダミーファイルが管理するスペースとして常に確保する。よって、連続領域として確保したい大きさに余分に２論理ブロックとダミーファイルのＦｉｌｅ  Ｅｎｔｒｙを記録する１論理ブロックの計３論理ブロックを確保しておく事になる。
【００５０】
あるいは、図１３に示すように、確保する連続領域の先頭はダミーファイルを管理するＦｉｌｅ  Ｅｎｔｒｙでなければならず、最後尾の１論理ブロックはダミーファイルが管理するスペースとして確保するようにしても構わない。
このように構成することによって、ダミーファイルＤＵＭＭＹ１．ＤＡＴを管理するＦｉｌｅ  ＥｎｔｒｙのＡｌｌｏｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒの中で一番小さい論理ブロック番号あるいはダミーファイルのＦｉｌｅ  Ｅｎｔｒｙ自体が記録されている論理ブロック番号が確保している連続領域の先頭位置となり、一番大きい論理ブロック番号が逆に連続領域の最後尾の位置となり、管理している連続領域の範囲を容易に把握する事が可能となる。
【００５１】
ここで、本発明の実際の適用例について図１４を用いて説明する。この図では、ＡＶデータを記録するＡＶ用途における領域管理の一例である。まず、領域としてファイルシステム管理情報領域、アプリケーション管理情報領域、データ領域に分割して管理するものとする。ファイルシステム管理情報領域には、ＵＤＦファイルシステムにおける基本管理情報である、Ｓｐａｃｅ  Ｂｉｔｍａｐ  Ｄｅｓｃｒｉｐｔｏｒ（ＳＢＤ）、Ｆｉｌｅ  Ｓｅｔ  Ｄｅｓｃｒｉｐｔｏｒ  （ＦＳＤ）、Ｔｅｒｍｉｎａｔｉｎｇ  Ｄｅｓｃｒｉｐｔｏｒ（ＴＤ）とＡＶアプリケーションによって規定されるディレクトリのＦｉｌｅ  Ｅｎｔｒｙ  （ＦＥ）と、ディレクトリ内に定義されるファイルやディレクトリを管理するＦｉｌｅ  Ｅｎｔｒｙへのポインタ情報である、Ｆｉｌｅ  Ｉｄｅｎｔｉｆｉｅｒ  Ｄｅｓｃｒｉｐｔｏｒ  （ＦＩＤ）を記録するものとする。この図の例では、ＲＯＯＴディレクトリ、ＡＶデータの管理情報を記録するＡＶＭＡＮディレクトリ、ＡＶデータを記録するＡＶＤＡＴディレクトリを管理するＦｉｌｅ  Ｅｎｔｒｙと、それぞれのディレクトリ内で定義されるファイルのＦｉｌｅ  Ｉｄｅｎｔｉｆｉｅｒ  Ｄｅｓｃｒｉｐｔｏｒ  （ＦＩＤ）の集合が記録されている。そして、ダミーファイルＬＯＧＩ．ＤＭＹがファイルシステム管理情報領域における未使用部分を管理している。
【００５２】
アプリケーション管理情報領域は、ＡＶデータを再生するための管理情報などのＡＶアプリケーションの管理情報が記録される領域である。この領域には、ＡＶデータの管理情報である、ＡＶＩＮＦＯ１．ＤＡＴおよびＡＶＩＮＦＯ２．ＤＡＴが記録されており、ディスクにはそれぞれに対応するＦｉｌｅ  Ｅｎｔｒｙとデータの実体が記録されている。ファイルシステム管理情報領域と同様に、ダミーファイルＡＰＰＬ．ＤＭＹがアプリケーション管理情報領域における未使用部分を管理している。このような構成のディスクをユーザがアクセスすると、図１５に示すようなディレクトリ階層として見える事になる。
【００５３】
データ領域には、ＡＶデータであるＡＶ１．ＤＡＴおよびＡＶ２．ＤＡＴが記録されており、ディスクにはそれぞれに対応するＦｉｌｅ  Ｅｎｔｒｙとその実体が記録されている。この図の例では、データ領域に関しては、ダミーファイルによるデータ領域の領域確保は行なっていないが、必要に応じてダミーファイルを定義して領域を確保しても構わない。
【００５４】
このように、ファイルシステム管理情報領域の未使用箇所は、ダミーファイルＬＯＧＩ．ＤＭＹによって管理され、アプリケーション管理情報領域の未使用箇所はダミーファイルＡＰＰＬ．ＤＭＹによって管理されており、これらの領域を使用するＡＶアプリケーションにとっては、それぞれ対応する領域の空き領域を管理しているものとして扱われる。例えばこのような状況のディスクをＰＣに接続されたディスクドライブでアクセスした場合には、ファイルシステム管理情報領域とアプリケーション管理情報領域には、空きスペースが無い状態でファイルが記録されているように扱われるため、領域が確保されているのと等価になる。よって、これらの領域にデータが書き込まれる事が無くなる。
【００５５】
また、この時ＰＣアプリケーションからＡＶアプリケーションで使用しているディレクトリやＡＶデータの管理情報などが削除されては困るので、これらのファイルやディレクトリの属性として書き込み禁止を設定しても良い。つまり、ＰＣアプリケーションはデータ領域の空き領域にしか書き込むことができないこととなる。また、当然ダミーファイル自体が削除されても困るので、同様に書き込み禁止属性を設定しても良い。またダミーファイルはＰＣアプリケーションから見えないようにするために、隠しファイル属性を設定しても良い。仮にダミーファイルが誤って消されてしまった場合には、現在定義されているファイルやディレクトリの論理ファイルシステムの管理情報と空き領域を管理しているＳｐａｃｅ  Ｂｉｔｍａｐ  Ｄｅｓｃｒｉｐｔｏｒの情報からダミーファイルを再構築する事も可能である。
【００５６】
【発明の効果】
本発明によれば、確保した連続領域内の未使用部分を管理するようにダミーファイルを作成する事によって、この領域を使用するアプリケーション以外にとって、この領域内は全て使用されているものとして扱われ、データが書き込まれる事を抑制することが可能となる。
【００５７】
また、ダミーファイルを規定したアプリケーションにとっては、ダミーファイルのファイルサイズや位置情報を取得する事によって、容易に確保した領域内の未使用箇所の大きさや位置を把握する事が可能となり領域内でのファイル作成や更新が容易に行える事になる。
【００５８】
また、ダミーファイルを理解できるアプリケーションが複数のメーカー等によって実装されている場合、必ずしも確保する連続領域の大きさが同一であるとは限らない。この場合にも、ダミーファイルの情報を参照するだけで、未使用部分を把握できるのでメーカー間の互換も取る事が可能となる。
【００５９】
また、論理ファイルシステムの機能であるパーティション機能を使っていないので、パーティションの大きさなどを変更する事と比較して、ダミーファイルの更新といった単純な処理だけで領域の大きさを変更することが可能となる。確保した連続領域の範囲を知る必要がある場合は、必要に応じて連続領域の最後尾あるいは先頭と最後尾の両方の論理ブロックをダミーファイルで管理する事によって、容易に管理している連続領域の範囲を把握することが可能となる。
【図面の簡単な説明】
【図１】本発明における一実施形態であるディスク装置の構成を示すブロック図である。
【図２】本発明の領域管理方法の実施形態においてダミーファイルによって領域を確保している様子を示す説明図である。
【図３】本発明の領域管理方法の実施形態においてファイルが削除された際のダミーファイルの様子を示す説明図である。
【図４】本発明の領域管理方法の実施形態においてＵＤＦ管理情報の関係を示す説明図である。
【図５】本発明の領域管理方法の実施形態において連続領域を確保する処理の流れを示すフローチャートである。
【図６】本発明の領域管理方法の実施形態において確保した連続領域内にファイルを作成する際の処理の流れを示すフローチャートである。
【図７】本発明の領域管理方法の実施形態において確保した連続領域内のファイルの大きさの変更を伴う更新がある場合の処理の流れを示すフローチャートである。
【図８】本発明の領域管理方法の実施形態において確保した連続領域内のファイルを削除する際の処理の流れを示すフローチャートである。
【図９】本発明の領域管理方法の実施形態において確保した連続領域を拡張する際の処理の流れを示すフローチャートである。
【図１０】本発明の領域管理方法の実施形態において確保した連続領域を拡張する際の例を示す説明図である。
【図１１】本発明の領域管理方法の実施形態において領域内のダミーファイルが必ず最後の論理ブロックを管理する様子を示す説明図である。
【図１２】本発明の領域管理方法の実施形態において領域内のダミーファイルが必ず先頭と最後の論理ブロックを管理する様子を示す説明図である。
【図１３】本発明の領域管理方法の実施形態において領域内のダミーファイルが必ず最後の論理ブロックを管理し、ダミーファイルのファイルエントリが最初の論理ブロックに配置される様子を示す説明図である。
【図１４】本発明の領域管理方法の実施形態における実際の適用例を示す説明図である。
【図１５】本発明の領域管理方法の実施形態において図１２の例のディレクトリ階層を示す説明図である。
【図１６】従来技術におけるパーティションによる領域確保の様子の説明図である。
【図１７】従来技術における領域の位置情報を記録するファイルによる領域確保の様子の説明図である。
【図１８】従来技術におけるファイル単位でのダミーファイルによる領域確保の様子の説明図である。
【符号の説明】
１  データ入出力部
２  データ処理部
３  メモリ
４  システム制御部
５  ディスク制御部
６  ディスク
【図１】
0003607153.tif 000002
【図２】
0003607153.tif 000003
【図３】
0003607153.tif 000004
【図４】
0003607153.tif 000005
【図５】
0003607153.tif 000006
【図６】
0003607153.tif 000007
【図７】
0003607153.tif 000008
【図８】
0003607153.tif 000009
【図９】
0003607153.tif 000010
【図１０】
0003607153.tif 000011
【図１１】
0003607153.tif 000012
【図１２】
0003607153.tif 000013
【図１３】
0003607153.tif 000014
【図１４】
0003607153.tif 000015
【図１５】
0003607153.tif 000016
【図１６】
0003607153.tif 000017
【図１７】
0003607153.tif 000018
【図１８】
0003607153.tif 000019