JP2002373099A - ディスク管理方法 - Google Patents

Abstract

(57)【要約】 【課題】 ディスクメディアのファイルの記録方式は、
ファイルの実体の記録領域を管理する管理情報も記録す
るが、この管理情報が読めなくなると、ファイルの実体
に異常が無くてもファイルが読み出せなくなる。 【解決手段】 ディスク101上にファイルの実体102と、
該ファイルの実体102の記録領域を管理する第１の管理
情報103とを記録するファイルシステムにおいて、前記
ファイルの実体102の記録領域を管理する第２の管理情
報105を作成して、該第２の管理情報105を前記第１の管
理情報103とは異なる領域に記録し、前記第１及び第２
の管理情報103,105によって、前記ファイルの実体102の
記録領域を共有して管理し、前記第１の管理情報103を
参照して読み出すことができるファイルをオリジナルフ
ァイルと見なし、前記第２の管理情報105を参照して読
み出すことができるファイルをバックアップファイルと
見なす。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ファイルやディレ
クトリの管理情報の保護を可能とするディスク管理方法
に関するものである。

【０００２】

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

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

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

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

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

【０００７】ディスク上には、ディスク全体に割り振ら
れた論理セクタ番号(LSN:Logical Sector Number)とパ
ーティション内に割り振られた論理ブロック番号(LBN:L
ogical Block Number)との二つのアドレス情報が付加さ
れている。

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

【０００９】ファイルの実体は、その管理情報であるFE
(File Entry)内のAD(Allocation Descriptor)によって
記録位置が管理されている。図２７及び図２８にFE、AD
の構造規格を示す。FEの先頭にはDescriptor Tagが記録
される。Descriptor Tag については後述する。

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

【００１１】Record Format、Record Display Attribut
e、Record Lengthはレコード記録用のフィールドで現在
のUDFでは使用しない。Information LengthにはADの管
理する領域であるファイルの実体の総サイズ、Logical
Block RecordedにはADの管理する領域であるファイルの
実体の総論理ブロック数が記録される。

【００１２】Access Date and Time、Modification Dat
e and Time、Attribute Date and Timeには最終アクセ
ス時間、最終更新時間、最終属性変更時間が記録され
る。Checkpointは現在のUDFでは常に1が記録され、使用
されていない。Extended Attribute ICB及びExtended A
ttributesは拡張属性用のフィールド、Implementation
Identifierはシステム用の識別情報が記述できるフィー
ルドで、Unique IDには各FE固有の番号が付与される。

【００１３】Extended Attributes フィールドの大きさ
はLength of Extended Attributesに記録される。Alloc
ation DescriptorsはADを記録するフィールドで、Lengt
h of Allocation Descriptorsに大きさが記録される。
ファイル用のFEにおいてADはファイルの実体を記録した
ディスク上の連続した1領域を記録し、Extent Lengthと
Extent Positionから構成される。

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

【００１５】ディレクトリも同様にFEで管理されてい
る。ディレクトリ用のFE内のADはFID(File Identifier
Descriptor)の集合の記録位置を管理している。ただ
し、先頭のFIDは親ディレクトリの記録位置を管理する
ものであり、本書面の図中ではその矢印を省略する。図
３１及び図３２にFIDとFIDに含まれるICB(Information
Control Block)の構造規格を示す。FIDの先頭もDescrip
tor Tagが記録されている。File Version Numberにファ
イルの版数、File Characteristicsには属性情報が記録
される。

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

【００１７】ICBはFE領域の記録位置を管理する情報
で、Extent Length、Extent Location、Flags、UDF Uni
que IDから構成されている。Extent Lengthには領域の
大きさがバイト単位で、Extent Locationには領域の開
始LBNが、Flagsは領域管理属性用のフィールドでUDF Un
ique IDにはFIDの参照先であるFEと同じUnique IDが記
録される。

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

【００１９】Descriptor CRCはタグ以降のDescriptor C
RC Lengthで指定された長さのデータに対してCRCチェッ
ク用の値が記録される。Tag Locationにはこの記述子自
体の記録位置（LBN）が記録される。

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

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

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

【００２３】抽出したFID内のICBよりMQ#ROOTディレク
トリのFEの記録位置を把握しディスクから読み出す。同
様にMQ＿ROOTディレクトリのFEが管理するFID列よりSHR
P0001.MQTに対応するFIDを抽出し、これによりFEをディ
スクから読み出す。読み出したFEには目的のファイルSH
RP0001.MQTの実体の記録位置がADに記録されているた
め、この情報を元にディスクから読み出す事が可能とな
る。

【００２４】

【発明が解決しようとする課題】このような論理ファイ
ルシステムを用いたディスクは、通常使用している場合
には全く問題は無いが、場合によってはディスクに記録
した情報が読み出せないといったことが起こる可能性が
ある。

【００２５】これは、例えば何らかのショックによって
ディスク自体に傷が付いてしまったり、書き込み中にシ
ョックが加わり本来書き込むべき箇所でない所に書き込
みを行ない、記録内容を書き変えてしまったり、リムー
バブルディスクの場合はディスクの表面に汚れが付着し
てしまったりすることによって発生する。

【００２６】ディスクに書き込む前に問題のある箇所が
発見できた場合には、ディスクの問題箇所の代わりに代
替領域に記録するディフェクトマネジメント機能を利用
することによって、問題を回避することができるが、情
報を書いた後に問題が発生すると、その情報をディスク
から読み出せなくなってしまうという問題がある。

【００２７】記録したデータ自体が読み出せないことも
問題であるが、前述した論理ファイルシステムの管理情
報がディスクから読み出せないことも大きな問題とな
る。仮にあるファイルにアクセスするための論理ファイ
ルシステムの管理情報が何らかの理由によって読み出せ
ないと、例えディスク上のデータに影響が無くても、対
応するデータがディスクのどこに記録されていたかが不
明となるため、データにアクセスできなくなってしま
う。

【００２８】PC用途で使用しているディスクでは、この
ようなことが起こる可能性は稀である。これは、PC用途
のドライブが物理的に安定した環境で使用されているこ
とが多いためである。一方、AV用途でリムーバブルディ
スクを記録媒体としたビデオカメラなどを考えた場合、
必ずしも物理的に安定した環境で使用されるとは限らな
い。

【００２９】すなわち、ビデオカメラは手に持って撮影
するが、走りながらの撮影や、何かにぶつかったりする
と、ディスクにデータを記録している最中にショックが
加わることが考えられる。このように、PC用途で使用す
る場合と比較して苛酷な状況で使用されることが考えら
れ、前述したようなディスクからデータが読み出せない
といった予期せぬ状況が発生する確率が高くなる。

【００３０】このような問題に対し、ミラーリングとい
うバックアップ方法がある。これは、ディレクトリ構成
やファイルを複製することによって、一方が壊れてもも
う一方のバックアップファイルにアクセスできるという
ものである。

【００３１】しかしながら、この方法はファイルの実体
も複製するので、容量の限られた媒体で実施するのは現
実的ではない。また、汎用性や実装の手間などを考慮す
ると、バックアップの為にファイルシステムに専用の機
構を設けることは極力避けたほうが良い。

【００３２】

【課題を解決するための手段】本願の第１の発明は、デ
ィスク上にファイルの実体と、該ファイルの実体の記録
領域を管理する第１の管理情報とを記録するファイルシ
ステムにおいて、前記ファイルの実体の記録領域を管理
する第２の管理情報を作成して、該第２の管理情報を前
記第１の管理情報とは異なる領域に記録し、前記第１及
び第２の管理情報によって、前記ファイルの実体の記録
領域を共有して管理し、前記第１の管理情報を参照して
読み出すことができるファイルをオリジナルファイルと
見なし、前記第２の管理情報を参照して読み出すことが
できるファイルをバックアップファイルと見なすことを
特徴とする。

【００３３】本願の第２の発明は、前記オリジナルファ
イルが含まれる第１のディレクトリの下に、第２のディ
レクトリを作成し、前記バックアップファイルが前記第
２のディレクトリ下に含まれるように、前記第２の管理
情報を作成することを特徴とすることを特徴とする。

【００３４】本願の第３の発明は、ファイルの更新が行
われた場合に、該ファイルの更新に合わせて、前記第２
の管理情報も更新することを特徴とする。

【００３５】本願の第４の発明は、ファイルが読み出せ
なくなった場合に、前記第２の管理情報にアクセスし、
該ファイルを再構築することを特徴とすることを特徴と
する。

【００３６】本願の第５の発明は、任意の第３のディレ
クトリの下に、第４のディレクトリを作成し、前記第３
のディレクトリの下に作成されている第５のディレクト
リを、前記第４のディレクトリの下に複製して、該複製
されたディレクトリを第６のディレクトリとし、前記複
製元の第５のディレクトリと前記第６のディレクトリと
によって、前記第５のディレクトリ下に含まれるファイ
ルやディレクトリの管理情報を共有することを特徴とす
る。

【００３７】本願の第６の発明は、任意の第７のディレ
クトリ下に、第８のディレクトリを作成し、前記第７の
ディレクトリ下に作成されている全ディレクトリ構造
を、前記第８のディレクトリ下に複製し、前記オリジナ
ルファイルに対応するバックアップファイルを、第８の
ディレクトリ下に含まれる各ディレクトリのそれぞれの
下に作成することを特徴とする。

【００３８】本願の第７の発明は、ディレクトリの更新
が行われた場合に、該ディレクトリの更新に合わせて、
前記複製されたディレクトリ情報も更新することを特徴
とする。

【００３９】本願の第８の発明は、ディレクトリが読み
出せなくなった場合に、前記複製されたディレクトリに
アクセスし、該ディレクトリを再構築することを特徴と
する。

【００４０】本願の第９の発明は、オリジナルの管理情
報に、バックアップの管理情報によって管理される記録
領域情報を記録することを特徴とする。

【００４１】本願の第１０の発明は、バックアップの管
理情報に、オリジナルの管理情報によって管理される記
録領域情報を記録することを特徴とする。

【００４２】本願の第１１の発明は、前記オリジナルの
管理情報が、複製元のディレクトリの管理情報であり、
前記バックアップの管理情報が、複製されたディレクト
リの管理情報であることを特徴とする。

【００４３】本願の第１２の発明は、前記管理情報が、
UDF(Universal Disk Format)におけるFE(File Entry)で
あることを特徴とする。

【００４４】本願の第１３の発明は、前記管理情報が、
UDF(Universal Disk Format)におけるFID(File Identif
ier Descriptor)であることを特徴とする。

【００４５】

【発明の実施の形態】以下、本発明のディスク管理方法
の実施形態を、UDFファイルシステムに適用した場合に
ついて説明する。尚、以下の説明では、通常のUDFファ
イルシステムの処理で記述されたファイルやディレクト
リをオリジナルファイルやオリジナルディレクトリと呼
び、情報の保護の為に本発明によって記録されるファイ
ルやディレクトリをバックアップファイルやバックアッ
プディレクトリと呼ぶこととする。

【００４６】従来のミラーリング手法によるファイルや
ディレクトリの複製によるバックアップは、容量に十分
余裕が無い媒体で実施するのは現実的ではないため、本
発明ではファイルシステムの管理情報のみを２重化する
事を考える。これによって、管理情報に問題があった場
合に例えディスク上の実体に問題が無くても、その実体
にアクセスできなくなってしまう問題を解決する。

【００４７】また、1バイトでもデータが正しく読み出
せないと意味をなさないPC用途のデータやアプリケーシ
ョンプログラムとは異なり、ファイルが管理する実体が
AVデータである場合は、仮にデータの一部に問題があっ
たとしても大きな問題とならない可能性がある。この場
合、AVデータを再生する画面にノイズが出たり、スピー
カからノイズが出たりすることになり、ファイルの管理
する全データが無意味になってしまうことは無い。

【００４８】そこで、少なくともファイルシステムの管
理情報を２重化し、オリジナルファイルの管理情報とバ
ックアップファイルの管理情報はディスク上の実体を共
有する形を取る。これにより、ファイルの実体にアクセ
スするための管理情報を２重に持ち、それぞれの管理情
報から同一のファイルの実体にアクセス可能となる。

【００４９】また、２重化したバックアップファイルは
通常のUDFの枠組みで作成されているために既存のUDFフ
ァイルシステムからアクセスを可能となる。つまり、バ
ックアップ情報にアクセスするために特別な処理を行う
必要がない事になる。また、オリジナルファイルの管理
情報に問題が発生した際に、バックアップファイルの情
報から復旧させたりする処理も、既存のUDFの管理情報
を作成や更新するための処理を組み合わせることによっ
て実現できるため実装の負担を減らすことが可能とな
る。

【００５０】図１を用いてファイルの実体の記録領域を
共有して二重に管理する手段について説明する。ディス
ク(101)上に記録されたファイルの実体(102)は、その記
録領域をFE(103)内のAD(104)によって管理されている。

【００５１】本発明では、前記FE(103)と等価な情報を
持つBackup-FE(105)を記録する。記録位置が異なるた
め、FEの記録領域の位置情報を管理するTag Locationに
設定する値は異なるが、タイムスタンプなどは同じ値が
設定される。また、UDF規格では同じUnique IDを異なる
FEに与えることが出来ないことから異なるUnique IDを
設定する必要がある。Backup-FE(106)はAD(104)と同じ
情報を持つAD(106)を含んでいる。

【００５２】その結果、Backup-FE(105)からもFE(103)
から参照できるファイルの実体と同じファイルの実体を
参照することが出来る。それはあたかも、もう一つファ
イルが作成されたように見えるので本発明では、Backup
-FEから参照できるファイルをバックアップファイルと
呼ぶことにしている。また、前記ファイルシステム内の
いずれかのFIDがBackup-FE(105)の記録位置を管理して
いるため、FE(104)と同様に通常のファイルシステムか
ら普通のファイルとしてアクセス可能である。

【００５３】ただし、アクセス属性は、実行不可、書込
不可、読込可、属性変更不可、削除不可とする。また、
システムファイル属性及び隠しファイル属性を設定す
る。本発明のバックアップ方法が実装されたUDFファイ
ルシステムであれば全く問題が無いが、実装されていな
い汎用的なUDFファイルシステムによってアクセスを行
う場合、オリジナルの情報とバックアップ情報との間の
不整合が発生することも考えられる。

【００５４】汎用的なUDFファイルシステムよりバック
アップファイルが削除可能であると、FE(103)がその領
域を管理しているにも関わらず、ファイルの実体(102)
の記録領域が解放されてしまうという不整合が生じる事
が考えられる。

【００５５】この不整合を防ぐためにバックアップファ
イルやバックアップディレクトリに前記の属性を設定す
る。また、バックアップファイルやバックアップディレ
クトリはあくまでもオリジナルファイルやオリジナルデ
ィレクトリに問題が発生した際にUDFのファイルシステ
ムが利用するバックアップ情報であるため、ユーザ側に
提示する必要の無い情報である。

【００５６】一方、仮に汎用的なUDFファイルシステム
によってオリジナルファイルやオリジナルディレクトリ
に変更等を加えた場合にもバックアップ情報との不整合
は発生する。しかしながら、ユーザがバックアップ情報
に直接アクセスすることが無いため、次に本発明のバッ
クアップ方法が実装されたUDFファイルシステムによっ
てアクセスした時に、この不整合を修復することが可能
である。

【００５７】編集に関しても同様で、両FEの管理領域に
不整合が生じてしまう恐れがあるため、バックアップフ
ァイルやディレクトリに前記の属性情報を設定する。FI
Dに記録されるFile Identifierつまりファイル名は、オ
リジナルファイルとバックアップファイルの関係を明示
するために同じ値が設定される。

【００５８】ここで、図２にファイルを記録する際にBa
ckup-FEを記録する手順をフローチャートで示す。ま
ず、ファイルの実体(102)をディスク(101)に記録する(S
101)。次に、ファイルの実体(102)の記録領域を管理す
るFE(103)をディスク(101)に記録する。そして、そのオ
リジナルファイルが属するディレクトリの管理情報にFE
(103)を管理するFIDを追加する(S103)。ここまでは通常
のUDFファイルシステムで行われる手順である。

【００５９】これに加え、ファイルの実体(102)を管理
するBackup-FE(105)をディスク(101)に記録する(S10
4)。そして、バックアップファイルを記録するディレク
トリの管理情報に Backup-FE(105)を管理するFIDを追加
する(S105)。

【００６０】同様に、図３にファイルを更新する手順を
フローチャートで示す。まず、ファイルの実体(102)を
更新する(S106)。次に、ファイルの実体(102)の記録領
域を管理するFE(103)を更新する(S107)。そして、バッ
クアップファイルの管理情報Backup-FE(105)がある場合
(S108)、Backup-FE(105)を更新(S109)して終了する。

【００６１】また、Backup-FE(105)がない場合、新たに
Backup-FE(105)を作成し(S110)、バックアップファイル
を記録するディレクトリの管理情報に、Backup-FE(105)
を管理するFIDを追加する(S111)。

【００６２】以降、説明に用いるディレクトリ構造のモ
デルとして図４に示すディレクトリ構造を用いる。ルー
トディレクトリ下に「SMAS0000.SMF」というファイルと
「MQ#ROOT」というディレクトリが存在し、「MQ#ROOT」
ディレクトリ下に複数のディレクトリが存在する。本モ
デルではそのうち「MQ#VIDEO」ディレクトリに注目す
る。同様に「100SHARP」ディレクトリが存在し、「100S
HARP」ディレクトリ下に複数のファイルが存在する。本
モデルではそのうち、「SHRP0001.MQT」と「SHRP0002.M
QT」に注目する。

【００６３】また、図５に図４のモデルに示されたディ
レクトリ構造のディスク上の配置イメージを示す。ディ
レクトリ構造を把握するために必要な情報は、ディレク
トリのFEとディレクトリ名もしくはファイル名を記録し
たFIDである。これらをディレクトリ情報と呼ぶことに
する。

【００６４】本モデルでは、ディレクトリ情報に高速に
アクセス出来るように、上記のディレクトリ情報を連続
した領域に書き込んでいる。またそのための領域を確保
するためにSMF(Space Management File)ファイルと呼ば
れるダミーファイルを配置している。

【００６５】本モデルの「SMAS0000.SMF」がこれにあた
る。これは、上記のディレクトリ情報を連続領域に書き
込む機能をサポートしていないファイルシステムでこの
ディレクトリ情報用に確保した領域にファイルのFEや実
体を書き込ませないために導入している。この機能をサ
ポートしたファイルシステムでディレクトリ情報を記録
・更新する場合は、SMFファイルの管理する領域を利用
してディレクトリ情報が連続するように記録し、SMFフ
ァイルの管理する領域を更新する。

【００６６】次に、本発明の第1の実施形態について説
明する。図６に図４のモデルに第1の実施形態を適用し
たディレクトリ構成を示す。ファイルの存在するROOTデ
ィレクトリ下及び「100SHARP」ディレクトリ下に「back
up」ディレクトリを作成し、それぞれのオリジナルディ
レクトリ下に記録されたオリジナルファイルに対応する
バックアップファイルを「backup」ディレクトリ下に作
成する。図中でファイルが破線で描かれているのはBack
up-FEつまり、バックアップファイルであることを示し
ている。

【００６７】また、図７に図４に対応したディスク上の
配置イメージを示す。ROOTディレクトリ及び「100SHAR
P」ディレクトリのFID列には「backup」ディレクトリの
FEの位置情報を持つFID(201,202)が追加されている。
「backup」ディレクトリのFE(203,204)が管理するFID列
には各Backup-FEの管理情報が記録されている。本実施
形態ではディレクトリ情報の他に「backup」ディレクト
リ以下のバックアップ情報も連続領域に記録され、領域
を確保するためにSMFファイルが使用されている。

【００６８】そのため、SMFファイルは２つに分断され
た１つのファイルから構成されている。図のようにオリ
ジナルファイルやオリジナルディレクトリの管理情報と
バックアップファイルやバックアップディレクトリの管
理情報を物理的に離して記録しているのは、近接領域に
記録されていることによるオリジナルとバックアップの
管理情報が同時に読み出せなくなることを防ぐためであ
る。本実施形態は、構造が簡単であることとバックアッ
プに必要な記録領域が小さいという利点がある。

【００６９】ここで、図８に第１の実施形態におけるフ
ァイルの作成フローチャートを示す。まず前述のS101〜
S103に相当するファイルの作成処理を行う(S201)。次に
書き込んだファイルのBackup-FEを作成する(S202)。「b
ackup」ディレクトリがない場合には(S203)、「backu
p」ディレクトリを作成する(S204)。そしていずれの場
合も、Backup-FEを管理するFIDを「backup」ディレクト
リに追加する（S205）。

【００７０】ここで、第１の実施形態におけるファイル
の復旧手順について図９のフローチャートを用いて説明
する。あるファイルのFEの読み出しに失敗し、ファイル
の実体が読み出せなかったとする(S301)。読み出しの失
敗は、例えばディスクからデータが物理的に読み出せな
いような場合や、読み出せたとしても管理情報のDescri
ptor Tagに記録されているCRC情報やChecksum情報が正
しくないことによって検出を行う。そのファイルの記録
されているディレクトリに「backup」ディレクトリがな
い場合(S302)、復旧不能として終了する。

【００７１】また、「backup」ディレクトリに同名のバ
ックアップファイルがない場合(S303)も、復旧不能とし
て終了する。バックアップディレクトリやバックアップ
ファイルが存在するかどうかは、対象となる名前（File
Identifier）を持つFIDがあるかどうかで判断する。

【００７２】バックアップファイルが見つかった場合
は、そのバックアップファイルが管理するBackup-FEを
ディスクから読み出してオリジナルのFEを復旧する。も
しFEが読み出せない理由が物理的破損などその領域に書
込みが出来ない問題であれば、新たに他の領域を確保し
てFEを再構築する必要がある。書込みが可能であれば、
同じ領域に再書込みすれば良い。このときFEのDescript
or Tag内のTag Locationの値などは記録するディスク上
の位置に応じて変更を行ってから書き込みを行う。

【００７３】次に、本発明の第２の実施形態について説
明する。第２の実施形態は第１の実施形態の「backup」
ディレクトリ下にファイルだけではなくディレクトリも
バックアップする手法である。図１０に第２の実施形態
を図４のモデルに適用したディレクトリ構成を示す。各
ディレクトリに「backup」ディレクトリを作成する。
「backup」ディレクトリ下には実施形態１と同様にバッ
クアップファイルが記録される。

【００７４】また、各ディレクトリ下に存在するディレ
クトリ情報がバックアップされる。複製されたディレク
トリには、前述した理由に読込専用、システムファイ
ル、隠しファイルの属性が設定される。図１１に図１０
に対応したディスク上の配置イメージを示す。各ディレ
クトリのFID列には「backup」ディレクトリへのFID(40
1,402,403, 404)が追加されている。

【００７５】各「backup」ディレクトリ下に複製された
ディレクトリのFE(405,406,407)は、Backup-FEと同様に
Tag Location、Unique IDはオリジナルと異なる値を設
定するが、タイムスタンプなどは同じ値を記録する。複
製されたディレクトリは、それぞれ複製されたFID列を
管理する。複製されたFID列に含まれる各FIDも同様にTa
g Location以外は同じ値を設定する。

【００７６】つまり、複製されたFID列に含まれる各FID
とオリジナルのFID列に含まれる各FIDが同じ領域を管理
することになるので、「backup」ディレクトリ下に複製
されたディレクトリはオリジナルのディレクトリ下に含
まれるファイル及びディレクトリの管理情報を共有して
いることになる。

【００７７】ここで、第２の実施形態における復旧手順
について説明する。ファイルの復旧手順は第１の実施形
態と同じなので説明は省略する。ディレクトリの復旧手
順について図１２のフローチャートを用いて説明する。
ディレクトリへのアクセスに失敗し、そのディレクトリ
の情報が得られなかったとする(S401)。

【００７８】アクセスの失敗は、例えばディスクからデ
ータが物理的に読み出せないような場合や、読み出せた
としても管理情報のDescriptor Tagに記録されているCR
C情報やChecksum情報が正しくないことによって検出を
行う。そのディレクトリの記録されているディレクトリ
に「backup」ディレクトリがない場合(S402)、復旧不能
として終了する。

【００７９】また、「backup」ディレクトリに同名のデ
ィレクトリがない場合(S403)、復旧不能として終了す
る。バックアップディレクトリが存在するかどうかは、
対象となる名前（File Identifier）を持つFIDがあるか
どうかで判断する。ディレクトリが見つかった場合は、
オリジナルのディレクトリ情報のうちどの情報に問題が
あるのかを特定する(S404)。

【００８０】FEに問題がある場合は、第１の実施形態の
復旧方法と同じで、そのFile Identifierつまりディレ
クトリ名が記録されているFIDが管理するFEを用いてオ
リジナルのFEを復旧する(S405)。もし、FEが読み出せな
い理由が物理的破損などその領域に書込みが出来ない問
題であれば、新たに他の領域を確保してFEを再構築する
必要がある。書込み可能であれば、同じ領域に再書込み
すれば良い。

【００８１】また、FIDに問題があった場合には、FID列
のバックアップを参照し、FIDを復旧する(S406)。も
し、FIDが読み出せない理由が物理的破損などその領域
に書込みが出来ない問題であれば、新たに他の領域を確
保してFID列全体を再構築する。そしてFID列の記録領域
を管理するADを更新する。

【００８２】以上説明したとおり、本手法によって壊れ
たFEもしくはFID列に対し、代替として置き換えられる
管理情報のバックアップを提供することが出来る。ま
た、バックアップ情報は各ディレクトリに分散している
ためバックアップ情報が分散し、保護情報としての安全
性が高いといえる。

【００８３】次に、本発明の第３の実施形態について説
明する。図１３に図４のモデルに第３の実施形態を適用
したディレクトリ構成を示す。ROOTディレクトリ下に
「backup」ディレクトリを作成し、「backup」ディレク
トリ下にルートディレクトリ下の全ディレクトリ構成を
複製する。また、ルートディレクトリ下の全ファイルの
管理情報FEに対応するBackup-FEをそれぞれ対応する位
置に作成する。

【００８４】複製されたディレクトリには、前述した理
由により読込専用、システムファイル、隠しファイルの
属性が設定される。このような構造にする事によって、
オリジナルのディレクトリ構造とは独立にバックアップ
のディレクトリ構造を管理することができ、管理情報の
独立性が高まる。

【００８５】図１４に図１３に対応したディスク上の配
置イメージを示す。ルートディレクトリのFID列には「b
ackup」ディレクトリへのFID(501)が追加されている。
また、「backup」ディレクトリのFE(502)以下にはルー
トディレクトリのFE(503)以下の構成とまったく同じ構
成のディレクトリ情報が記録されている。ただし、「ba
ckup」ディレクトリ下にあるファイルを管理するFID(50
4, 505,506)が管理する領域は、ファイルの管理情報FE
(507,508,509)ではなくBackup-FE(510,511,512)にな
る。

【００８６】ここで、第３の実施形態における復旧手順
について説明する。ファイルの復旧手順は第１の実施形
態とほぼ同じで、「backup」ディレクトリの位置がROOT
ディレクトリにあることと、バックアップファイルの探
索がオリジナルのディレクトリ階層に合わせて「backu
p」ディレクトリ以下のディレクトリを辿る点で異な
る。

【００８７】具体的には、問題のあるオリジナルファイ
ルやオリジナルディレクトリのフルパス形式の名前に、
バックアップディレクトリ階層が構築されている「back
up」ディレクトリの名前を付け、目的のバックアップ情
報にアクセスする。

【００８８】例えば、オリジナルファイルのフルパス形
式のファイル名が￥ＭＱ＿ＲＯＯＴ￥ＭＱ＿ＶＩＤＥＯ
￥１００ＳＨＡＲＰ￥ＳＨＲＰ０００１．ＭＱＴの場
合、対応するバックアップ情報には、￥ｂａｃｋｕｐ￥
ＭＱ＿ＲＯＯＴ￥ＭＱ＿ＶＩＤＥＯ￥１００ＳＨＡＲＰ
￥ＳＨＲＰ０００１．ＭＱＴを指定しアクセスする事に
なる。バックアップファイルの探索以外は同様の手順で
復旧が可能なので説明は省略する。

【００８９】次に、ディレクトリの復旧について図１５
のフローチャートを用いて説明する。ディレクトリへの
アクセスに失敗し、そのディレクトリの情報が得られな
かったとする(S501)。アクセス失敗は、例えばディスク
からデータが物理的に読み出せないような場合や、読み
出せたとしても管理情報のDescriptor Tagに記録されて
いるCRC情報やChecksum情報が正しくないことによって
検出を行う。

【００９０】そのルートディレクトリに「backup」ディ
レクトリがない場合(S502)、復旧不能として終了する。
また「backup」ディレクトリ以下に同名のディレクトリ
が見つからない場合(S503)、復旧不能として終了する。
バックアップディレクトリが存在するかどうかは、対象
となる名前（File Identifier）を持つFIDがあるかどう
かで判断する。ディレクトリが見つかった場合は、オリ
ジナルのディレクトリ情報のうちどの情報に問題がある
のかを特定する(S504)。

【００９１】まず、FEに問題があった場合について図１
６を用いて説明する。例えば「MQ#VIDEO」のFE(602)が
壊れたものとする。バックアップ情報の「MQ#VIDEO」の
FE(604)が管理するFID(605)を復旧に用いるが、FID(60
5)のICBが管理している領域はバックアップディレクト
リのFE(606)の記録領域である。そのためFE(605)の情報
を元に単純に復元する事はできない。

【００９２】また、オリジナルのFEの記録領域を管理し
ているFID(603)は参照できない。そのため、バックアッ
プ情報を参照して、新たな領域に「MQ#VIDEO」以下のフ
ァイル及びディレクトリを再構築する必要がある。「MQ
#ROOT」のFE(601)が管理するFID列にFE(607)を管理する
FIDを追加し、「SHRP0001.MQT」と「SHRP0002.MQT」のF
EもBackup-FEを参照しながら再構築する(S505)。

【００９３】次に、FIDに問題があった場合について図
１７を用いて説明する。例えば「MQ#ROOT」のFE（701)
に含まれる「MQ#VIDEO」へのFID（702)が壊れたものと
する。バックアップ情報の「MQ#ROOT」のFE（704)に含
まれる「MQ#VIDEO」へのFID（705)を復旧に用いるが、F
ID（705)のICBが管理している領域はバックアップのFE
（706)の記録領域である。従って、この情報を元に単純
に復元しては不都合がある。また、オリジナルのFE（70
3)の記録領域を管理している情報はない。

【００９４】そのため、バックアップ情報を参照して、
新たな領域に「MQ#VIDEO」以下のファイル及びディレク
トリを再構築する。「MQ#ROOT」のFE（701)が管理するF
ID列にFE（707)を管理するFIDを追加し、「SHRP0001.MQ
T」と「SHRP0002.MQT」のFEもBackup-FEを参照しながら
再構築する(S506)。

【００９５】ここで、第３の実施形態の応用を考える。
図１８に示したディレクトリ構成を用いて説明する。図
１８は図１３のモデルに対し「MQ#VIDEO」ディレクトリ
にファイル「SHRP0003.MQT」を追加したモデルで、この
うち破線内のファイル及びディレクトリに注目する。図
１９にそのディスク上のイメージ図を示す。

【００９６】まず、バックアップディレクトリである
「MQ#VIDEO」のFE(804)に、オリジナルディレクトリで
ある「MQ#VIDEO」が管理するFID列(802)の記録領域の位
置を管理する仕組を導入する。本方式を用いれば、例え
ばオリジナルディレクトリである「MQ#VIDEO」のFE(80
1)が壊れて情報が読み出せなくなった場合に、対応する
バックアップディレクトリのFE(804)にアクセスし、壊
れたFE（801）の代わりのFEを再構築しそのFEが管理す
るFID列の記録領域をバックアップディレクトリFE（80
4）によって得られたFID列(802)の記録領域にすること
で、簡単に復旧することが出来るようになる。

【００９７】ここで、これを実現するためのUDFの管理
情報について例を用いて説明する。FEの管理情報をExte
nded Attributesフィールドを用いて拡張することを考
える。図２１乃至図２２にFE(804)のExtended Attribut
esフィールドに書込む構造規格を示す。Extended Attri
bute Header Descriptor に続いてImplementation UseE
xtended Attributeを記録する。Extended Attribute He
ader Descriptorは他の記述子と同様にDescriptor Tag
を持つ。

【００９８】Implementation Attributes Locationには
Implementation Use Extended Attributeの記録位置へ
のオフセットが記録される。Application Attribute Lo
cationは本発明では使用しない。Attribute Type及びAt
tribute SubtypeにはImplementation Use Extended Att
ributeを示す値が設定される。Attribute Lengthにはex
tended Attributeのサイズが、Implementation Use Len
gthにはImplementationUseフィールドのサイズが記録さ
れる。

【００９９】Implementation Identifierには、本発明
の管理情報が含まれていることを示す識別情報を記録す
る。例えば*UDFBackupPointerのような識別情報を定義
する。このImplementation Identifierによって、本発
明に必要な追加情報が含まれているかどうかを判別する
ことが可能となる。Implementation Use内にAllocation
Descriptorsのフィールドを作成し、Length of Alloca
tion Descriptorsでそのサイズを管理する。

【０１００】そして、Allocation Descriptorsフィール
ドにオリジナルディレクトリのFEが管理しているFID列
(802)の記録領域を管理するADを記録する。この情報は
バックアップディレクトリのFEだけではなく、オリジナ
ルのFEに取り入れても良い。オリジナルディレクトリの
FEが管理するFIDの情報が更新された場合に、対応する
バックアップディレクトリが管理するFIDも整合を保つ
ために更新する必要がある。

【０１０１】オリジナルのFEにこの情報を取り入れる事
によって、更新すべきFID列の記録位置が把握できてい
るために、通常はROOTディレクトリから順番にパスを辿
りアクセスしなければならなかったのが、ダイレクトに
更新すべきFID列にアクセス可能となる。

【０１０２】次に、バックアップディレクトリである
「MQ#VIDEO」のFID(903,904)に、対応するオリジナルデ
ィレクトリである「MQ#VIDEO」の管理するFIDが指し示
すオリジナルファイルのFEの記録領域と同じ情報を管理
する仕組みを導入する。

【０１０３】本方式を用いれば、例えばオリジナルディ
レクトリである「MQ#VIDEO」の管理するFID列(901)が壊
れて情報が読み出せなくなった場合に、バックアップ情
報であるFID(903,904)を用いて読み出せなかったオリジ
ナルファイルのFE(902,905)の記録領域がどこであった
かを把握することが可能である。例えばファイル「SHRP
0003.MQT」を管理するFID(906)が読み出せなかったとす
る。

【０１０４】この場合、対応するバックアップであるFI
D(904)を用いて、FID(906)を復旧する。その際に、FID
(904)に拡張記録された「SHRP0003.MQT」のFE(905)の記
録領域情報を用いて復旧する。その結果、ファイルシス
テムはFE(905)の記録領域にアクセスすることが出来
る。ここで、仮にFE(905)も読み出しが出来ない場合、
前述の手法を使ってBackup-FE（907）からFE(905)を復
旧することが出来、ファイル「SHRP0003.MQT」へのアク
セスを再度、可能にすることが出来るようになる。

【０１０５】この情報はバックアップディレクトリが管
理するFIDだけではなく、オリジナルのFEが管理するFID
に取り入れても良い。この事により、オリジナルファイ
ルを管理するFEに更新が発生した場合に、整合を保つた
めに対応するバックアップファイルの更新すべきFEの記
録位置が把握できているために、通常はROOTディレクト
リから順番にパスを辿りアクセスしなければならなかっ
たのが、ダイレクトに更新すべきFEにアクセス可能とな
る。

【０１０６】ここで、これを実現するためのUDFの管理
情報について例を用いて説明する。FIDの管理情報のImp
lementation Useフィールドを用いて拡張することを考
える。図２３にFID(903,904)のImplementation Useフィ
ールドに書き込む規格の構造を示す。Implementation U
seフィールドの先頭の32バイトはEntity ID構造を持
つ。続けて16バイトのICBフィールドを持つ。このICBフ
ィールドにFE(902,905)の記録領域を記録する。

【０１０７】続いて、図２２のImplementation Use Ext
ended Attributeを拡張してICBフィールドを設けたもの
を図２４に示す。例えばバックアップディレクトリであ
る「100SHARP」を管理するFE(808)内のImplementation
Use Extended Attribute内のICBに、それに対応するオ
リジナルディレクトリである「100SHARP」を管理するFE
(803)の記録位置が書き込まれる。その結果前述のFIDの
Implementation Useフィールドを用いた拡張と同等の効
果を得ることが可能になる。

【０１０８】このようにオリジナルの管理情報に、対応
するバックアップの管理情報の記録位置を管理したり、
バックアップの管理情報に、対応するオリジナルの管理
情報の記録位置を管理したりすることによって問題が発
生した時に復旧処理が容易になったり、オリジナルの管
理情報を更新した際の対応するバックアップの管理情報
を更新する際の処理が容易になる。尚、これらの情報を
UDFのFEやFIDに記録する場合の例を述べたが、それぞれ
個別に導入したり、組み合わせて導入しても良い。

【０１０９】

【発明の効果】以上詳述したとおり、本発明によれば、
ファイルシステムの管理情報のみを２重化する事によっ
て、管理情報に問題があった場合に、例えディスク上の
実体に問題が無くても、その実体にアクセスできなくな
ってしまうという問題を解決することができる。

【０１１０】２重化したバックアップファイルは、通常
のファイルシステムの枠組みで作成されているため、既
存のファイルシステムからアクセスを可能となる。つま
り、バックアップ情報にアクセスするために特別な処理
を行う必要がない事になる。

【０１１１】また、オリジナルファイルの管理情報に問
題が発生した際に、バックアップファイルの情報から復
旧させたりする処理も、既存のファイルシステムの管理
情報を作成や更新するための処理を組み合わせることに
よって実現できるため、実装の負担を減らすことが可能
となる。

【０１１２】さらに、壊れたオリジナルの管理情報に対
し、代替として置き換えられるバックアップの管理情報
を提供することが出来る。また、各バックアップ情報は
各ディレクトリからアクセス可能とすることで、バック
アップ情報が分散し、保護情報としての安全性が高いと
いえる。

【０１１３】また、各管理情報にオリジナルとバックア
ップの双方の記録領域を管理する情報を記録すること
で、通常はROOTディレクトリから順番にパスを辿りアク
セスしなければならなかったのが、ダイレクトに更新す
べき管理情報や復旧するべき管理情報の記録位置にアク
セスすることが可能となる。

【図面の簡単な説明】

【図１】ファイルの実データ共有のディスク配置イメー
ジ図である。

【図２】ファイルの書込みに対するバックアップ手順の
フローチャートである。

【図３】ファイルの更新に対するバックアップ手順のフ
ローチャートである。

【図４】ディレクトリ構造のモデルである。

【図５】ディレクトリ構造のモデルのディスク配置イメ
ージ図である。

【図６】第1の実施形態を適用したディレクトリ構造の
説明図である。

【図７】第1の実施形態の適用のディスク配置イメージ
図である。

【図８】第1の実施形態のファイル作成に対するバック
アップ手順のフローチャートである。

【図９】第1の実施形態に対するファイルの復旧手順の
フローチャートである。

【図１０】第２の実施形態を適用したディレクトリ構造
の説明図である。

【図１１】第２の実施形態の適用のディスク配置イメー
ジ図である。

【図１２】第２の実施形態に対するディレクトリの復旧
手順のフローチャートである。

【図１３】第３の実施形態を適用したディレクトリ構造
の説明図である。

【図１４】第３の実施形態の適用のディスク配置イメー
ジ図である。

【図１５】第３の実施形態に対するディレクトリの復旧
手順のフローチャートである。

【図１６】第３の実施形態におけるFEの読込失敗例の説
明図である。

【図１７】第３の実施形態におけるFIDの読込失敗例の
説明図である。

【図１８】第３の実施形態の応用モデルの説明図であ
る。

【図１９】第３の実施形態の応用モデルのディスク配置
イメージ図である。

【図２０】第３の実施形態の応用モデルのディスク配置
イメージ図である。

【図２１】Extended Attribute Header Descriptorの説
明図である。

【図２２】Implementation Use Extended Attribute(1)
の説明図である。

【図２３】Implementation Use Extended Attribute(2)
の説明図である。

【図２４】Implementation Useの説明図である。

【図２５】UDFファイルシステムにおけるファイルの記
録方式の説明図である。

【図２６】UDFファイルシステムにおけるディレクトリ
の記録方式の説明図である。

【図２７】File Entryの説明図である。

【図２８】Allocation Descriptorの説明図である。

【図２９】Extent Lengthのフォーマットの説明図であ
る。

【図３０】Type of the Extentの説明図である。

【図３１】File Identifier Descriptorの説明図であ
る。

【図３２】Information Control Blockの説明図であ
る。

【図３３】Descriptor Tagの説明図である。

【図３４】UDFファイルシステムにおける記録例の説明
図である。

【符号の説明】

101 ディスク 102 ファイルの実体 103 FE 104,106 AD 105 Backup-FE 401,501 ルートディレクトリ下の「backup」ディレク
トリのFID 402 「MQ#ROOT」ディレクトリ下の「backup」ディレク
トリのFID 403 「MQ#VIDEO」ディレクトリ下の「backup」ディレ
クトリのFID 404 「100SHARP」ディレクトリ下の「backup」ディレ
クトリのFID 405 「MQ#ROOT」のバックアップディレクトリのFE 406,804 「MQ#VIDEO」のバックアップディレクトリのF
E 407 「100SHARP」のバックアップディレクトリのFE 502 ルートのバックアップディレクトリのFE 503 ルートディレクトリのFE 504 「100SHARP」のバックアップディレクトリ下の「S
HRP0001.MQT」のFID 505 「100SHARP」のバックアップディレクトリ下の「S
HRP0002.MQT」のFID 506 ルートのバックアップディレクトリ下の「SMAS000
0.SMF」のFID 507 「SHRP0001.MQT」のFE 508 「SHRP0002.MQT」のFE 509 「SMAS0000.SMF」のFE 510 「SHRP0001.MQT」のBackup-FE 511 「SHRP0002.MQT」のBackup-FE 512 「SMAS0000.SMF」のBackup-FE 601,701 「MQ#ROOT」ディレクトリ 602 読出失敗した「MQ#VIDEO」ディレクトリ 603 「MQ#VIDEO」ディレクトリ下へのエクステント 604,706 「MQ#VIDEO」のバックアップディレクトリ 605 「MQ#VIDEO」バックアップディレクトリ下へのエ
クステント 606 「100SHARP」のバックアップディレクトリ 607,707 新しく作られた「MQ#VIDEO」ディレクトリ 608,708 新しく作られた「SHRP0001.MQT」 609,709 新しく作られた「SHRP0002.MQT」 702 読出失敗した「MQ#VIDEO」ディレクトリ下へのエ
クステント 703 「MQ#VIDEO」ディレクトリ 704 「MQ#ROOT」のバックアップディレクトリ 705 「MQ#ROOT」バックアップディレクトリ下へのエク
ステント 801 「MQ#VIDEO」ディレクトリのFE 802 「MQ#VIDEO」ディレクトリ下のFID 803 「100SHARP」ディレクトリのFE 805 「MQ#VIDEO」のバックアップディレクトリ下の「1
00SHARP」のFID 806 「MQ#VIDEO」のバックアップディレクトリ下の「S
HRP0003.MQT」のFID 807 ファイル「SHRP0003.MQT」のFE 808 「100SHARP」のバックアップディレクトリのFE

フロントページの続き (72)発明者 山口 孝好 大阪府大阪市阿倍野区長池町22番22号 シ ャープ株式会社内 Ｆターム(参考） 5B082 DC02 DC05 5D044 CC04 DE02 DE48 DE52 5D110 AA12 DA03 DA11 DB05 DB13 DF01

Claims (13)

【特許請求の範囲】
1. 【請求項１】 ディスク上にファイルの実体と、該ファ
   イルの実体の記録領域を管理する第１の管理情報とを記
   録するファイルシステムにおいて、 前記ファイルの実体の記録領域を管理する第２の管理情
   報を作成して、該第２の管理情報を前記第１の管理情報
   とは異なる領域に記録し、 前記第１及び第２の管理情報によって、前記ファイルの
   実体の記録領域を共有して管理し、 前記第１の管理情報を参照して読み出すことができるフ
   ァイルをオリジナルファイルと見なし、前記第２の管理
   情報を参照して読み出すことができるファイルをバック
   アップファイルと見なすことを特徴とするディスク管理
   方法。
2. 【請求項２】 前記請求項１に記載のディスク管理方法
   において、 前記オリジナルファイルが含まれる第１のディレクトリ
   の下に、第２のディレクトリを作成し、 前記バックアップファイルが前記第２のディレクトリ下
   に含まれるように、前記第２の管理情報を作成すること
   を特徴とするディスク管理方法。
3. 【請求項３】 前記請求項１または２に記載のディスク
   管理方法において、 ファイルの更新が行われた場合に、該ファイルの更新に
   合わせて、前記第２の管理情報も更新することを特徴と
   するディスク管理方法。
4. 【請求項４】 前記請求項１乃至３のいずれかに記載の
   ディスク管理方法において、 ファイルが読み出せなくなった場合に、前記第２の管理
   情報にアクセスし、該ファイルを再構築することを特徴
   とするディスク管理方法。
5. 【請求項５】 前記請求項１乃至４のいずれかに記載の
   ディスク管理方法において、 任意の第３のディレクトリの下に、第４のディレクトリ
   を作成し、 前記第３のディレクトリの下に作成されている第５のデ
   ィレクトリを、前記第４のディレクトリの下に複製し
   て、該複製されたディレクトリを第６のディレクトリと
   し、 前記複製元の第５のディレクトリと前記第６のディレク
   トリとによって、前記第５のディレクトリ下に含まれる
   ファイルやディレクトリの管理情報を共有することを特
   徴とするディスク管理方法。
6. 【請求項６】 前記請求項１乃至４のいずれかに記載の
   ディスク管理方法において、 任意の第７のディレクトリ下に、第８のディレクトリを
   作成し、 前記第７のディレクトリ下に作成されている全ディレク
   トリ構造を、前記第８のディレクトリ下に複製し、 前記オリジナルファイルに対応するバックアップファイ
   ルを、第８のディレクトリ下に含まれる各ディレクトリ
   のそれぞれの下に作成することを特徴とするディスク管
   理方法。
7. 【請求項７】 前記請求項５または６に記載のディスク
   管理方法において、 ディレクトリの更新が行われた場合に、該ディレクトリ
   の更新に合わせて、前記複製されたディレクトリ情報も
   更新することを特徴とするディスク管理方法。
8. 【請求項８】 前記請求項５乃至７に記載のディスク管
   理方法において、 ディレクトリが読み出せなくなった場合に、前記複製さ
   れたディレクトリにアクセスし、該ディレクトリを再構
   築することを特徴とするディスク管理方法。
9. 【請求項９】 前記請求項１乃至８のいずれかに記載の
   ディスク管理方法において、 オリジナルの管理情報に、バックアップの管理情報によ
   って管理される記録領域情報を記録することを特徴とす
   るディスク管理方法。
10. 【請求項１０】 前記請求項１乃至９のいずれかに記載
    のディスク管理方法において、 バックアップの管理情報に、オリジナルの管理情報によ
    って管理される記録領域情報を記録することを特徴とす
    るディスク管理方法。
11. 【請求項１１】 前記請求項９または１０に記載のディ
    スク管理方法において、 前記オリジナルの管理情報は、複製元のディレクトリの
    管理情報であり、 前記バックアップの管理情報は、複製されたディレクト
    リの管理情報であることを特徴とするディスク管理方
    法。
12. 【請求項１２】 前記請求項９乃至１１のいずれかに記
    載のディスク管理方法において、 前記管理情報が、UDF(Universal Disk Format)における
    FE(File Entry)であることを特徴とするディスク管理方
    法。
13. 【請求項１３】 前記請求項９乃至１１のいずれかに記
    載のディスク管理方法において、 前記管理情報が、UDF(Universal Disk Format)における
    FID(File IdentifierDescriptor)であることを特徴とす
    るディスク管理方法。