JP2002082825A - ファイル管理方法 - Google Patents
ファイル管理方法Info
- Publication number
- JP2002082825A JP2002082825A JP2001170443A JP2001170443A JP2002082825A JP 2002082825 A JP2002082825 A JP 2002082825A JP 2001170443 A JP2001170443 A JP 2001170443A JP 2001170443 A JP2001170443 A JP 2001170443A JP 2002082825 A JP2002082825 A JP 2002082825A
- Authority
- JP
- Japan
- Prior art keywords
- file
- history
- information
- recording
- recorded
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
- G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
- G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
- G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
- G11B27/32—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier
- G11B27/327—Table of contents
- G11B27/329—Table of contents on a disc [VTOC]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
- G11B20/10—Digital recording or reproducing
- G11B20/12—Formatting, e.g. arrangement of data block or words on the record carriers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1435—Saving, restoring, recovering or retrying at system level using file system or storage system metadata
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F2003/0697—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers device management, e.g. handlers, drivers, I/O schedulers
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B2220/00—Record carriers by type
- G11B2220/20—Disc-shaped record carriers
Abstract
(57)【要約】
【課題】 ファイルシステムにおいて、管理領域と実デ
ータ領域を予め分離しておき、管理領域を２重化するこ
とでバックアップを行う場合、逆に管理領域及びバック
アップ用の管理領域を予め確保しておく必要があるた
め、管理領域の大きさから管理できる最大ファイル数の
制限がでてきてしまう。また、管理領域とデータ領域が
同じ領域に記録されていくようなファイルシステムにお
いて、管理領域という概念はないので、管理領域ごと２
重化するという手法は適用できない。 【解決手段】 前記記録媒体へのファイルの追加、変
更、削除のアクションが行われる毎に、当該ファイルの
ファイル識別子と当該ファイルの記録媒体上の記録位置
情報及びファイルのアクション種別を対応づけた履歴情
報を順次作成し、当該履歴情報を前記ファイル及び管理
情報の記録領域とは異なる履歴テーブル領域に履歴情報
の作成順に記録することで課題を解決する。
ータ領域を予め分離しておき、管理領域を２重化するこ
とでバックアップを行う場合、逆に管理領域及びバック
アップ用の管理領域を予め確保しておく必要があるた
め、管理領域の大きさから管理できる最大ファイル数の
制限がでてきてしまう。また、管理領域とデータ領域が
同じ領域に記録されていくようなファイルシステムにお
いて、管理領域という概念はないので、管理領域ごと２
重化するという手法は適用できない。 【解決手段】 前記記録媒体へのファイルの追加、変
更、削除のアクションが行われる毎に、当該ファイルの
ファイル識別子と当該ファイルの記録媒体上の記録位置
情報及びファイルのアクション種別を対応づけた履歴情
報を順次作成し、当該履歴情報を前記ファイル及び管理
情報の記録領域とは異なる履歴テーブル領域に履歴情報
の作成順に記録することで課題を解決する。
Description
【０００１】
【発明の属する技術分野】本発明は、記録媒体における
ファイルのバックアップ等に関するファイル管理方法に
関するものである。
ファイルのバックアップ等に関するファイル管理方法に
関するものである。
【０００２】
【従来の技術】ＰＣ用途やＡＶ用途など様々な用途でデ
ィスク媒体にデータを記録する場合、論理ファイルシス
テムを用いる事が一般的である。論理ファイルシステム
を用いる事によって、記録したデータをファイルとして
管理し、ディレクトリ階層を構築する事が可能となり管
理が容易となる。論理ファイルシステムとしては、広く
普及しているＦＡＴ方式やＤＶＤなどで導入されている
ＵＤＦ（Ｕｎｉｖｅｒｓａｌ Ｄｉｓｋ Ｆｏｒｍａ
ｔ）などが挙げられる。
ィスク媒体にデータを記録する場合、論理ファイルシス
テムを用いる事が一般的である。論理ファイルシステム
を用いる事によって、記録したデータをファイルとして
管理し、ディレクトリ階層を構築する事が可能となり管
理が容易となる。論理ファイルシステムとしては、広く
普及しているＦＡＴ方式やＤＶＤなどで導入されている
ＵＤＦ（Ｕｎｉｖｅｒｓａｌ Ｄｉｓｋ Ｆｏｒｍａ
ｔ）などが挙げられる。
【０００３】論理ファイルシステムとは、ディスクに記
録されたデータに対してデータを識別するための情報
と、データが記録されたディスク上の位置情報などを管
理情報としてディスクに記録し、それらの情報にアクセ
スする事によってファイルアクセスを可能とする仕組み
の事である。例えば、論理ファイルシステムの管理情報
には、ファイル名、そのファイルに関する作成日時、フ
ァイルサイズ、状態を示す情報などの属性情報、対応す
る実データが記録されているディスク上の位置情報など
が記録されている。ＦＡＴやＵＤＦなどと言った様々な
種類の論理ファイルシステムが存在するが、これらの管
理情報の構成や管理する属性情報が異なるだけで、ファ
イル名あるいはそれに準ずる情報からディスク上の目的
のデータにアクセスができると言った意味では同じ目的
のためのものである。
録されたデータに対してデータを識別するための情報
と、データが記録されたディスク上の位置情報などを管
理情報としてディスクに記録し、それらの情報にアクセ
スする事によってファイルアクセスを可能とする仕組み
の事である。例えば、論理ファイルシステムの管理情報
には、ファイル名、そのファイルに関する作成日時、フ
ァイルサイズ、状態を示す情報などの属性情報、対応す
る実データが記録されているディスク上の位置情報など
が記録されている。ＦＡＴやＵＤＦなどと言った様々な
種類の論理ファイルシステムが存在するが、これらの管
理情報の構成や管理する属性情報が異なるだけで、ファ
イル名あるいはそれに準ずる情報からディスク上の目的
のデータにアクセスができると言った意味では同じ目的
のためのものである。
【０００４】このような論理ファイルシステムを用いた
ディスクを通常使用している場合には全く問題は無い
が、場合によってディスクに記録した情報が読み出せな
いと言った事が起こる可能性がある。例えば、何らかの
ショックによってディスク自体に傷が付いてしまった
り、書き込み中にショックが加わり本来書き込むべき箇
所でない所に書き込みを行ない記録内容を書き変えてし
まったり、リムーバブルディスクの場合はディスクの表
面に汚れが付着してしまったりする事によって発生する
事が考えられる。
ディスクを通常使用している場合には全く問題は無い
が、場合によってディスクに記録した情報が読み出せな
いと言った事が起こる可能性がある。例えば、何らかの
ショックによってディスク自体に傷が付いてしまった
り、書き込み中にショックが加わり本来書き込むべき箇
所でない所に書き込みを行ない記録内容を書き変えてし
まったり、リムーバブルディスクの場合はディスクの表
面に汚れが付着してしまったりする事によって発生する
事が考えられる。
【０００５】ディスクに書き込む前に問題のある箇所が
発見できた場合には、ディスクの問題の箇所の代わりに
代替領域に記録するディフェクトマネジメント機能を利
用する事によって問題を回避できるが、情報を書いた後
に問題が発生すると、その情報をディスクから読み出せ
なくなってしまい問題がある。記録したデータ自体が読
みだせない事も問題であるが、前述した論理ファイルシ
ステムの管理情報がディスクから読みだせない事の方が
問題となる。仮にあるファイルにアクセスするための論
理ファイルシステムの管理情報が何らかの理由によって
読み出せないと、例えディスク上のデータに影響が無く
ても、対応するデータがディスクのどこに記録されてい
たかが不明となるため、データにアクセスできなくなっ
てしまう。
発見できた場合には、ディスクの問題の箇所の代わりに
代替領域に記録するディフェクトマネジメント機能を利
用する事によって問題を回避できるが、情報を書いた後
に問題が発生すると、その情報をディスクから読み出せ
なくなってしまい問題がある。記録したデータ自体が読
みだせない事も問題であるが、前述した論理ファイルシ
ステムの管理情報がディスクから読みだせない事の方が
問題となる。仮にあるファイルにアクセスするための論
理ファイルシステムの管理情報が何らかの理由によって
読み出せないと、例えディスク上のデータに影響が無く
ても、対応するデータがディスクのどこに記録されてい
たかが不明となるため、データにアクセスできなくなっ
てしまう。
【０００６】ＰＣ用途で使用しているディスクでは、こ
のような事が起こる可能性は稀である。これは、ＰＣ用
途のドライブが物理的に安定した環境で使用されている
ことが多いためである。一方、ＡＶ用途でリムーバブル
ディスクを記録媒体としたビデオカメラなどを考えた場
合、必ずしも物理的に安定した環境で使用されるとは限
らない。ビデオカメラなので手に持って撮影するが、走
りながらの撮影や、何かにぶつかったりとディスクにデ
ータを記録している最中にショックが加わる事も考えら
れる。このように、ＰＣ用途で使用する場合と比較して
苛酷な状況で使用される事が考えられ、前述したような
予期せねディスクからデータが読み出せないと言った状
況が発生する確率が高くなる。
のような事が起こる可能性は稀である。これは、ＰＣ用
途のドライブが物理的に安定した環境で使用されている
ことが多いためである。一方、ＡＶ用途でリムーバブル
ディスクを記録媒体としたビデオカメラなどを考えた場
合、必ずしも物理的に安定した環境で使用されるとは限
らない。ビデオカメラなので手に持って撮影するが、走
りながらの撮影や、何かにぶつかったりとディスクにデ
ータを記録している最中にショックが加わる事も考えら
れる。このように、ＰＣ用途で使用する場合と比較して
苛酷な状況で使用される事が考えられ、前述したような
予期せねディスクからデータが読み出せないと言った状
況が発生する確率が高くなる。
【０００７】このような、論理ファイルシステムの管理
情報が読み出せない事によって、データにアクセス出来
なくなってしまう問題を解決するためには、論理ファイ
ルシステムの管理情報を多重する事が考えられる。つま
り、ディスク上に論理ファイルシステムの管理情報を多
重する事によって、万が一ある管理情報が読み出せなく
なった場合でも多重化してあるバックアップの管理情報
を元に、データへのアクセスを可能とする事ができる。
情報が読み出せない事によって、データにアクセス出来
なくなってしまう問題を解決するためには、論理ファイ
ルシステムの管理情報を多重する事が考えられる。つま
り、ディスク上に論理ファイルシステムの管理情報を多
重する事によって、万が一ある管理情報が読み出せなく
なった場合でも多重化してあるバックアップの管理情報
を元に、データへのアクセスを可能とする事ができる。
【０００８】図３５にその様子を示す。このファイルシ
ステムでは、ファイルシステムの管理情報とデータを記
録する領域を区別し、それぞれがディスク上の対応する
領域に記録される。ファイルシステムの管理情報が実際
にはファイルが記録される領域とは別の所定の領域に記
録されるので、管理領域は必ずこの領域内に記録される
ことになる。よって、この管理情報記録領域と全く同じ
状態のバックアップ用の領域を用意する事によって管理
情報を多重する事が可能となる。
ステムでは、ファイルシステムの管理情報とデータを記
録する領域を区別し、それぞれがディスク上の対応する
領域に記録される。ファイルシステムの管理情報が実際
にはファイルが記録される領域とは別の所定の領域に記
録されるので、管理領域は必ずこの領域内に記録される
ことになる。よって、この管理情報記録領域と全く同じ
状態のバックアップ用の領域を用意する事によって管理
情報を多重する事が可能となる。
【０００９】
【発明が解決しようとする課題】上記した図３５に示す
ように、管理領域と実データ領域を予め分離しておき、
管理領域を２重化することでバックアップを行う場合、
逆に管理領域及びバックアップ用の管理領域を予め確保
しておく必要があるため、管理領域の大きさから管理で
きる最大ファイル数の制限がでてきてしまうという問題
がある。
ように、管理領域と実データ領域を予め分離しておき、
管理領域を２重化することでバックアップを行う場合、
逆に管理領域及びバックアップ用の管理領域を予め確保
しておく必要があるため、管理領域の大きさから管理で
きる最大ファイル数の制限がでてきてしまうという問題
がある。
【００１０】また、上記したＦＡＴやＵＤＦファイルシ
ステムは図３４に示すように管理領域とデータ領域が同
じ領域に記録されていくことになる。このようなファイ
ルシステムにおいて、管理領域という概念はないので、
管理領域ごと２重化するという手法は適用できない。
ステムは図３４に示すように管理領域とデータ領域が同
じ領域に記録されていくことになる。このようなファイ
ルシステムにおいて、管理領域という概念はないので、
管理領域ごと２重化するという手法は適用できない。
【００１１】また、ファイルシステムの管理情報はディ
レクトリ階層を構成するように管理されており、各管理
情報の間にはこのディレクトリ階層に従った結び付き
（ディスク上のアドレス位置でリンクされている）があ
るため、単純に管理情報を２重化することは容易ではな
い。例えば、ディレクトリを管理する管理情報にはその
ディレクトリ内に定義されるファイルやディレクトリを
管理する管理情報が記録されているアドレス位置が記述
されている。よって、これらの論理ファイルシステムの
管理情報を所定のバックアップ領域に単純にコピーする
という方法で多重化する場合、管理情報間の連結情報で
あるディスク上のアドレスを、バックアップ領域内に記
録する管理情報の記録位置に応じて変更しなければなら
ない。
レクトリ階層を構成するように管理されており、各管理
情報の間にはこのディレクトリ階層に従った結び付き
（ディスク上のアドレス位置でリンクされている）があ
るため、単純に管理情報を２重化することは容易ではな
い。例えば、ディレクトリを管理する管理情報にはその
ディレクトリ内に定義されるファイルやディレクトリを
管理する管理情報が記録されているアドレス位置が記述
されている。よって、これらの論理ファイルシステムの
管理情報を所定のバックアップ領域に単純にコピーする
という方法で多重化する場合、管理情報間の連結情報で
あるディスク上のアドレスを、バックアップ領域内に記
録する管理情報の記録位置に応じて変更しなければなら
ない。
【００１２】このような構成であると、ファイルの作
成、変更、削除のタイミングで、実際の管理情報を更新
するとともに、バックアップの管理情報のアドレスの更
新処理を行う必要があり、バックアップ作成に多くの処
理が必要となってしまう。
成、変更、削除のタイミングで、実際の管理情報を更新
するとともに、バックアップの管理情報のアドレスの更
新処理を行う必要があり、バックアップ作成に多くの処
理が必要となってしまう。
【００１３】本願は上記したような課題を解決するもの
であり、ファイルに関する作成、変更、削除、ディレク
トリに関する作成、削除などといったイベントが発生し
た場合、そのファイル或いはディレクトリの識別情報
と、当該ファイルのディスク上での位置あるいはディレ
クトリ情報を履歴情報として作成し、当該履歴情報を履
歴テーブル領域に記録することで、管理情報が正常に読
み出せない場合においても、容易にファイルを読み出す
ことを可能とし、また、バックアップ作成時に複雑な処
理を行う必要がない。
であり、ファイルに関する作成、変更、削除、ディレク
トリに関する作成、削除などといったイベントが発生し
た場合、そのファイル或いはディレクトリの識別情報
と、当該ファイルのディスク上での位置あるいはディレ
クトリ情報を履歴情報として作成し、当該履歴情報を履
歴テーブル領域に記録することで、管理情報が正常に読
み出せない場合においても、容易にファイルを読み出す
ことを可能とし、また、バックアップ作成時に複雑な処
理を行う必要がない。
【００１４】
【課題を解決するための手段】本願の第１の発明によれ
ば、入力されたデータをファイルとして記録媒体に記録
し、各ファイルを少なくとも該ファイルの記録媒体上に
おける記録位置情報を含む管理情報により管理する記録
装置におけるファイル管理方法であって、前記記録媒体
へのファイルの追加、変更、削除のアクションが行われ
る毎に、当該ファイルのファイル識別情報と当該ファイ
ルの記録媒体上の記録位置情報及びファイルのアクショ
ン種別を対応づけた履歴情報を順次作成し、当該履歴情
報を履歴テーブル領域に履歴情報の作成順に記録するこ
とにより上記課題を解決する。
ば、入力されたデータをファイルとして記録媒体に記録
し、各ファイルを少なくとも該ファイルの記録媒体上に
おける記録位置情報を含む管理情報により管理する記録
装置におけるファイル管理方法であって、前記記録媒体
へのファイルの追加、変更、削除のアクションが行われ
る毎に、当該ファイルのファイル識別情報と当該ファイ
ルの記録媒体上の記録位置情報及びファイルのアクショ
ン種別を対応づけた履歴情報を順次作成し、当該履歴情
報を履歴テーブル領域に履歴情報の作成順に記録するこ
とにより上記課題を解決する。
【００１５】本願の第２の発明によれば、入力されたデ
ータをファイルとして記録媒体に記録し、各ファイルを
少なくとも該ファイルの記録媒体上における記録位置情
報を含む管理情報により管理する記録装置におけるファ
イル管理方法であって、前記履歴情報を前記ファイル及
び管理情報の記録領域とは異なる履歴テーブル領域に履
歴情報の作成順に記録することにより上記課題を解決す
る。
ータをファイルとして記録媒体に記録し、各ファイルを
少なくとも該ファイルの記録媒体上における記録位置情
報を含む管理情報により管理する記録装置におけるファ
イル管理方法であって、前記履歴情報を前記ファイル及
び管理情報の記録領域とは異なる履歴テーブル領域に履
歴情報の作成順に記録することにより上記課題を解決す
る。
【００１６】本願の第３の発明によれば、入力されたデ
ータをファイルとして記録媒体に記録し、各ファイルを
少なくとも該ファイルの記録媒体上における記録位置情
報を含む管理情報により管理する記録装置におけるファ
イル管理方法であって、ファイルとして管理される、前
記履歴情報を記録する履歴テーブル領域に履歴情報の作
成順に記録することにより上記課題を解決する。
ータをファイルとして記録媒体に記録し、各ファイルを
少なくとも該ファイルの記録媒体上における記録位置情
報を含む管理情報により管理する記録装置におけるファ
イル管理方法であって、ファイルとして管理される、前
記履歴情報を記録する履歴テーブル領域に履歴情報の作
成順に記録することにより上記課題を解決する。
【００１７】本願の第４の発明によれば、入力されたデ
ータをファイルとして記録媒体に記録し、各ファイルを
少なくとも該ファイルの記録媒体上における記録位置情
報を含む管理情報により管理する記録装置におけるファ
イル管理方法であって、前記記録媒体へのファイルの追
加、変更、削除のアクションが行われる毎に、前記履歴
テーブル領域に記録する前記ファイル識別情報として、
当該ファイルのファイル名あるいはファイルＩＤを含む
ことにより上記課題を解決する。
ータをファイルとして記録媒体に記録し、各ファイルを
少なくとも該ファイルの記録媒体上における記録位置情
報を含む管理情報により管理する記録装置におけるファ
イル管理方法であって、前記記録媒体へのファイルの追
加、変更、削除のアクションが行われる毎に、前記履歴
テーブル領域に記録する前記ファイル識別情報として、
当該ファイルのファイル名あるいはファイルＩＤを含む
ことにより上記課題を解決する。
【００１８】本願の第５の発明によれば、入力されたデ
ータをファイルとして記録媒体に記録し、各ファイルを
少なくとも該ファイルの記録媒体上における記録位置情
報を含む管理情報により管理する記録装置におけるファ
イル管理方法であって、前記記録媒体へのファイルの追
加、変更、削除のアクションが行われる毎に、前記履歴
テーブル領域に記録する前記ファイル識別情報として、
当該ファイルを管理する管理情報の記録媒体上の記録位
置情報を含むことにより上記課題を解決する。
ータをファイルとして記録媒体に記録し、各ファイルを
少なくとも該ファイルの記録媒体上における記録位置情
報を含む管理情報により管理する記録装置におけるファ
イル管理方法であって、前記記録媒体へのファイルの追
加、変更、削除のアクションが行われる毎に、前記履歴
テーブル領域に記録する前記ファイル識別情報として、
当該ファイルを管理する管理情報の記録媒体上の記録位
置情報を含むことにより上記課題を解決する。
【００１９】本願の第６の発明によれば、入力されたデ
ータをファイルとして記録媒体に記録し、各ファイルを
少なくとも該ファイルの記録媒体上における記録位置情
報を含む管理情報により管理する記録装置におけるファ
イル管理方法であって、前記記録媒体へのファイルの追
加、変更、削除のアクションが行われる毎に、前記履歴
テーブル領域に記録する前記履歴情報として、当該ファ
イルを管理する管理情報の記録媒体上の記録位置情報を
含むことにより上記課題を解決する。
ータをファイルとして記録媒体に記録し、各ファイルを
少なくとも該ファイルの記録媒体上における記録位置情
報を含む管理情報により管理する記録装置におけるファ
イル管理方法であって、前記記録媒体へのファイルの追
加、変更、削除のアクションが行われる毎に、前記履歴
テーブル領域に記録する前記履歴情報として、当該ファ
イルを管理する管理情報の記録媒体上の記録位置情報を
含むことにより上記課題を解決する。
【００２０】本願の第７の発明によれば、前記記録媒体
へのファイルの追加、変更、削除のアクションが行われ
る毎に、前記履歴情報を記録装置のメモリ上に順次作成
し、前記記録装置において、前記記録媒体の取り出し指
示が行われた場合、当該履歴情報を該記録媒体上の履歴
テーブル領域に記録することにより上記課題を解決す
る。
へのファイルの追加、変更、削除のアクションが行われ
る毎に、前記履歴情報を記録装置のメモリ上に順次作成
し、前記記録装置において、前記記録媒体の取り出し指
示が行われた場合、当該履歴情報を該記録媒体上の履歴
テーブル領域に記録することにより上記課題を解決す
る。
【００２１】本願の第８の発明によれば、前記記録媒体
へのファイルの追加、変更、削除のアクションが行われ
る毎に、前記履歴情報を記録装置のメモリ上に順次作成
し、前記記録装置において、メモリへの電源供給切断指
示が行われた場合、当該履歴情報を該記録媒体上の履歴
テーブル領域に記録することにより上記課題を解決す
る。
へのファイルの追加、変更、削除のアクションが行われ
る毎に、前記履歴情報を記録装置のメモリ上に順次作成
し、前記記録装置において、メモリへの電源供給切断指
示が行われた場合、当該履歴情報を該記録媒体上の履歴
テーブル領域に記録することにより上記課題を解決す
る。
【００２２】本願の第９の発明によれば、履歴テーブル
の履歴確認指示に基づいて、前記履歴テーブル領域に記
録された履歴情報のうち、所定のファイル識別情報を有
する履歴情報のみを抽出することにより上記課題を解決
する。
の履歴確認指示に基づいて、前記履歴テーブル領域に記
録された履歴情報のうち、所定のファイル識別情報を有
する履歴情報のみを抽出することにより上記課題を解決
する。
【００２３】本願の第１０の発明によれば、履歴テーブ
ルの再構築指示に基づいて、前記履歴テーブル領域に記
録された履歴情報のうち、同一のファイル識別情報を有
する履歴情報を、当該履歴情報のアクション種別に応じ
て一つの履歴情報に統合し、履歴テーブル領域を縮小す
ることにより上記課題を解決する。
ルの再構築指示に基づいて、前記履歴テーブル領域に記
録された履歴情報のうち、同一のファイル識別情報を有
する履歴情報を、当該履歴情報のアクション種別に応じ
て一つの履歴情報に統合し、履歴テーブル領域を縮小す
ることにより上記課題を解決する。
【００２４】本願の第１１の発明によれば、前記管理情
報は、ディレクトリの管理情報を含み、前記記録媒体へ
のディレクトリ情報の追加、削除のアクションが行われ
る毎に、当該ディレクトリの識別情報とアクション種別
を対応づけた履歴情報を順次作成し、当該履歴情報を履
歴テーブル領域に順次追記記録することにより上記課題
を解決する。
報は、ディレクトリの管理情報を含み、前記記録媒体へ
のディレクトリ情報の追加、削除のアクションが行われ
る毎に、当該ディレクトリの識別情報とアクション種別
を対応づけた履歴情報を順次作成し、当該履歴情報を履
歴テーブル領域に順次追記記録することにより上記課題
を解決する。
【００２５】本願の第１２の発明によれば、前記履歴情
報を履歴テーブル領域に順次追記記録する際、前記履歴
テーブル領域の後方から前方方向へ順番に記録すること
により上記課題を解決する。
報を履歴テーブル領域に順次追記記録する際、前記履歴
テーブル領域の後方から前方方向へ順番に記録すること
により上記課題を解決する。
【００２６】本願の第１３の発明によれば、ファイルの
読出し指示に基づいて、前記管理情報を検索して、ファ
イルの読出しを行う際、当該ファイルの管理情報が読み
出せない場合、前記履歴テーブル領域から、当該ファイ
ルのファイル識別情報を有する最新の履歴情報を読出
し、当該履歴情報に基づいてファイルの読出しを行うこ
とにより上記課題を解決する。
読出し指示に基づいて、前記管理情報を検索して、ファ
イルの読出しを行う際、当該ファイルの管理情報が読み
出せない場合、前記履歴テーブル領域から、当該ファイ
ルのファイル識別情報を有する最新の履歴情報を読出
し、当該履歴情報に基づいてファイルの読出しを行うこ
とにより上記課題を解決する。
【００２７】本願の第１４の発明によれば、管理情報の
再構築指示に基づいて、前記履歴テーブル領域から履歴
情報を読みだし、当該履歴情報に基づいて、管理情報を
生成し、当該管理情報を記録媒体に記録することにより
上記課題を解決する。
再構築指示に基づいて、前記履歴テーブル領域から履歴
情報を読みだし、当該履歴情報に基づいて、管理情報を
生成し、当該管理情報を記録媒体に記録することにより
上記課題を解決する。
【００２８】
【発明の実施の形態】以下、本発明のディスク管理方法
に関する実施形態について、図１乃至図３４とともに詳
細について説明する。本実施例は、ディスク装置とし
て、ＡＶ記録再生を目的としたディスクを用いた携帯型
のビデオカメラやビデオデッキ、ＰＣに接続された外部
記憶装置などを想定するものである。ディスク媒体は、
リムーバブルディスクが好ましいが、ハードディスクな
どの据え付け型であっても構わない。また、説明の都合
上ディスクに用いる論理ファイルシステムとしてＯＳＴ
Ａ（Ｏｐｔｉｃａｌ Ｓｔｏｒａｇｅ Ｔｅｃｈｎｏｌ
ｏｇｙ Ａｓｓｏｃｉａｔｉｏｎ）の規格であるＵＤＦ
（Ｕｎｉｖｅｒｓａｌ Ｄｉｓｋ Ｆｏｒｍａｔ）を想
定するが、その他の汎用論理ファイルシステムであって
も構わない。
に関する実施形態について、図１乃至図３４とともに詳
細について説明する。本実施例は、ディスク装置とし
て、ＡＶ記録再生を目的としたディスクを用いた携帯型
のビデオカメラやビデオデッキ、ＰＣに接続された外部
記憶装置などを想定するものである。ディスク媒体は、
リムーバブルディスクが好ましいが、ハードディスクな
どの据え付け型であっても構わない。また、説明の都合
上ディスクに用いる論理ファイルシステムとしてＯＳＴ
Ａ（Ｏｐｔｉｃａｌ Ｓｔｏｒａｇｅ Ｔｅｃｈｎｏｌ
ｏｇｙ Ａｓｓｏｃｉａｔｉｏｎ）の規格であるＵＤＦ
（Ｕｎｉｖｅｒｓａｌ Ｄｉｓｋ Ｆｏｒｍａｔ）を想
定するが、その他の汎用論理ファイルシステムであって
も構わない。
【００２９】一般的なディスク装置の構成を図１に示
す。データ入力出力部１はカメラなどから入力される映
像信号を取り込んだり、再生するデータをモニタ等に出
力したりする。データ処理部２は、例えばＭＰＥＧ符号
をエンコードしたり、デコードしたりする信号処理等を
行う処理部であり、処理されたデータはメモリ３に格納
される。データを記録する場合は、ディスク制御部５に
おいて、ディスク６を制御しディスク上の目的の箇所に
データが記録され、再生時には、ディスク６を制御しデ
ィスク上の目的の箇所からデータが読み出されてメモリ
３に格納される。各処理部はシステム制御部４によって
制御される。
す。データ入力出力部１はカメラなどから入力される映
像信号を取り込んだり、再生するデータをモニタ等に出
力したりする。データ処理部２は、例えばＭＰＥＧ符号
をエンコードしたり、デコードしたりする信号処理等を
行う処理部であり、処理されたデータはメモリ３に格納
される。データを記録する場合は、ディスク制御部５に
おいて、ディスク６を制御しディスク上の目的の箇所に
データが記録され、再生時には、ディスク６を制御しデ
ィスク上の目的の箇所からデータが読み出されてメモリ
３に格納される。各処理部はシステム制御部４によって
制御される。
【００３０】このようなディスク装置における論理ファ
イルシステムで、論理ファイルシステムの管理情報とデ
ータを記録する領域が明確にわかれている場合、管理情
報の領域を多重する事によって容易に管理情報のバック
アップを持つ事が可能である。しかしながら、論理ファ
イルシステムの管理情報とデータを記録する領域が明確
に分かれていない場合、つまり論理ファイルシステムの
管理情報とデータが同一のディスク空間に記録される場
合は、管理情報のバックアップを容易に持つ事はできな
い。
イルシステムで、論理ファイルシステムの管理情報とデ
ータを記録する領域が明確にわかれている場合、管理情
報の領域を多重する事によって容易に管理情報のバック
アップを持つ事が可能である。しかしながら、論理ファ
イルシステムの管理情報とデータを記録する領域が明確
に分かれていない場合、つまり論理ファイルシステムの
管理情報とデータが同一のディスク空間に記録される場
合は、管理情報のバックアップを容易に持つ事はできな
い。
【００３１】管理情報とデータを記録する領域が明確に
分かれている場合とは異なり、ディスクに分散している
管理情報をある特定の大きさのバックアップ用領域に記
録する事ができないからである。これは、ディレクトリ
の管理情報にそのディレクトリに含まれるファイルやデ
ィレクトリの管理情報が記録されているディスク上のア
ドレスが記述されており、バックアップ領域に管理情報
をバックアップする場合、論理ファイルシステムの管理
情報間の連結情報であるディスク上のアドレスを、バッ
クアップ領域内の管理情報の記録位置に応じて変更しな
ければならない事を意味する。
分かれている場合とは異なり、ディスクに分散している
管理情報をある特定の大きさのバックアップ用領域に記
録する事ができないからである。これは、ディレクトリ
の管理情報にそのディレクトリに含まれるファイルやデ
ィレクトリの管理情報が記録されているディスク上のア
ドレスが記述されており、バックアップ領域に管理情報
をバックアップする場合、論理ファイルシステムの管理
情報間の連結情報であるディスク上のアドレスを、バッ
クアップ領域内の管理情報の記録位置に応じて変更しな
ければならない事を意味する。
【００３２】そこで、本発明では特にファイルやディレ
クトリなどの管理情報を多重して持つ機能の無い汎用の
論理ファイルシステムにおいて、管理情報が読み出せな
くなる事によるデータの読み出しが不可能になる事を防
ぐ事を目標としている。
クトリなどの管理情報を多重して持つ機能の無い汎用の
論理ファイルシステムにおいて、管理情報が読み出せな
くなる事によるデータの読み出しが不可能になる事を防
ぐ事を目標としている。
【００３３】既にディスクに記録されているファイルや
ディレクトリはＵＤＦのような論理ファイルシステムに
よって管理されているので、論理ファイルシステムの管
理情報のバックアップを取るのにあまり繁雑な操作が発
生してしまっては意味が無い。そこで本発明では、バッ
クアップ情報として、ファイルやディレクトリにアクセ
スするのに必要最低限の情報のみをバックアップするも
のとする。この必要最低限のバックアップ情報をバック
アップの対象となるファイルシステムの管理する領域と
は別の領域を用意してその領域中に記録する。
ディレクトリはＵＤＦのような論理ファイルシステムに
よって管理されているので、論理ファイルシステムの管
理情報のバックアップを取るのにあまり繁雑な操作が発
生してしまっては意味が無い。そこで本発明では、バッ
クアップ情報として、ファイルやディレクトリにアクセ
スするのに必要最低限の情報のみをバックアップするも
のとする。この必要最低限のバックアップ情報をバック
アップの対象となるファイルシステムの管理する領域と
は別の領域を用意してその領域中に記録する。
【００３４】図２に、本発明で用いるバックアップ領域
とＵＤＦ規格によって規定されるパーティションの関係
を示す。ＵＤＦでは論理セクタ番号２５６とディスク上
の最後の論理セクタ番号−２５６にＡｎｃｈｏｒ Ｖｏ
ｌｕｍｅ Ｄｅｓｃｒｉｐｔｏｒ Ｐｏｉｎｔｅｒが記
録される事が決まっており、この情報にアクセスする事
によって、Ｖｏｌｕｍｅ Ｄｅｓｃｒｉｐｔｏｒ Ｓｅ
ｑｕｅｎｃｅを把握する事が可能となる。論理セクタ番
号とは、ユーザシステムがアクセスできるディスク上の
空間に昇順に付加されたアドレスの事である。
とＵＤＦ規格によって規定されるパーティションの関係
を示す。ＵＤＦでは論理セクタ番号２５６とディスク上
の最後の論理セクタ番号−２５６にＡｎｃｈｏｒ Ｖｏ
ｌｕｍｅ Ｄｅｓｃｒｉｐｔｏｒ Ｐｏｉｎｔｅｒが記
録される事が決まっており、この情報にアクセスする事
によって、Ｖｏｌｕｍｅ Ｄｅｓｃｒｉｐｔｏｒ Ｓｅ
ｑｕｅｎｃｅを把握する事が可能となる。論理セクタ番
号とは、ユーザシステムがアクセスできるディスク上の
空間に昇順に付加されたアドレスの事である。
【００３５】また、Ａｎｃｈｏｒ Ｖｏｌｕｍｅ Ｄｅ
ｓｃｒｉｐｔｏｒ Ｐｏｉｎｔｅｒには、Ｖｏｌｕｍｅ
全体を管理する管理情報で構成される、Ｖｏｌｕｍｅ
Ｄｅｓｃｒｉｐｔｏｒ Ｓｅｑｕｅｎｃｅの記録位置が
管理されている。Ｖｏｌｕｍｅ Ｄｅｓｃｒｉｐｔｏｒ
Ｓｅｑｕｅｎｃｅには、Ｖｏｌｕｍｅ内に定義される
パーティションに関する管理情報が管理されており、実
際にファイルやディレクトリを作成するＵＤＦのファイ
ルシステムを構築するパーティションの位置情報を取得
する事が可能となる。本発明における、履歴情報を記録
するファイル及び管理情報の記録領域とは異なる領域と
は、このＵＤＦパーティション外に確保する領域の事を
指す。
ｓｃｒｉｐｔｏｒ Ｐｏｉｎｔｅｒには、Ｖｏｌｕｍｅ
全体を管理する管理情報で構成される、Ｖｏｌｕｍｅ
Ｄｅｓｃｒｉｐｔｏｒ Ｓｅｑｕｅｎｃｅの記録位置が
管理されている。Ｖｏｌｕｍｅ Ｄｅｓｃｒｉｐｔｏｒ
Ｓｅｑｕｅｎｃｅには、Ｖｏｌｕｍｅ内に定義される
パーティションに関する管理情報が管理されており、実
際にファイルやディレクトリを作成するＵＤＦのファイ
ルシステムを構築するパーティションの位置情報を取得
する事が可能となる。本発明における、履歴情報を記録
するファイル及び管理情報の記録領域とは異なる領域と
は、このＵＤＦパーティション外に確保する領域の事を
指す。
【００３６】このバックアップ情報用領域の位置情報
は、例えば、論理セクタ番号１２８に記録される本発明
用のＡｎｃｈｏｒ Ｄｅｓｃｒｉｐｔｏｒによって把握
する事が可能となる。また、バックアップ情報用領域の
領域の位置を把握するためのＡｎｃｈｏｒ Ｄｅｓｃｒ
ｉｐｔｏｒを用いないで、ある特定の固定位置に領域が
あると決めて確保しても構わない。図の例ではＶｏｌｕ
ｍｅの管理情報のバックアップであるＲｅｓｅｒｖｅｄ
Ｖｏｌｕｍｅ Ｄｅｓｃｒｉｐｔｏｒ Ｓｅｑｕｅｎ
ｃｅがＭａｉｎ Ｖｏｌｕｍｅ Ｄｅｓｃｒｉｐｔｏｒ
Ｓｅｑｕｅｎｃｅの後にも記録されている。
は、例えば、論理セクタ番号１２８に記録される本発明
用のＡｎｃｈｏｒ Ｄｅｓｃｒｉｐｔｏｒによって把握
する事が可能となる。また、バックアップ情報用領域の
領域の位置を把握するためのＡｎｃｈｏｒ Ｄｅｓｃｒ
ｉｐｔｏｒを用いないで、ある特定の固定位置に領域が
あると決めて確保しても構わない。図の例ではＶｏｌｕ
ｍｅの管理情報のバックアップであるＲｅｓｅｒｖｅｄ
Ｖｏｌｕｍｅ Ｄｅｓｃｒｉｐｔｏｒ Ｓｅｑｕｅｎ
ｃｅがＭａｉｎ Ｖｏｌｕｍｅ Ｄｅｓｃｒｉｐｔｏｒ
Ｓｅｑｕｅｎｃｅの後にも記録されている。
【００３７】また、図３にバックアップ領域の中の様子
を示す。図中の先頭のＶｏｌｕｍｅ管理情報は、図２に
おいてバックアップ情報用領域の手前までの領域に対応
する。バックアップ領域には、Ｐｒｉｍａｒｙ Ｈｉｓ
ｔｏｒｙ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒ（ＰＨＴ
Ｄ）と複数のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
（ＨＤ）が記録されている。全てのＨＤを合わせてＨｉ
ｓｔｏｒｙ Ｔａｂｌｅと呼ぶ事とする。このＨｉｓｔ
ｏｒｙ ＴａｂｌｅがＵＤＦファイルシステムの管理情
報のバックアップ情報（履歴情報）となる。ＰＨＴＤは
バックアップ領域中の最後の論理セクタに記録され、Ｈ
ＤはＰＨＴＤの１つ前の論理セクタからバックアップ領
域の先頭方向に向かって順次追記されて行く。論理セク
タ内では、後ろからＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔ
ｏｒをつめて記録することになる。
を示す。図中の先頭のＶｏｌｕｍｅ管理情報は、図２に
おいてバックアップ情報用領域の手前までの領域に対応
する。バックアップ領域には、Ｐｒｉｍａｒｙ Ｈｉｓ
ｔｏｒｙ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒ（ＰＨＴ
Ｄ）と複数のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
（ＨＤ）が記録されている。全てのＨＤを合わせてＨｉ
ｓｔｏｒｙ Ｔａｂｌｅと呼ぶ事とする。このＨｉｓｔ
ｏｒｙ ＴａｂｌｅがＵＤＦファイルシステムの管理情
報のバックアップ情報（履歴情報）となる。ＰＨＴＤは
バックアップ領域中の最後の論理セクタに記録され、Ｈ
ＤはＰＨＴＤの１つ前の論理セクタからバックアップ領
域の先頭方向に向かって順次追記されて行く。論理セク
タ内では、後ろからＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔ
ｏｒをつめて記録することになる。
【００３８】例えば、初めて５２ｂｙｔｅの大きさのＨ
ｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを記録する場合、
ＰＨＴＤの１つ前の論理セクタ内で１９９６ｂｙｔｅ目
（セクタサイズ２０４８ｂｙｔｅ−Ｈｉｓｔｏｒｙ Ｄ
ｅｓｃｒｉｐｔｏｒの大きさ５２ｂｙｔｅ）からＨｉｓ
ｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを記録することにな
る。このように記録するのは、論理セクタ番号の低い方
から最新のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが順
番に記録されているため、バックアップ情報へのアクセ
スが容易になるためである。
ｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを記録する場合、
ＰＨＴＤの１つ前の論理セクタ内で１９９６ｂｙｔｅ目
（セクタサイズ２０４８ｂｙｔｅ−Ｈｉｓｔｏｒｙ Ｄ
ｅｓｃｒｉｐｔｏｒの大きさ５２ｂｙｔｅ）からＨｉｓ
ｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを記録することにな
る。このように記録するのは、論理セクタ番号の低い方
から最新のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが順
番に記録されているため、バックアップ情報へのアクセ
スが容易になるためである。
【００３９】例えば、任意のファイルのバックアップ情
報であるＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉ
ｓｔｏｒｙ Ｔａｂｌｅから抽出する場合、このように
記録されていることによって、ディスクから読み出した
Ｈｉｓｔｏｒｙ Ｔａｂｌｅを格納するメモリ上におい
て、メモリ空間上で先頭から時間的に最新のＨｉｓｔｏ
ｒｙ Ｄｅｓｃｒｉｐｔｏｒが配置されることになり、
アクセスするのには都合が良い。目的のＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒが比較的新しく追加になってい
れば、すぐに見つかることになる。また使用できるメモ
リの制限から一度に全てのＨｉｓｔｏｒｙ Ｄｅｓｃｒ
ｉｐｔｏｒを読み出せないような場合にも非常に有効で
ある。
報であるＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉ
ｓｔｏｒｙ Ｔａｂｌｅから抽出する場合、このように
記録されていることによって、ディスクから読み出した
Ｈｉｓｔｏｒｙ Ｔａｂｌｅを格納するメモリ上におい
て、メモリ空間上で先頭から時間的に最新のＨｉｓｔｏ
ｒｙ Ｄｅｓｃｒｉｐｔｏｒが配置されることになり、
アクセスするのには都合が良い。目的のＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒが比較的新しく追加になってい
れば、すぐに見つかることになる。また使用できるメモ
リの制限から一度に全てのＨｉｓｔｏｒｙ Ｄｅｓｃｒ
ｉｐｔｏｒを読み出せないような場合にも非常に有効で
ある。
【００４０】ＵＤＦファイルシステムにおいてファイル
が新規に作成されたり、変更が発生したり、削除された
り、またディレクトリの場合は新規に作成されたり、削
除された場合、そのファイルやディレクトリ毎に１つの
Ｈｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒがＨｉｓｔｏｒ
ｙ Ｔａｂｌｅに追加される。ＰＨＴＤには、Ｈｉｓｔ
ｏｒｙ Ｔａｂｌｅの大きさが管理されており、常にＨ
ｉｓｔｏｒｙ Ｔａｂｌｅの最後尾（ディスク上では最
前部）が分かるようになっているので、Ｈｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒの追加は容易に行なう事が可能
である。ＵＤＦなどの汎用ファイルシステムと異なり今
までに記録されたＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏ
ｒ（ファイルやディレクトリのバックアップ情報）をＨ
ｉｓｔｏｒｙ Ｔａｂｌｅからは削除しない。
が新規に作成されたり、変更が発生したり、削除された
り、またディレクトリの場合は新規に作成されたり、削
除された場合、そのファイルやディレクトリ毎に１つの
Ｈｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒがＨｉｓｔｏｒ
ｙ Ｔａｂｌｅに追加される。ＰＨＴＤには、Ｈｉｓｔ
ｏｒｙ Ｔａｂｌｅの大きさが管理されており、常にＨ
ｉｓｔｏｒｙ Ｔａｂｌｅの最後尾（ディスク上では最
前部）が分かるようになっているので、Ｈｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒの追加は容易に行なう事が可能
である。ＵＤＦなどの汎用ファイルシステムと異なり今
までに記録されたＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏ
ｒ（ファイルやディレクトリのバックアップ情報）をＨ
ｉｓｔｏｒｙ Ｔａｂｌｅからは削除しない。
【００４１】つまり、ＵＤＦファイルシステムにおいて
ファイルやディレクトリの作成、変更、削除などと言っ
たイベントが発生する度に、単純にそれらのイベントに
対応するＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒがＨｉ
ｓｔｏｒｙ Ｔａｂｌｅの最後尾（ディスク上では最前
部）に追加されるだけである。
ファイルやディレクトリの作成、変更、削除などと言っ
たイベントが発生する度に、単純にそれらのイベントに
対応するＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒがＨｉ
ｓｔｏｒｙ Ｔａｂｌｅの最後尾（ディスク上では最前
部）に追加されるだけである。
【００４２】仮に、ＵＤＦファイルシステムの管理情報
が読み出せないと言った状況になった場合、目的のファ
イルやディレクトリを特定するための識別情報をキーと
して、Ｈｉｓｔｏｒｙ Ｔａｂｌｅの最後尾（ディスク
上では最前部）から順番に、対応するＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒが見つかるまで見ていく。探し出
したＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを参照する
事によって、対応するファイルが記録されているディス
ク上の位置情報を把握する事ができ、データにアクセス
できないと言った問題点を解決する。
が読み出せないと言った状況になった場合、目的のファ
イルやディレクトリを特定するための識別情報をキーと
して、Ｈｉｓｔｏｒｙ Ｔａｂｌｅの最後尾（ディスク
上では最前部）から順番に、対応するＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒが見つかるまで見ていく。探し出
したＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを参照する
事によって、対応するファイルが記録されているディス
ク上の位置情報を把握する事ができ、データにアクセス
できないと言った問題点を解決する。
【００４３】目的のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔ
ｏｒを探し出すのに、Ｈｉｓｔｏｒｙ Ｔａｂｌｅをサ
ーチしなければならないが、本発明の目的であるバック
アップ用途であり、この情報にアクセスする場合は非常
時である事を考慮すれば許容できるものである。その反
面、ＵＤＦファイルシステムにおけるファイルやディレ
クトリの作成、変更、削除と言ったイベントが発生した
際のＨｉｓｔｏｒｙＴａｂｌｅの更新は、Ｈｉｓｔｏｒ
ｙ Ｄｅｓｃｒｉｐｔｏｒの追加のみと必要最低限のデ
ータ量および処理に抑えられている事が特徴となる。
ｏｒを探し出すのに、Ｈｉｓｔｏｒｙ Ｔａｂｌｅをサ
ーチしなければならないが、本発明の目的であるバック
アップ用途であり、この情報にアクセスする場合は非常
時である事を考慮すれば許容できるものである。その反
面、ＵＤＦファイルシステムにおけるファイルやディレ
クトリの作成、変更、削除と言ったイベントが発生した
際のＨｉｓｔｏｒｙＴａｂｌｅの更新は、Ｈｉｓｔｏｒ
ｙ Ｄｅｓｃｒｉｐｔｏｒの追加のみと必要最低限のデ
ータ量および処理に抑えられている事が特徴となる。
【００４４】またＨｉｓｔｏｒｙ Ｔａｂｌｅには、Ｈ
ｉｓｔｏｒｙ Ｔａｂｌｅを作り始めてからのＵＤＦフ
ァイルシステムにおけるファイルの作成、変更、削除、
またディレクトリの作成、削除と言ったイベントに対応
するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが記録され
ている事になるので、Ｈｉｓｔｏｒｙ Ｔａｂｌｅは単
純なＵＤＦファイルシステムの管理情報のバックアップ
だけではなく、ファイルシステムの管理情報の更新履歴
としても利用する事が可能である。
ｉｓｔｏｒｙ Ｔａｂｌｅを作り始めてからのＵＤＦフ
ァイルシステムにおけるファイルの作成、変更、削除、
またディレクトリの作成、削除と言ったイベントに対応
するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが記録され
ている事になるので、Ｈｉｓｔｏｒｙ Ｔａｂｌｅは単
純なＵＤＦファイルシステムの管理情報のバックアップ
だけではなく、ファイルシステムの管理情報の更新履歴
としても利用する事が可能である。
【００４５】Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒは
Ｈｉｓｔｏｒｙ Ｔａｂｌｅに追加されて行くだけなの
で、使用過程においてＨｉｓｔｏｒｙ Ｔａｂｌｅが巨
大になってしまったり、バックアップ領域の空きの残量
が無くなってしまう事も考えられる。そこで、Ｈｉｓｔ
ｏｒｙ ＴａｂｌｅからＵＤＦファイルシステムで定義
されているファイルやディレクトリに対応するＨｉｓｔ
ｏｒｙ Ｄｅｓｃｒｉｐｔｏｒだけ残してその他の過去
の更新履歴情報であるＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐ
ｔｏｒを全て削除しＨｉｓｔｏｒｙ Ｔａｂｌｅを再構
築する事も可能である。
Ｈｉｓｔｏｒｙ Ｔａｂｌｅに追加されて行くだけなの
で、使用過程においてＨｉｓｔｏｒｙ Ｔａｂｌｅが巨
大になってしまったり、バックアップ領域の空きの残量
が無くなってしまう事も考えられる。そこで、Ｈｉｓｔ
ｏｒｙ ＴａｂｌｅからＵＤＦファイルシステムで定義
されているファイルやディレクトリに対応するＨｉｓｔ
ｏｒｙ Ｄｅｓｃｒｉｐｔｏｒだけ残してその他の過去
の更新履歴情報であるＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐ
ｔｏｒを全て削除しＨｉｓｔｏｒｙ Ｔａｂｌｅを再構
築する事も可能である。
【００４６】Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒで
管理するバックアップ対象のファイルやディレクトリを
特定するための識別情報としてファイル名を用いる第１
の実施の形態について説明を行なう。ここで、図４にＰ
ｒｉｍａｒｙ Ｈｉｓｔｏｒｙ Ｔａｂｌｅ Ｄｅｓｃ
ｒｉｐｔｏｒの内容を示す。Ｐｒｉｍａｒｙ Ｈｉｓｔ
ｏｒｙ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒは、Ｈｉｓ
ｔｏｒｙ Ｔａｂｌｅを管理するための情報やバックア
ップ領域の情報を管理する記述子である。
管理するバックアップ対象のファイルやディレクトリを
特定するための識別情報としてファイル名を用いる第１
の実施の形態について説明を行なう。ここで、図４にＰ
ｒｉｍａｒｙ Ｈｉｓｔｏｒｙ Ｔａｂｌｅ Ｄｅｓｃ
ｒｉｐｔｏｒの内容を示す。Ｐｒｉｍａｒｙ Ｈｉｓｔ
ｏｒｙ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒは、Ｈｉｓ
ｔｏｒｙ Ｔａｂｌｅを管理するための情報やバックア
ップ領域の情報を管理する記述子である。
【００４７】Ａｒｅａ Ｓｉｚｅはバックアップ領域の
大きさをｂｙｔｅ数で表し、Ｕｉｎｔ３２型として記録
される。Ｌａｓｔ ＨＤ Ａｄｄｅｄ Ｔｉｍｅｓｔａ
ｍｐは、Ｈｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒがＨｉ
ｓｔｏｒｙ Ｔａｂｌｅに追加された最終日時を記録す
る。この情報によって、最後にＨｉｓｔｏｒｙ Ｄｅｓ
ｃｒｉｐｔｏｒを追加した日時を把握する事ができ、例
えばＵＤＦファイルシステムの管理情報との整合性を見
る場合などに利用する事ができる。ＬａｓｔＨＴ Ｕｐ
ｄａｔｅｄ Ｔｉｍｅｓｔａｍｐは、Ｈｉｓｔｏｒｙ
Ｔａｂｌｅを最後に再構築した日時を記録する。この情
報によりＨｉｓｔｏｒｙ Ｔａｂｌｅが保持する更新履
歴がいつからのものであるかを把握する事が可能とな
る。
大きさをｂｙｔｅ数で表し、Ｕｉｎｔ３２型として記録
される。Ｌａｓｔ ＨＤ Ａｄｄｅｄ Ｔｉｍｅｓｔａ
ｍｐは、Ｈｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒがＨｉ
ｓｔｏｒｙ Ｔａｂｌｅに追加された最終日時を記録す
る。この情報によって、最後にＨｉｓｔｏｒｙ Ｄｅｓ
ｃｒｉｐｔｏｒを追加した日時を把握する事ができ、例
えばＵＤＦファイルシステムの管理情報との整合性を見
る場合などに利用する事ができる。ＬａｓｔＨＴ Ｕｐ
ｄａｔｅｄ Ｔｉｍｅｓｔａｍｐは、Ｈｉｓｔｏｒｙ
Ｔａｂｌｅを最後に再構築した日時を記録する。この情
報によりＨｉｓｔｏｒｙ Ｔａｂｌｅが保持する更新履
歴がいつからのものであるかを把握する事が可能とな
る。
【００４８】Ｎｕｍｂｅｒ ｏｆ Ｈｉｓｔｏｒｙ Ｄ
ｅｓｃｒｉｐｔｏｒｓは、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ
に記録されているＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏ
ｒの数を示し、Ｕｉｎｔ３２型で記録される。Ｈｉｓｔ
ｏｒｙ Ｔａｂｌｅ Ｓｉｚｅは、Ｈｉｓｔｏｒｙ Ｔ
ａｂｌｅのサイズをｂｙｔｅ数で表しＵｉｎｔ３２型で
記録される。Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中の全Ｈｉｓ
ｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの合計サイズをＢｙｔ
ｅ数で表す。ディスクへのＨｉｓｔｏｒｙ Ｄｅｓｃｒ
ｉｐｔｏｒの追加は論理セクタ単位で行うのが一般的な
ので、仮に１論理セクタのサイズが２ＫＢとすると、こ
のＨｉｓｔｏｒｙ Ｔａｂｌｅ Ｓｉｚｅを２ＫＢで割
り、その商がアクセスすべきバックアップ領域の最後の
論理セクタから１セクタ（ＰＨＴＤのサイズ）引いた箇
所からみた論理セクタ数となる。
ｅｓｃｒｉｐｔｏｒｓは、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ
に記録されているＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏ
ｒの数を示し、Ｕｉｎｔ３２型で記録される。Ｈｉｓｔ
ｏｒｙ Ｔａｂｌｅ Ｓｉｚｅは、Ｈｉｓｔｏｒｙ Ｔ
ａｂｌｅのサイズをｂｙｔｅ数で表しＵｉｎｔ３２型で
記録される。Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中の全Ｈｉｓ
ｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの合計サイズをＢｙｔ
ｅ数で表す。ディスクへのＨｉｓｔｏｒｙ Ｄｅｓｃｒ
ｉｐｔｏｒの追加は論理セクタ単位で行うのが一般的な
ので、仮に１論理セクタのサイズが２ＫＢとすると、こ
のＨｉｓｔｏｒｙ Ｔａｂｌｅ Ｓｉｚｅを２ＫＢで割
り、その商がアクセスすべきバックアップ領域の最後の
論理セクタから１セクタ（ＰＨＴＤのサイズ）引いた箇
所からみた論理セクタ数となる。
【００４９】また、余りが追加を行うべき論理セクタに
既にデータが記録されている量である。つまり、追加を
行う場合には目的の論理セクタを一度読み出して、既に
記録されている情報の前にＨｉｓｔｏｒｙ Ｄｅｓｃｒ
ｉｐｔｏｒを追加して、その論理セクタの内容をディス
クに記録する事になる。
既にデータが記録されている量である。つまり、追加を
行う場合には目的の論理セクタを一度読み出して、既に
記録されている情報の前にＨｉｓｔｏｒｙ Ｄｅｓｃｒ
ｉｐｔｏｒを追加して、その論理セクタの内容をディス
クに記録する事になる。
【００５０】なお、図中の、ＲＢＰはＲｅｌａｔｉｖｅ
Ｂｙｔｅ Ｐｏｓｉｔｉｏｎを意味し、先頭から見た
対応する管理項目の開始位置を示す情報で、Ｌｅｎはそ
の管理項目の大きさをＢｙｔｅで表し、Ｆｉｅｌｄ Ｎ
ａｍｅは管理項目名、Ｃｏｎｔｅｎｔｓは、管理項目が
どのような形式で記録されなければならないかというこ
とを示す。Ｃｏｎｔｅｎｔｓで用いられているデータ型
のうち、Ｕｉｎｔ８は符号無し８ｂｉｔ整数、Ｕｉｎｔ
１６は符号無し１６ｂｉｔ整数、Ｕｉｎｔ３２は符号無
し３２ｂｉｔ整数を意味する。Ｓｔｒｉｎｇは文字列を
格納するためのデータ型、Ｔｉｍｅｓｔａｍｐは日時情
報を格納する型である。
Ｂｙｔｅ Ｐｏｓｉｔｉｏｎを意味し、先頭から見た
対応する管理項目の開始位置を示す情報で、Ｌｅｎはそ
の管理項目の大きさをＢｙｔｅで表し、Ｆｉｅｌｄ Ｎ
ａｍｅは管理項目名、Ｃｏｎｔｅｎｔｓは、管理項目が
どのような形式で記録されなければならないかというこ
とを示す。Ｃｏｎｔｅｎｔｓで用いられているデータ型
のうち、Ｕｉｎｔ８は符号無し８ｂｉｔ整数、Ｕｉｎｔ
１６は符号無し１６ｂｉｔ整数、Ｕｉｎｔ３２は符号無
し３２ｂｉｔ整数を意味する。Ｓｔｒｉｎｇは文字列を
格納するためのデータ型、Ｔｉｍｅｓｔａｍｐは日時情
報を格納する型である。
【００５１】図５にＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔ
ｏｒの内容を示す。ＨｉｓｔｏｒｙＤｅｓｃｒｉｐｔｏ
ｒは、論理ファイルシステムにおけるファイルやディレ
クトリの管理情報のバックアップ情報であり、対応する
ファイルやディレクトリにアクセスするための必要最低
限の情報で構成されている。Ｆｉｌｅ Ｓｉｚｅは、バ
ックアップの対象となるファイルのファイルサイズをｂ
ｙｔｅ数で示し、Ｕｉｎｔ３２型で記録される。具体的
には、対応するＵＤＦファイルシステムのＦｉｌｅ Ｅ
ｎｔｒｙ内のファイルサイズの情報を示すＩｎｆｏｒｍ
ａｔｉｏｎ Ｌｅｎｇｔｈと同じ値を記録する。Ｍｏｄ
ｉｆｉｃａｔｉｏｎ Ｄａｔｅ ａｎｄＴｉｍｅは、こ
のファイルが追加、変更、削除、またディレクトリが追
加、削除された時刻を示し、Ｔｉｍｅｓｔａｍｐ型で記
録される。バックアップ対象がファイルの場合、対応す
るＵＤＦファイルシステムのＦｉｌｅ Ｅｎｔｒｙ内の
変更日時を示すＭｏｄｉｆｉｃａｔｉｏｎ Ｄａｔｅ
ａｎｄ Ｔｉｍｅと同じ値を、ディレクトリの場合はＦ
ｉｌｅ Ｅｎｔｒｙ内の作成日時を示すＡｃｃｅｓｓ
Ｄａｔａ ａｎｄ Ｔｉｍｅと同じ値を記録する。ま
た、ファイルやディレクトリの削除を示すＨｉｓｔｏｒ
ｙ Ｄｅｓｃｒｉｐｔｏｒの場合は、実際の削除の日時
を記録する。
ｏｒの内容を示す。ＨｉｓｔｏｒｙＤｅｓｃｒｉｐｔｏ
ｒは、論理ファイルシステムにおけるファイルやディレ
クトリの管理情報のバックアップ情報であり、対応する
ファイルやディレクトリにアクセスするための必要最低
限の情報で構成されている。Ｆｉｌｅ Ｓｉｚｅは、バ
ックアップの対象となるファイルのファイルサイズをｂ
ｙｔｅ数で示し、Ｕｉｎｔ３２型で記録される。具体的
には、対応するＵＤＦファイルシステムのＦｉｌｅ Ｅ
ｎｔｒｙ内のファイルサイズの情報を示すＩｎｆｏｒｍ
ａｔｉｏｎ Ｌｅｎｇｔｈと同じ値を記録する。Ｍｏｄ
ｉｆｉｃａｔｉｏｎ Ｄａｔｅ ａｎｄＴｉｍｅは、こ
のファイルが追加、変更、削除、またディレクトリが追
加、削除された時刻を示し、Ｔｉｍｅｓｔａｍｐ型で記
録される。バックアップ対象がファイルの場合、対応す
るＵＤＦファイルシステムのＦｉｌｅ Ｅｎｔｒｙ内の
変更日時を示すＭｏｄｉｆｉｃａｔｉｏｎ Ｄａｔｅ
ａｎｄ Ｔｉｍｅと同じ値を、ディレクトリの場合はＦ
ｉｌｅ Ｅｎｔｒｙ内の作成日時を示すＡｃｃｅｓｓ
Ｄａｔａ ａｎｄ Ｔｉｍｅと同じ値を記録する。ま
た、ファイルやディレクトリの削除を示すＨｉｓｔｏｒ
ｙ Ｄｅｓｃｒｉｐｔｏｒの場合は、実際の削除の日時
を記録する。
【００５２】ＬＢＮ ｏｆ ＦＥは、バックアップ対象
となるファイルやディレクトリのＵＤＦファイルシステ
ムでのＦｉｌｅ Ｅｎｔｒｙの記録位置を示すＵＤＦパ
ーティション内の論理ブロック番号を示し、Ｕｉｎｔ３
２型で記録する。Ａｔｔｒｉｂｕｔｅｓは、バックアッ
プのイベント種別およびバックアップの対象がファイル
なのかディレクトリなのかをＵｉｎｔ１６型で示す。Ｂ
ｉｔ０は、バックアップ対象がファイルなのかディレク
トリなのかを示し、０の場合はファイル、１の場合はデ
ィレクトリを示す。Ｂｉｔ１と２は、符号無しの２ｂｉ
ｔの情報として扱い、この２ｂｉｔが０の場合「作
成」、１の場合は「変更」、２の場合は「削除」を示
す。
となるファイルやディレクトリのＵＤＦファイルシステ
ムでのＦｉｌｅ Ｅｎｔｒｙの記録位置を示すＵＤＦパ
ーティション内の論理ブロック番号を示し、Ｕｉｎｔ３
２型で記録する。Ａｔｔｒｉｂｕｔｅｓは、バックアッ
プのイベント種別およびバックアップの対象がファイル
なのかディレクトリなのかをＵｉｎｔ１６型で示す。Ｂ
ｉｔ０は、バックアップ対象がファイルなのかディレク
トリなのかを示し、０の場合はファイル、１の場合はデ
ィレクトリを示す。Ｂｉｔ１と２は、符号無しの２ｂｉ
ｔの情報として扱い、この２ｂｉｔが０の場合「作
成」、１の場合は「変更」、２の場合は「削除」を示
す。
【００５３】Ｌｅｎｇｔｈ ｏｆ Ｆｉｌｅ Ｉｄｅｎ
ｔｉｆｉｅｒは、ファイルやディレクトリを識別するた
めの情報であるＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒの長さ
をｂｙｔｅ数で示し、Ｕｉｎｔ１６型で記録される。Ｌ
ｅｎｇｔｈ ｏｆ Ａｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒ
ｉｐｔｏｒｓは、Ａｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉ
ｐｔｏｒｓフィールドの長さをｂｙｔｅ数で示し、Ｕｉ
ｎｔ３２型で記録する。バックアップ対象であるファイ
ルのＵＤＦファイルシステムでのＦｉｌｅ Ｅｎｔｒｙ
のＬｅｎｇｔｈ ｏｆ Ａｌｌｏｃａｔｉｏｎ Ｄｅｓ
ｃｒｉｐｔｏｒｓと同じ値を記録する。
ｔｉｆｉｅｒは、ファイルやディレクトリを識別するた
めの情報であるＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒの長さ
をｂｙｔｅ数で示し、Ｕｉｎｔ１６型で記録される。Ｌ
ｅｎｇｔｈ ｏｆ Ａｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒ
ｉｐｔｏｒｓは、Ａｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉ
ｐｔｏｒｓフィールドの長さをｂｙｔｅ数で示し、Ｕｉ
ｎｔ３２型で記録する。バックアップ対象であるファイ
ルのＵＤＦファイルシステムでのＦｉｌｅ Ｅｎｔｒｙ
のＬｅｎｇｔｈ ｏｆ Ａｌｌｏｃａｔｉｏｎ Ｄｅｓ
ｃｒｉｐｔｏｒｓと同じ値を記録する。
【００５４】Ｆｉｌｅ Ｉｄｅｎｔｉｆｉｅｒは、ファ
イルやディレクトリを識別するための情報であり、Ｌｅ
ｎｇｔｈ ｏｆ Ｆｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ ｂ
ｙｔｅだけｓｔｒｉｎｇ形式で記録される。ファイルや
ディレクトリを識別するための情報とは、通常ファイル
名やディレクトリ名である。ここで、Ｆｉｌｅ Ｉｄｅ
ｎｔｉｆｉｅｒにはファイルやディレクトリのパス名を
併記して記録するものとする。
イルやディレクトリを識別するための情報であり、Ｌｅ
ｎｇｔｈ ｏｆ Ｆｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ ｂ
ｙｔｅだけｓｔｒｉｎｇ形式で記録される。ファイルや
ディレクトリを識別するための情報とは、通常ファイル
名やディレクトリ名である。ここで、Ｆｉｌｅ Ｉｄｅ
ｎｔｉｆｉｅｒにはファイルやディレクトリのパス名を
併記して記録するものとする。
【００５５】例えば、Ｒｏｏｔディレクトリ下のＤＡＴ
Ａディレクトリ下のＦＩＬＥ１．ＤＡＴというファイル
の場合は、￥ＤＡＴＡ￥ＦＩＬＥ１．ＤＡＴと記録す
る。また、前述のＬｅｎｇｔｈ ｏｆ Ｆｉｌｅ Ｉｄ
ｅｎｔｉｆｉｅｒはこの場合、１５ｂｙｔｅとなる。Ｆ
ｉｌｅ Ｉｄｅｎｔｉｆｉｅｒはファイル名である必要
はなく、例えばファイルＩＤ番号などファイルやディレ
クトリが特定できるものであれば構わない。ただし、同
一ディスクに色々な種類のＦｉｌｅ Ｉｄｅｎｔｉｆｉ
ｅｒが混在できるという意味ではない。
Ａディレクトリ下のＦＩＬＥ１．ＤＡＴというファイル
の場合は、￥ＤＡＴＡ￥ＦＩＬＥ１．ＤＡＴと記録す
る。また、前述のＬｅｎｇｔｈ ｏｆ Ｆｉｌｅ Ｉｄ
ｅｎｔｉｆｉｅｒはこの場合、１５ｂｙｔｅとなる。Ｆ
ｉｌｅ Ｉｄｅｎｔｉｆｉｅｒはファイル名である必要
はなく、例えばファイルＩＤ番号などファイルやディレ
クトリが特定できるものであれば構わない。ただし、同
一ディスクに色々な種類のＦｉｌｅ Ｉｄｅｎｔｉｆｉ
ｅｒが混在できるという意味ではない。
【００５６】Ｐａｄｄｉｎｇは、Ａｌｌｏｃａｔｉｏｎ
Ｄｅｓｃｒｉｐｔｏｒｓフィールドの開始ＲＢＰが４
ｂｙｔｅアライメントされるように調整を行う情報であ
り、必要な数だけは００ｈを記録する。４×ｉｐ（Ｌ＿
ＦＩ＋２８＋３）／４）―（Ｌ＿ＦＩ＋２８）によって
Ｐａｄｄｉｎｇすべきｂｙｔｅ数が求まる。ここで、ｉ
ｐ（ｎ）はｎの整数部分を返す関数であり、Ｌ＿ＦＩは
Ｌｅｎｇｔｈ ｏｆＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒフ
ィールドによって示される値である。Ａｌｌｏｃａｔｉ
ｏｎ Ｄｅｓｃｒｉｐｔｏｒｓ（ＡＤ）はディスク上の
データの記録位置を管理するための管理構造であり、Ｕ
ｉｎｔ３２型のＥｘｔｅｎｔ Ｌｅｎｇｔｈと、Ｕｉｎ
ｔ３２型のＥｘｔｅｎｔ Ｐｏｓｉｔｉｏｎによって構
成される。ここでは、Ｅｘｔｅｎｔ ＬｅｎｇｔｈとＥ
ｘｔｅｎｔ Ｐｏｓｉｔｉｏｎを合わせてＳｈｏｒｔ＿
ａｄ型として扱うものとする。
Ｄｅｓｃｒｉｐｔｏｒｓフィールドの開始ＲＢＰが４
ｂｙｔｅアライメントされるように調整を行う情報であ
り、必要な数だけは００ｈを記録する。４×ｉｐ（Ｌ＿
ＦＩ＋２８＋３）／４）―（Ｌ＿ＦＩ＋２８）によって
Ｐａｄｄｉｎｇすべきｂｙｔｅ数が求まる。ここで、ｉ
ｐ（ｎ）はｎの整数部分を返す関数であり、Ｌ＿ＦＩは
Ｌｅｎｇｔｈ ｏｆＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒフ
ィールドによって示される値である。Ａｌｌｏｃａｔｉ
ｏｎ Ｄｅｓｃｒｉｐｔｏｒｓ（ＡＤ）はディスク上の
データの記録位置を管理するための管理構造であり、Ｕ
ｉｎｔ３２型のＥｘｔｅｎｔ Ｌｅｎｇｔｈと、Ｕｉｎ
ｔ３２型のＥｘｔｅｎｔ Ｐｏｓｉｔｉｏｎによって構
成される。ここでは、Ｅｘｔｅｎｔ ＬｅｎｇｔｈとＥ
ｘｔｅｎｔ Ｐｏｓｉｔｉｏｎを合わせてＳｈｏｒｔ＿
ａｄ型として扱うものとする。
【００５７】Ｅｘｔｅｎｔ Ｌｅｎｇｔｈは、分断の長
さをｂｙｔｅ数で示し、Ｅｘｔｅｎｔ Ｐｏｓｉｔｉｏ
ｎは分断の開始論理ブロック番号が記録される。１つの
ファイルであってもファイルに対応する実データはディ
スク上で分断されて記録する事も可能であるため、ファ
イルを構成する分断の数だけＡｌｌｏｃａｔｉｏｎＤｅ
ｓｃｒｉｐｔｏｒｓが記録されることになる。
さをｂｙｔｅ数で示し、Ｅｘｔｅｎｔ Ｐｏｓｉｔｉｏ
ｎは分断の開始論理ブロック番号が記録される。１つの
ファイルであってもファイルに対応する実データはディ
スク上で分断されて記録する事も可能であるため、ファ
イルを構成する分断の数だけＡｌｌｏｃａｔｉｏｎＤｅ
ｓｃｒｉｐｔｏｒｓが記録されることになる。
【００５８】実際には、１つのＡｌｌｏｃａｔｉｏｎ
Ｄｅｓｃｒｉｐｔｏｒｓが８ｂｙｔｅなので、Ｌｅｎｇ
ｔｈ ｏｆ Ａｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔ
ｏｒｓで示される値を８で割ることによってＡｌｌｏｃ
ａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓの数が求まる。こ
のフィールドには、バックアップ対象のＵＤＦファイル
システムでのＦｉｌｅ Ｅｎｔｒｙ内のＡｌｌｏｃａｔ
ｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓと同じ内容を記録す
る。
Ｄｅｓｃｒｉｐｔｏｒｓが８ｂｙｔｅなので、Ｌｅｎｇ
ｔｈ ｏｆ Ａｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔ
ｏｒｓで示される値を８で割ることによってＡｌｌｏｃ
ａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓの数が求まる。こ
のフィールドには、バックアップ対象のＵＤＦファイル
システムでのＦｉｌｅ Ｅｎｔｒｙ内のＡｌｌｏｃａｔ
ｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓと同じ内容を記録す
る。
【００５９】以上のような管理情報を用いた実際の実施
例を説明して行く。図６に示すようなディレクトリ階層
のファイルやディレクトリがある場合、対応するＵＤＦ
ファイルシステムが定義するパーティション内の論理フ
ァイルシステムの管理情報とデータ配置の様子の例を図
７に示す。
例を説明して行く。図６に示すようなディレクトリ階層
のファイルやディレクトリがある場合、対応するＵＤＦ
ファイルシステムが定義するパーティション内の論理フ
ァイルシステムの管理情報とデータ配置の様子の例を図
７に示す。
【００６０】パーティション内の先頭から、パーティシ
ョン内の空き領域情報を管理するＳｐａｃｅ Ｂｉｔｍ
ａｐ Ｄｅｓｃｒｉｐｔｏｒ（ＳＢＤ）、ファイルシス
テムの基本管理情報であり、Ｒｏｏｔディレクトリを管
理するＦｉｌｅ Ｅｎｔｒｙ（ＦＥ Ｒｏｏｔ）へのポ
インタ情報を持つＦｉｌｅ Ｓｅｔ Ｄｅｓｃｒｉｐｔ
ｏｒ（ＦＳＤ）、Ｆｉｌｅ Ｓｅｔ Ｄｅｓｃｒｉｐｔ
ｏｒが終った事を示すＴｅｒｍｉｎａｔｉｎｇ Ｄｅｓ
ｃｒｉｐｔｏｒ（ＴＤ）が記録されている。
ョン内の空き領域情報を管理するＳｐａｃｅ Ｂｉｔｍ
ａｐ Ｄｅｓｃｒｉｐｔｏｒ（ＳＢＤ）、ファイルシス
テムの基本管理情報であり、Ｒｏｏｔディレクトリを管
理するＦｉｌｅ Ｅｎｔｒｙ（ＦＥ Ｒｏｏｔ）へのポ
インタ情報を持つＦｉｌｅ Ｓｅｔ Ｄｅｓｃｒｉｐｔ
ｏｒ（ＦＳＤ）、Ｆｉｌｅ Ｓｅｔ Ｄｅｓｃｒｉｐｔ
ｏｒが終った事を示すＴｅｒｍｉｎａｔｉｎｇ Ｄｅｓ
ｃｒｉｐｔｏｒ（ＴＤ）が記録されている。
【００６１】また、Ｒｏｏｔディレクトリ、ＤＡＴＡデ
ィレクトリをそれぞれ管理するＦｉｌｅ Ｅｎｔｒｙ
（ＦＥ）と、各ディレクトリの下に定義されるファイル
のファイル名や属性情報、そしてそのファイルあるいは
下位のディレクトリを管理するＦｉｌｅ Ｅｎｔｒｙ
（ＦＥ）へのポインタ情報であるＦｉｌｅ Ｉｄｅｎｔ
ｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏｒ（ＦＩＤ）、Ｒｏｏ
ｔディレクトリの下に定義されているＲＥＡＤＭＥ．Ｔ
ＸＴを管理するＦｉｌｅ Ｅｎｔｒｙ（ＦＥ）とＤＡＴ
Ａディレクトリの下に定義される、ＦＩＬＥ１．ＤＡＴ
とＦＩＬＥ２．ＤＡＴを管理するＦｉｌｅ Ｅｎｔｒｙ
（ＦＥ）が記録されている。
ィレクトリをそれぞれ管理するＦｉｌｅ Ｅｎｔｒｙ
（ＦＥ）と、各ディレクトリの下に定義されるファイル
のファイル名や属性情報、そしてそのファイルあるいは
下位のディレクトリを管理するＦｉｌｅ Ｅｎｔｒｙ
（ＦＥ）へのポインタ情報であるＦｉｌｅ Ｉｄｅｎｔ
ｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏｒ（ＦＩＤ）、Ｒｏｏ
ｔディレクトリの下に定義されているＲＥＡＤＭＥ．Ｔ
ＸＴを管理するＦｉｌｅ Ｅｎｔｒｙ（ＦＥ）とＤＡＴ
Ａディレクトリの下に定義される、ＦＩＬＥ１．ＤＡＴ
とＦＩＬＥ２．ＤＡＴを管理するＦｉｌｅ Ｅｎｔｒｙ
（ＦＥ）が記録されている。
【００６２】なお、Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔ
ｏｒ内のＬＢＮ ｏｆ ＦＥフィールドには、このファ
イルを管理するＦｉｌｅ Ｅｎｔｒｙが記録された論理
ブロック番号が記録されることになる。ファイルおよび
ディレクトリのＦｉｌｅ Ｅｎｔｒｙはそれぞれ対応す
るデータが記録されているディスク上の分断情報をＥｘ
ｔｅｎｔとしてＡｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉｐ
ｔｏｒｓによって管理している。例えば、図７の例にお
いては、ＦＩＬＥ１．ＤＡＴに対応するデータはディス
クでは分断して記録されており、Ｅｘｔｅｎｔ４および
５によって構成されている。またＦＩＬＥ２．ＤＡＴに
対応するディスク上のデータは連続的に記録されてお
り、Ｅｘｔｅｎｔ６によって構成されている。
ｏｒ内のＬＢＮ ｏｆ ＦＥフィールドには、このファ
イルを管理するＦｉｌｅ Ｅｎｔｒｙが記録された論理
ブロック番号が記録されることになる。ファイルおよび
ディレクトリのＦｉｌｅ Ｅｎｔｒｙはそれぞれ対応す
るデータが記録されているディスク上の分断情報をＥｘ
ｔｅｎｔとしてＡｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉｐ
ｔｏｒｓによって管理している。例えば、図７の例にお
いては、ＦＩＬＥ１．ＤＡＴに対応するデータはディス
クでは分断して記録されており、Ｅｘｔｅｎｔ４および
５によって構成されている。またＦＩＬＥ２．ＤＡＴに
対応するディスク上のデータは連続的に記録されてお
り、Ｅｘｔｅｎｔ６によって構成されている。
【００６３】このような状況のディレクトリ階層に対応
するＨｉｓｔｏｒｙ Ｔａｂｌｅの例を図８に示す。こ
の図では、一番下にＰｒｉｍａｒｙ Ｈｉｓｔｏｒｙ
Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒが配置されており、
Ｈｉｓｔｏｒｙ Ｔａｂｌｅの最後尾は図の一番上に相
当する。この例では、Ｒｏｏｔディレクトリ（￥）、￥
ＲＥＡＤＭＥ．ＴＸＴ、￥ＤＡＴＡディレクトリ、￥Ｄ
ＡＴＡ￥ＦＩＬＥ１．ＤＡＴ、￥ＤＡＴＡ￥ＦＩＬＥ
２．ＤＡＴの順番で作成された様子を示している。一番
下の枠を除いて１つの枠が１つのＨｉｓｔｏｒｙ Ｄｅ
ｓｃｒｉｐｔｏｒに対応し、全てのＨｉｓｔｏｒｙ Ｄ
ｅｓｃｒｉｐｔｏｒをまとめてＨｉｓｔｏｒｙ Ｔａｂ
ｌｅを構成する。
するＨｉｓｔｏｒｙ Ｔａｂｌｅの例を図８に示す。こ
の図では、一番下にＰｒｉｍａｒｙ Ｈｉｓｔｏｒｙ
Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒが配置されており、
Ｈｉｓｔｏｒｙ Ｔａｂｌｅの最後尾は図の一番上に相
当する。この例では、Ｒｏｏｔディレクトリ（￥）、￥
ＲＥＡＤＭＥ．ＴＸＴ、￥ＤＡＴＡディレクトリ、￥Ｄ
ＡＴＡ￥ＦＩＬＥ１．ＤＡＴ、￥ＤＡＴＡ￥ＦＩＬＥ
２．ＤＡＴの順番で作成された様子を示している。一番
下の枠を除いて１つの枠が１つのＨｉｓｔｏｒｙ Ｄｅ
ｓｃｒｉｐｔｏｒに対応し、全てのＨｉｓｔｏｒｙ Ｄ
ｅｓｃｒｉｐｔｏｒをまとめてＨｉｓｔｏｒｙ Ｔａｂ
ｌｅを構成する。
【００６４】図９に図８に示す状態から、ＤＡＴＡディ
レクトリの下にＦＩＬＥ３．ＤＡＴというファイルが作
成（追加）された場合の様子を示す。ＦＩＬＥ３．ＤＡ
ＴがＵＤＦファイルシステムで作成されると、それに対
応するＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒがＨｉｓ
ｔｏｒｙ Ｔａｂｌｅの最後尾（ディスク上では最前
部）に追加される。
レクトリの下にＦＩＬＥ３．ＤＡＴというファイルが作
成（追加）された場合の様子を示す。ＦＩＬＥ３．ＤＡ
ＴがＵＤＦファイルシステムで作成されると、それに対
応するＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒがＨｉｓ
ｔｏｒｙ Ｔａｂｌｅの最後尾（ディスク上では最前
部）に追加される。
【００６５】この際、Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐ
ｔｏｒのＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒには￥ＤＡＴ
Ａ￥ＦＩＬＥ３．ＤＡＴが記録され、Ｔｉｍｅｓｔａｍ
ｐにはファイルの作成された日時、Ａｔｔｒｉｂｕｔｅ
にはファイルおよび作成を示す００００ｈ、Ｆｉｌｅ
ＳｉｚｅにはＦＩＬＥ３．ＤＡＴのファイルサイズを、
Ｌｅｎｇｔｈ ｏｆ Ａｌｌｏｃａｔｉｏｎ Ｄｅｓｃ
ｒｉｐｔｏｒｓには、ＦＩＬＥ３．ＤＡＴに対応するデ
ータのディスク上での分断数を８倍した値を、そしてＡ
ｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓ（ＡＤ）
にはそれぞれの分断に関する位置情報を記録する事にな
る。ここでは、ＦＩＬＥ３．ＤＡＴはＥｘｔｅｎｔ７の
みによって構成されている（連続して記録されている）
ことになる。
ｔｏｒのＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒには￥ＤＡＴ
Ａ￥ＦＩＬＥ３．ＤＡＴが記録され、Ｔｉｍｅｓｔａｍ
ｐにはファイルの作成された日時、Ａｔｔｒｉｂｕｔｅ
にはファイルおよび作成を示す００００ｈ、Ｆｉｌｅ
ＳｉｚｅにはＦＩＬＥ３．ＤＡＴのファイルサイズを、
Ｌｅｎｇｔｈ ｏｆ Ａｌｌｏｃａｔｉｏｎ Ｄｅｓｃ
ｒｉｐｔｏｒｓには、ＦＩＬＥ３．ＤＡＴに対応するデ
ータのディスク上での分断数を８倍した値を、そしてＡ
ｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓ（ＡＤ）
にはそれぞれの分断に関する位置情報を記録する事にな
る。ここでは、ＦＩＬＥ３．ＤＡＴはＥｘｔｅｎｔ７の
みによって構成されている（連続して記録されている）
ことになる。
【００６６】図１０に、図９で示された状態から、さら
にＤＡＴＡディレクトリの下のＦＩＬＥ２．ＤＡＴの内
容が変更された場合の様子を示す。ＵＤＦファイルシス
テムにおいてＦＩＬＥ２．ＤＡＴのディスク上の位置が
変更になったり、内容が変更になった場合、Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅの最後尾（ディスク上では最前部）
に、対応するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを
追加する。この際、Ａｔｔｒｉｂｕｔｅにはファイルお
よび変更を示す０００２ｈを記録する。また、ＦＩＬＥ
２．ＤＡＴのディスク上の位置が変更となり、Ａｌｌｏ
ｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓ（ＡＤ）が管理
する分断がＥｘｔｅｎｔ８に変更になる。
にＤＡＴＡディレクトリの下のＦＩＬＥ２．ＤＡＴの内
容が変更された場合の様子を示す。ＵＤＦファイルシス
テムにおいてＦＩＬＥ２．ＤＡＴのディスク上の位置が
変更になったり、内容が変更になった場合、Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅの最後尾（ディスク上では最前部）
に、対応するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを
追加する。この際、Ａｔｔｒｉｂｕｔｅにはファイルお
よび変更を示す０００２ｈを記録する。また、ＦＩＬＥ
２．ＤＡＴのディスク上の位置が変更となり、Ａｌｌｏ
ｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓ（ＡＤ）が管理
する分断がＥｘｔｅｎｔ８に変更になる。
【００６７】このＦＩＬＥ２．ＤＡＴの変更に関するＨ
ｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが追加になった時
点で、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ内に既に存在してい
る、ＦＩＬＥ２．ＤＡＴを作成した際のＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒが古い情報となり、更新履歴情
報となる。
ｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが追加になった時
点で、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ内に既に存在してい
る、ＦＩＬＥ２．ＤＡＴを作成した際のＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒが古い情報となり、更新履歴情
報となる。
【００６８】図１１に、図１０で示された状態から、さ
らにＤＡＴＡディレクトリの下のＦＩＬＥ１．ＤＡＴを
削除した場合の様子を示す。ＵＤＦファイルシステムに
おいてＦＩＬＥ１．ＤＡＴが削除された場合、Ｈｉｓｔ
ｏｒｙ Ｔａｂｌｅの最後尾（ディスク上では最前部）
に対応するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを追
加する。この際、Ａｔｔｒｉｂｕｔｅにはファイルおよ
び削除を示す０００４ｈを記録し、Ａｌｌｏｃａｔｉｏ
ｎ Ｄｅｓｃｒｉｐｔｏｒｓ（ＡＤ）には、削除する直
前のデータの位置情報を記録する。
らにＤＡＴＡディレクトリの下のＦＩＬＥ１．ＤＡＴを
削除した場合の様子を示す。ＵＤＦファイルシステムに
おいてＦＩＬＥ１．ＤＡＴが削除された場合、Ｈｉｓｔ
ｏｒｙ Ｔａｂｌｅの最後尾（ディスク上では最前部）
に対応するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを追
加する。この際、Ａｔｔｒｉｂｕｔｅにはファイルおよ
び削除を示す０００４ｈを記録し、Ａｌｌｏｃａｔｉｏ
ｎ Ｄｅｓｃｒｉｐｔｏｒｓ（ＡＤ）には、削除する直
前のデータの位置情報を記録する。
【００６９】削除されるデータであるため直前の記録位
置を記録しないようにしても良い。このＦＩＬＥ１．Ｄ
ＡＴの削除に関するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔ
ｏｒが追加になった時点で、Ｈｉｓｔｏｒｙ Ｔａｂｌ
ｅ内に既に存在しているＦＩＬＥ１．ＤＡＴを作成した
際のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが古い情報
となり、更新履歴情報となる。
置を記録しないようにしても良い。このＦＩＬＥ１．Ｄ
ＡＴの削除に関するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔ
ｏｒが追加になった時点で、Ｈｉｓｔｏｒｙ Ｔａｂｌ
ｅ内に既に存在しているＦＩＬＥ１．ＤＡＴを作成した
際のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが古い情報
となり、更新履歴情報となる。
【００７０】なお、図９乃至１１においてイベント種別
が作成、変更、削除について説明したが、ファイルシス
テム上では例えば、ファイルやディレクトリのコピーや
移動あるいは名称変更なども起きる。これらのイベント
は基本的に前述の作成、変更、削除を組み合わせること
によって更新情報を表現する事が可能である。
が作成、変更、削除について説明したが、ファイルシス
テム上では例えば、ファイルやディレクトリのコピーや
移動あるいは名称変更なども起きる。これらのイベント
は基本的に前述の作成、変更、削除を組み合わせること
によって更新情報を表現する事が可能である。
【００７１】例えば、あるファイルの移動であれば、移
動元のファイルに対応する削除を表すＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒを作成し、移動先のファイルに対
応する作成を表すＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏ
ｒを作成する。また、同様に名称変更でも、名称を変更
する前のファイルに対応する削除を表すＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒを作成し、名称変更後のファイ
ルに対応する作成を表すＨｉｓｔｏｒｙ Ｄｅｓｃｒｉ
ｐｔｏｒを追加すれば良いことになる。
動元のファイルに対応する削除を表すＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒを作成し、移動先のファイルに対
応する作成を表すＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏ
ｒを作成する。また、同様に名称変更でも、名称を変更
する前のファイルに対応する削除を表すＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒを作成し、名称変更後のファイ
ルに対応する作成を表すＨｉｓｔｏｒｙ Ｄｅｓｃｒｉ
ｐｔｏｒを追加すれば良いことになる。
【００７２】ここで、Ｈｉｓｔｏｒｙ Ｔａｂｌｅを再
構築する場合の様子を図１２に示す。Ｈｉｓｔｏｒｙ
Ｔａｂｌｅには、ＵＤＦファイルシステムにおいてファ
イルに関する作成、変更、削除、またディレクトリに関
する作成、削除と言ったイベントが発生する度にＨｉｓ
ｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが単純に追加になって
いく。Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを記録す
る領域は決まっているので、状況に応じてＨｉｓｔｏｒ
ｙ Ｔａｂｌｅから不要な情報を削除しＨｉｓｔｏｒｙ
Ｔａｂｌｅを再構築する事も必要となる。
構築する場合の様子を図１２に示す。Ｈｉｓｔｏｒｙ
Ｔａｂｌｅには、ＵＤＦファイルシステムにおいてファ
イルに関する作成、変更、削除、またディレクトリに関
する作成、削除と言ったイベントが発生する度にＨｉｓ
ｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが単純に追加になって
いく。Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを記録す
る領域は決まっているので、状況に応じてＨｉｓｔｏｒ
ｙ Ｔａｂｌｅから不要な情報を削除しＨｉｓｔｏｒｙ
Ｔａｂｌｅを再構築する事も必要となる。
【００７３】この場合は、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ
の最後部（ディスク上では最前部）のＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒから順番に見て行き、同一のファ
イルやディレクトリに関する情報つまり更新履歴に相当
するＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔ
ｏｒｙ Ｔａｂｌｅから削除する。また、Ａｔｔｒｉｂ
ｕｔｅが削除のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
に関しても同様に削除する。図の例では、左側のＨｉｓ
ｔｏｒｙ Ｔａｂｌｅから更新履歴に相当する「￥ＤＡ
ＴＡ￥ＦＩＬＥ２．ＤＡＴ作成」と「￥ＤＡＴＡ￥ＦＩ
ＬＥ１．ＤＡＴ作成」と、「￥ＤＡＴＡ￥ＦＩＬＥ１．
ＤＡＴ削除」のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
を削除し、右のＨｉｓｔｏｒｙ Ｔａｂｌｅのように最
構築する。この際、残ったＨｉｓｔｏｒｙ Ｄｅｓｃｒ
ｉｐｔｏｒのＡｔｔｒｉｂｕｔｅは全て作成に変更する
事になる。
の最後部（ディスク上では最前部）のＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒから順番に見て行き、同一のファ
イルやディレクトリに関する情報つまり更新履歴に相当
するＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔ
ｏｒｙ Ｔａｂｌｅから削除する。また、Ａｔｔｒｉｂ
ｕｔｅが削除のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
に関しても同様に削除する。図の例では、左側のＨｉｓ
ｔｏｒｙ Ｔａｂｌｅから更新履歴に相当する「￥ＤＡ
ＴＡ￥ＦＩＬＥ２．ＤＡＴ作成」と「￥ＤＡＴＡ￥ＦＩ
ＬＥ１．ＤＡＴ作成」と、「￥ＤＡＴＡ￥ＦＩＬＥ１．
ＤＡＴ削除」のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
を削除し、右のＨｉｓｔｏｒｙ Ｔａｂｌｅのように最
構築する。この際、残ったＨｉｓｔｏｒｙ Ｄｅｓｃｒ
ｉｐｔｏｒのＡｔｔｒｉｂｕｔｅは全て作成に変更する
事になる。
【００７４】ここで、処理の詳細をフローチャートで説
明する。図１３にＵＤＦファイルシステムにおいてファ
イルやディレクトリの作成、変更、削除と言ったイベン
トが発生した場合の処理の流れを示す。
明する。図１３にＵＤＦファイルシステムにおいてファ
イルやディレクトリの作成、変更、削除と言ったイベン
トが発生した場合の処理の流れを示す。
【００７５】ステップＳ１において、ファイルの作成、
変更、削除イベントが発生すると、ステップＳ２におい
てＰｒｉｍａｒｙ Ｈｉｓｔｏｒｙ Ｔａｂｌｅ Ｄｅ
ｓｃｒｉｐｔｏｒを読み出し、Ｈｉｓｔｏｒｙ Ｔａｂ
ｌｅの最後部（ディスク上では最前部）を把握する。
変更、削除イベントが発生すると、ステップＳ２におい
てＰｒｉｍａｒｙ Ｈｉｓｔｏｒｙ Ｔａｂｌｅ Ｄｅ
ｓｃｒｉｐｔｏｒを読み出し、Ｈｉｓｔｏｒｙ Ｔａｂ
ｌｅの最後部（ディスク上では最前部）を把握する。
【００７６】具体的には、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ
中のＨｉｓｔｏｒｙ ＴａｂｌｅＳｉｚｅからＨｉｓｔ
ｏｒｙ Ｔａｂｌｅの最後尾の位置を把握する事が可能
となる。ステップＳ３において、ファイルに対応するＨ
ｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔｏｒｙ
Ｔａｂｌｅの最後に追加する。
中のＨｉｓｔｏｒｙ ＴａｂｌｅＳｉｚｅからＨｉｓｔ
ｏｒｙ Ｔａｂｌｅの最後尾の位置を把握する事が可能
となる。ステップＳ３において、ファイルに対応するＨ
ｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔｏｒｙ
Ｔａｂｌｅの最後に追加する。
【００７７】この際Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔ
ｏｒには、図５に示すように、ファイルの名前をフルパ
ス形式でＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒに、発生した
イベントの種類およびファイルかディレクトリなのかを
Ａｔｔｒｉｂｕｔｅ、イベントが発生した日時、イベン
トが発生した対象のＵＤＦファイルシステムにおけるフ
ァイルの管理するディスク上の分断を管理する形で、Ａ
ｌｌｏｃａｔｉｏｎＤｅｓｃｒｉｐｔｏｒｓが記録され
る。ステップＳ４において、ＰｒｉｍａｒｙＨｉｓｔｏ
ｒｙ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒ内の最後尾
（ディスク上では最前部）にＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒを追加した時刻を示すＬａｓｔ ＨＤ Ａ
ｄｄｅｄ Ｔｉｍｅｓｔａｍｐと、Ｈｉｓｔｏｒｙ Ｄ
ｅｓｃｒｉｐｔｏｒ数、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ
Ｓｉｚｅを更新して処理を終了する。ＵＤＦにおけるフ
ァイルに関するイベントが発生した際の処理は以上のよ
うに、単純なＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの
追加処理となる。
ｏｒには、図５に示すように、ファイルの名前をフルパ
ス形式でＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒに、発生した
イベントの種類およびファイルかディレクトリなのかを
Ａｔｔｒｉｂｕｔｅ、イベントが発生した日時、イベン
トが発生した対象のＵＤＦファイルシステムにおけるフ
ァイルの管理するディスク上の分断を管理する形で、Ａ
ｌｌｏｃａｔｉｏｎＤｅｓｃｒｉｐｔｏｒｓが記録され
る。ステップＳ４において、ＰｒｉｍａｒｙＨｉｓｔｏ
ｒｙ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒ内の最後尾
（ディスク上では最前部）にＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒを追加した時刻を示すＬａｓｔ ＨＤ Ａ
ｄｄｅｄ Ｔｉｍｅｓｔａｍｐと、Ｈｉｓｔｏｒｙ Ｄ
ｅｓｃｒｉｐｔｏｒ数、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ
Ｓｉｚｅを更新して処理を終了する。ＵＤＦにおけるフ
ァイルに関するイベントが発生した際の処理は以上のよ
うに、単純なＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの
追加処理となる。
【００７８】ファイルの場合とは異なり、バックアップ
対象がディレクトリの場合は、ディレクトリの存在のみ
をＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒで管理するこ
とにし、Ｆｉｌｅ Ｓｉｚｅ、ＬＢＮ ｏｆ ＦＥやＡ
ｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓは記録し
ないようにしてもよい。
対象がディレクトリの場合は、ディレクトリの存在のみ
をＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒで管理するこ
とにし、Ｆｉｌｅ Ｓｉｚｅ、ＬＢＮ ｏｆ ＦＥやＡ
ｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓは記録し
ないようにしてもよい。
【００７９】このフローチャートでは、ＵＤＦのファイ
ルシステムにおいてファイルの作成、変更、削除、また
ディレクトリの作成、削除と言ったイベントが発生する
度に対応するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを
Ｈｉｓｔｏｒｙ Ｔａｂｌｅに追加する説明になってい
るが、例えば電源投入時やディスクを装着した時にＰｒ
ｉｍａｒｙ Ｈｉｓｔｏｒｙ Ｔａｂｌｅ Ｄｅｓｃｒ
ｉｐｔｏｒを読み出し、電源を切断する時やディスクを
排出する時などにその期間中に発生した全てのイベント
に対応するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒをま
とめてＨｉｓｔｏｒｙ Ｔａｂｌｅに追加しＰｒｉｍａ
ｒｙ Ｈｉｓｔｏｒｙ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔ
ｏｒを更新し記録しても良い。つまりＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒをメモリ上に保持しておき、ある
タイミングで一度にディスク上のＨｉｓｔｏｒｙ Ｔａ
ｂｌｅを更新しても構わないものとする。
ルシステムにおいてファイルの作成、変更、削除、また
ディレクトリの作成、削除と言ったイベントが発生する
度に対応するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを
Ｈｉｓｔｏｒｙ Ｔａｂｌｅに追加する説明になってい
るが、例えば電源投入時やディスクを装着した時にＰｒ
ｉｍａｒｙ Ｈｉｓｔｏｒｙ Ｔａｂｌｅ Ｄｅｓｃｒ
ｉｐｔｏｒを読み出し、電源を切断する時やディスクを
排出する時などにその期間中に発生した全てのイベント
に対応するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒをま
とめてＨｉｓｔｏｒｙ Ｔａｂｌｅに追加しＰｒｉｍａ
ｒｙ Ｈｉｓｔｏｒｙ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔ
ｏｒを更新し記録しても良い。つまりＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒをメモリ上に保持しておき、ある
タイミングで一度にディスク上のＨｉｓｔｏｒｙ Ｔａ
ｂｌｅを更新しても構わないものとする。
【００８０】このように、ファイルやディレクトリに関
するイベントが発生する度にＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒを追記する訳である。ＵＤＦにおいてファ
イルやディレクトリにアクセスする場合、まずＦｉｌｅ
Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏｒにアク
セスしディレクトリ内に記録されているファイルやディ
レクトリ名を把握する。アクセスしたいファイルやディ
レクトリに対応するＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ
Ｄｅｓｃｒｉｐｔｏｒの情報より、対応するＦｉｌｅ
Ｅｎｔｒｙの記録位置を把握し、Ｆｉｌｅ Ｅｎｔｒｙ
にアクセスする。
するイベントが発生する度にＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒを追記する訳である。ＵＤＦにおいてファ
イルやディレクトリにアクセスする場合、まずＦｉｌｅ
Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏｒにアク
セスしディレクトリ内に記録されているファイルやディ
レクトリ名を把握する。アクセスしたいファイルやディ
レクトリに対応するＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ
Ｄｅｓｃｒｉｐｔｏｒの情報より、対応するＦｉｌｅ
Ｅｎｔｒｙの記録位置を把握し、Ｆｉｌｅ Ｅｎｔｒｙ
にアクセスする。
【００８１】Ｆｉｌｅ Ｅｎｔｒｙにはファイルやディ
レクトリの実体の記録位置が管理されているので、この
情報を元に実体にアクセスする訳である。このときファ
イルやディレクトリにアクセスしようとしたが、それら
を管理するＦｉｌｅ Ｅｎｔｒｙにアクセスできない非
常時に、バックアップ情報であるＨｉｓｔｏｒｙ Ｔａ
ｂｌｅにアクセスする手段に関して図１４のフローチャ
ートを用いて説明する。
レクトリの実体の記録位置が管理されているので、この
情報を元に実体にアクセスする訳である。このときファ
イルやディレクトリにアクセスしようとしたが、それら
を管理するＦｉｌｅ Ｅｎｔｒｙにアクセスできない非
常時に、バックアップ情報であるＨｉｓｔｏｒｙ Ｔａ
ｂｌｅにアクセスする手段に関して図１４のフローチャ
ートを用いて説明する。
【００８２】ステップＳ１０において、バックアップ情
報であるＨｉｓｔｏｒｙ Ｔａｂｌｅへのアクセス要求
が発生すると、ステップＳ１１において、Ｐｒｉｍａｒ
ｙＨｉｓｔｏｒｙ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒ
を読み出し、Ｈｉｓｔｏｒｙ Ｔａｂｌｅの大きさと、
Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中のＨｉｓｔｏｒｙＤｅｓ
ｃｒｉｐｔｏｒの数を把握してＨｉｓｔｏｒｙ Ｔａｂ
ｌｅをディスクから読み出す。具体的には、Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅ中のＮｕｍｂｅｒ ｏｆＨｉｓｔｏｒ
ｙ ＤｅｓｃｒｉｐｔｏｒｓによってＨｉｓｔｏｒｙ
Ｔａｂｌｅ中のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
の数を、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ ＳｉｚｅからＨ
ｉｓｔｏｒｙ Ｔａｂｌｅの最後尾の位置（ディスク上
では最前部）を把握する事が可能となり、読み出された
Ｈｉｓｔｏｒｙ Ｔａｂｌｅは制御部のメモリ上でＨｉ
ｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ毎に展開される。ス
テップＳ１２において、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中
の最後（時間的には最新）のＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒに注目をする。
報であるＨｉｓｔｏｒｙ Ｔａｂｌｅへのアクセス要求
が発生すると、ステップＳ１１において、Ｐｒｉｍａｒ
ｙＨｉｓｔｏｒｙ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒ
を読み出し、Ｈｉｓｔｏｒｙ Ｔａｂｌｅの大きさと、
Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中のＨｉｓｔｏｒｙＤｅｓ
ｃｒｉｐｔｏｒの数を把握してＨｉｓｔｏｒｙ Ｔａｂ
ｌｅをディスクから読み出す。具体的には、Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅ中のＮｕｍｂｅｒ ｏｆＨｉｓｔｏｒ
ｙ ＤｅｓｃｒｉｐｔｏｒｓによってＨｉｓｔｏｒｙ
Ｔａｂｌｅ中のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
の数を、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ ＳｉｚｅからＨ
ｉｓｔｏｒｙ Ｔａｂｌｅの最後尾の位置（ディスク上
では最前部）を把握する事が可能となり、読み出された
Ｈｉｓｔｏｒｙ Ｔａｂｌｅは制御部のメモリ上でＨｉ
ｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ毎に展開される。ス
テップＳ１２において、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中
の最後（時間的には最新）のＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒに注目をする。
【００８３】ステップＳ１３において、今アクセスした
いファイルあるいはディレクトリのフルパス形式の名前
と注目しているＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
のＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒが一致するかどうか
を判定する。一致しない場合はステップＳ１４において
全てのＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒをサーチ
したかどうかを判定する。全てのＨｉｓｔｏｒｙ Ｄｅ
ｓｃｒｉｐｔｏｒをサーチした場合は、探そうとしてい
るバックアップ情報が見つからないという事になり、ス
テップＳ１７においてエラー処理を行ない処理を終了す
る。ステップＳ１４においてまだ全てのＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒをサーチし終っていない場合
は、ステップＳ１５において注目しているＨｉｓｔｏｒ
ｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔｏｒｙ Ｔａｂｌ
ｅ中の１つ前のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
に変更し、ステップＳ１３に戻り処理を繰り返す。
いファイルあるいはディレクトリのフルパス形式の名前
と注目しているＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
のＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒが一致するかどうか
を判定する。一致しない場合はステップＳ１４において
全てのＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒをサーチ
したかどうかを判定する。全てのＨｉｓｔｏｒｙ Ｄｅ
ｓｃｒｉｐｔｏｒをサーチした場合は、探そうとしてい
るバックアップ情報が見つからないという事になり、ス
テップＳ１７においてエラー処理を行ない処理を終了す
る。ステップＳ１４においてまだ全てのＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒをサーチし終っていない場合
は、ステップＳ１５において注目しているＨｉｓｔｏｒ
ｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔｏｒｙ Ｔａｂｌ
ｅ中の１つ前のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
に変更し、ステップＳ１３に戻り処理を繰り返す。
【００８４】ステップＳ１３において名前が一致すると
判定された場合は、ステップＳ１６において注目してい
るＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒのイベント種
別を示すＡｔｔｒｉｂｕｔｅが削除であるかどうかを判
定する。イベント種別が削除の場合、探そうとしている
ファイルあるいはディレクトリのバックアップ情報が削
除状態を示すものであるためステップＳ１７においてエ
ラー処理して処理を終了する。
判定された場合は、ステップＳ１６において注目してい
るＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒのイベント種
別を示すＡｔｔｒｉｂｕｔｅが削除であるかどうかを判
定する。イベント種別が削除の場合、探そうとしている
ファイルあるいはディレクトリのバックアップ情報が削
除状態を示すものであるためステップＳ１７においてエ
ラー処理して処理を終了する。
【００８５】ただし、ここで、ファイルやディレクトリ
の削除した時点での情報が取得したいのであれば、エラ
ー処理を行わず抽出したＨｉｓｔｏｒｙ Ｄｅｓｃｒｉ
ｐｔｏｒを利用しても構わない。ステップＳ１６におい
てイベント種別が削除以外であれば、注目しているＨｉ
ｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが探し出すべきバッ
クアップ情報であり、サーチ処理を終了する。探し出し
たＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ中のＡｌｌｏ
ｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓの情報を用いて
ファイルやディレクトリのデータにアクセスが可能とな
るわけである。
の削除した時点での情報が取得したいのであれば、エラ
ー処理を行わず抽出したＨｉｓｔｏｒｙ Ｄｅｓｃｒｉ
ｐｔｏｒを利用しても構わない。ステップＳ１６におい
てイベント種別が削除以外であれば、注目しているＨｉ
ｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが探し出すべきバッ
クアップ情報であり、サーチ処理を終了する。探し出し
たＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ中のＡｌｌｏ
ｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓの情報を用いて
ファイルやディレクトリのデータにアクセスが可能とな
るわけである。
【００８６】このように、ある特定のファイルやディレ
クトリのＵＤＦファイルシステム管理情報にアクセスで
きない場合に、Ｈｉｓｔｏｒｙ Ｔａｂｌｅから対応す
る最新のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを抽出
し、その情報から対応するデータの記録位置を把握しデ
ータにアクセスする事を可能とした。また、この情報を
利用して主の管理情報であるＵＤＦの管理情報を再構築
する事も可能である。例えば、あるファイルを管理する
ＵＤＦのＦｉｌｅ Ｅｎｔｒｙが読み出せなくなった場
合は、対応するバックアップ情報に相当するＨｉｓｔｏ
ｒｙ Ｄｅｓｃｒｉｐｔｏｒの情報を元にＦｉｌｅ Ｅ
ｎｔｒｙをＵＤＦのパーティション内に記録し直す。
クトリのＵＤＦファイルシステム管理情報にアクセスで
きない場合に、Ｈｉｓｔｏｒｙ Ｔａｂｌｅから対応す
る最新のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを抽出
し、その情報から対応するデータの記録位置を把握しデ
ータにアクセスする事を可能とした。また、この情報を
利用して主の管理情報であるＵＤＦの管理情報を再構築
する事も可能である。例えば、あるファイルを管理する
ＵＤＦのＦｉｌｅ Ｅｎｔｒｙが読み出せなくなった場
合は、対応するバックアップ情報に相当するＨｉｓｔｏ
ｒｙ Ｄｅｓｃｒｉｐｔｏｒの情報を元にＦｉｌｅ Ｅ
ｎｔｒｙをＵＤＦのパーティション内に記録し直す。
【００８７】Ｆｉｌｅ Ｅｎｔｒｙの情報としては、作
成時刻はＦｉｌｅ Ｅｎｔｒｙを作成し直した時刻、属
性情報は標準的な情報にセットされ、問題の発生する前
の状態とは必ずしも同じでは無いが、データにアクセス
するための必要最低限の情報であるデータの記録位置情
報に関しては完全に復活できるわけである。復旧したＵ
ＤＦのＦｉｌｅ Ｅｎｔｒｙの記録位置が問題のあった
元のＦｉｌｅ Ｅｎｔｒｙの記録位置と異なる場合、Ｆ
ｉｌｅ Ｅｎｔｒｙの記録位置を管理しているＵＤＦ管
理情報のＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒ
ｉｐｔｏｒ内のポインタ情報を新しく作成し直したＦｉ
ｌｅ Ｅｎｔｒｙの記録位置に更新を行う。
成時刻はＦｉｌｅ Ｅｎｔｒｙを作成し直した時刻、属
性情報は標準的な情報にセットされ、問題の発生する前
の状態とは必ずしも同じでは無いが、データにアクセス
するための必要最低限の情報であるデータの記録位置情
報に関しては完全に復活できるわけである。復旧したＵ
ＤＦのＦｉｌｅ Ｅｎｔｒｙの記録位置が問題のあった
元のＦｉｌｅ Ｅｎｔｒｙの記録位置と異なる場合、Ｆ
ｉｌｅ Ｅｎｔｒｙの記録位置を管理しているＵＤＦ管
理情報のＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒ
ｉｐｔｏｒ内のポインタ情報を新しく作成し直したＦｉ
ｌｅ Ｅｎｔｒｙの記録位置に更新を行う。
【００８８】続いて、Ｈｉｓｔｏｒｙ Ｔａｂｌｅの再
構築の要求が発生した際の処理の流れを図１５に示した
フローチャートに基づいて説明する。
構築の要求が発生した際の処理の流れを図１５に示した
フローチャートに基づいて説明する。
【００８９】ステップＳ２０において、Ｈｉｓｔｏｒｙ
Ｔａｂｌｅの再構築の要求が発生した場合、ステップ
Ｓ２１において、Ｐｒｉｍａｒｙ Ｈｉｓｔｏｒｙ Ｔ
ａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒを読み出し、Ｈｉｓｔ
ｏｒｙ Ｔａｂｌｅの大きさと、Ｈｉｓｔｏｒｙ Ｔａ
ｂｌｅ中のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの数
を把握してＨｉｓｔｏｒｙ Ｔａｂｌｅをディスクから
読み出す。具体的には、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中
のＮｕｍｂｅｒ ｏｆ Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉ
ｐｔｏｒｓによってＨｉｓｔｏｒｙ Ｔａｂｌｅ中のＨ
ｉｓｔｏｒｙＤｅｓｃｒｉｐｔｏｒの数を、Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅ ＳｉｚｅからＨｉｓｔｏｒｙ Ｔａ
ｂｌｅの最後尾の位置を把握する事が可能となり、読み
出されたＨｉｓｔｏｒｙ Ｔａｂｌｅは制御部のメモリ
上でＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ毎に展開さ
れる。
Ｔａｂｌｅの再構築の要求が発生した場合、ステップ
Ｓ２１において、Ｐｒｉｍａｒｙ Ｈｉｓｔｏｒｙ Ｔ
ａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒを読み出し、Ｈｉｓｔ
ｏｒｙ Ｔａｂｌｅの大きさと、Ｈｉｓｔｏｒｙ Ｔａ
ｂｌｅ中のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの数
を把握してＨｉｓｔｏｒｙ Ｔａｂｌｅをディスクから
読み出す。具体的には、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中
のＮｕｍｂｅｒ ｏｆ Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉ
ｐｔｏｒｓによってＨｉｓｔｏｒｙ Ｔａｂｌｅ中のＨ
ｉｓｔｏｒｙＤｅｓｃｒｉｐｔｏｒの数を、Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅ ＳｉｚｅからＨｉｓｔｏｒｙ Ｔａ
ｂｌｅの最後尾の位置を把握する事が可能となり、読み
出されたＨｉｓｔｏｒｙ Ｔａｂｌｅは制御部のメモリ
上でＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ毎に展開さ
れる。
【００９０】ステップＳ２２において、Ｈｉｓｔｏｒｙ
Ｔａｂｌｅ中の最後のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉ
ｐｔｏｒに注目をする。ステップＳ２３において、Ｈｉ
ｓｔｏｒｙ Ｔａｂｌｅ中の全てのＨｉｓｔｏｒｙ Ｄ
ｅｓｃｒｉｐｔｏｒを見たかどうかを判定し、全てのＨ
ｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒについて処理が終
っていれば処理を終了する。まだ処理が終っていない場
合は、ステップＳ２４において、注目しているＨｉｓｔ
ｏｒｙ Ｄｅｓｃｒｉｐｔｏｒのイベント種別を表すＡ
ｔｔｒｉｂｕｔｅが削除かどうかを判定する。イベント
種別が削除の場合は、ステップＳ２８において注目して
いるＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを削除リス
トに追加する。
Ｔａｂｌｅ中の最後のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉ
ｐｔｏｒに注目をする。ステップＳ２３において、Ｈｉ
ｓｔｏｒｙ Ｔａｂｌｅ中の全てのＨｉｓｔｏｒｙ Ｄ
ｅｓｃｒｉｐｔｏｒを見たかどうかを判定し、全てのＨ
ｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒについて処理が終
っていれば処理を終了する。まだ処理が終っていない場
合は、ステップＳ２４において、注目しているＨｉｓｔ
ｏｒｙ Ｄｅｓｃｒｉｐｔｏｒのイベント種別を表すＡ
ｔｔｒｉｂｕｔｅが削除かどうかを判定する。イベント
種別が削除の場合は、ステップＳ２８において注目して
いるＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを削除リス
トに追加する。
【００９１】具体的には注目しているＨｉｓｔｏｒｙ
ＤｅｓｃｒｉｐｔｏｒのＦｉｌｅＩｄｅｎｔｉｆｉｅｒ
を削除リストに登録する事を行う。ステップＳ２９にお
いて注目しているＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏ
ｒをＨｉｓｔｏｒｙ Ｔａｂｌｅ中の１つ前のＨｉｓｔ
ｏｒｙ Ｄｅｓｃｒｉｐｔｏｒに変更し、ステップＳ２
３に戻り処理を繰り返す。
ＤｅｓｃｒｉｐｔｏｒのＦｉｌｅＩｄｅｎｔｉｆｉｅｒ
を削除リストに登録する事を行う。ステップＳ２９にお
いて注目しているＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏ
ｒをＨｉｓｔｏｒｙ Ｔａｂｌｅ中の１つ前のＨｉｓｔ
ｏｒｙ Ｄｅｓｃｒｉｐｔｏｒに変更し、ステップＳ２
３に戻り処理を繰り返す。
【００９２】ステップＳ２４においてイベント種別が削
除でない場合、ステップＳ２５において注目しているＨ
ｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが削除リストに含
まれているかを判定する。具体的には、注目しているＨ
ｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒのＦｉｌｅ Ｉｄ
ｅｎｔｉｆｉｅｒと削除リストに含まれる名前を比較す
る事によって行う。ステップＳ２６において削除リスト
に含まれていたかを判定し、含まれていた場合は、その
ままステップＳ２９において注目しているＨｉｓｔｏｒ
ｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔｏｒｙ Ｔａｂｌ
ｅ中の１つ前のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
に変更し、ステップＳ２３に戻り処理を繰り返す。
除でない場合、ステップＳ２５において注目しているＨ
ｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが削除リストに含
まれているかを判定する。具体的には、注目しているＨ
ｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒのＦｉｌｅ Ｉｄ
ｅｎｔｉｆｉｅｒと削除リストに含まれる名前を比較す
る事によって行う。ステップＳ２６において削除リスト
に含まれていたかを判定し、含まれていた場合は、その
ままステップＳ２９において注目しているＨｉｓｔｏｒ
ｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔｏｒｙ Ｔａｂｌ
ｅ中の１つ前のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
に変更し、ステップＳ２３に戻り処理を繰り返す。
【００９３】ステップＳ２６において削除リストに含ま
れていないと判定された場合、ステップＳ２７において
抽出結果リストに追加する。具体的には注目しているＨ
ｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒをそのまま抽出結
果リストにコピーする事を行う。ステップＳ２８におい
て、注目しているＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏ
ｒを削除リストに追加し、ステップＳ２９において注目
しているＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉ
ｓｔｏｒｙ Ｔａｂｌｅ中の１つ前のＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒに変更し、ステップＳ２３に戻り
処理を繰り返す。
れていないと判定された場合、ステップＳ２７において
抽出結果リストに追加する。具体的には注目しているＨ
ｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒをそのまま抽出結
果リストにコピーする事を行う。ステップＳ２８におい
て、注目しているＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏ
ｒを削除リストに追加し、ステップＳ２９において注目
しているＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉ
ｓｔｏｒｙ Ｔａｂｌｅ中の１つ前のＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒに変更し、ステップＳ２３に戻り
処理を繰り返す。
【００９４】このような処理を行う事によって、Ｈｉｓ
ｔｏｒｙ Ｔａｂｌｅ中の同じファイルやディレクトリ
を示す重複するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
を削除し、更新履歴として存在した不要な情報を削除す
る事が可能となる。具体的には、処理が終わった段階で
抽出結果リストに残っているＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒが目的の情報となる。
ｔｏｒｙ Ｔａｂｌｅ中の同じファイルやディレクトリ
を示す重複するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
を削除し、更新履歴として存在した不要な情報を削除す
る事が可能となる。具体的には、処理が終わった段階で
抽出結果リストに残っているＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒが目的の情報となる。
【００９５】続いて、Ｈｉｓｔｏｒｙ Ｔａｂｌｅから
あるファイルやディレクトリに関する更新履歴を取得し
たい要求が発生した際の処理の流れを図１６に示したフ
ローチャートに基づいて説明する。
あるファイルやディレクトリに関する更新履歴を取得し
たい要求が発生した際の処理の流れを図１６に示したフ
ローチャートに基づいて説明する。
【００９６】ステップＳ４０において、Ｈｉｓｔｏｒｙ
Ｔａｂｌｅからあるファイルやディレクトリに関する
更新履歴を取得したい要求が発生した場合、ステップＳ
４１において、Ｐｒｉｍａｒｙ Ｈｉｓｔｏｒｙ Ｔａ
ｂｌｅ Ｄｅｓｃｒｉｐｔｏｒを読み出し、Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅの大きさと、Ｈｉｓｔｏｒｙ Ｔａｂ
ｌｅ中のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの数を
把握してＨｉｓｔｏｒｙ Ｔａｂｌｅをディスクから読
み出す。具体的には、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中の
Ｎｕｍｂｅｒ ｏｆ Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐ
ｔｏｒｓによってＨｉｓｔｏｒｙ Ｔａｂｌｅ中のＨｉ
ｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの数を、Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅ ＳｉｚｅからＨｉｓｔｏｒｙ Ｔａ
ｂｌｅの最後尾の位置を把握する事が可能となり、読み
出されたＨｉｓｔｏｒｙ Ｔａｂｌｅは制御部のメモリ
上でＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ毎に展開さ
れる。
Ｔａｂｌｅからあるファイルやディレクトリに関する
更新履歴を取得したい要求が発生した場合、ステップＳ
４１において、Ｐｒｉｍａｒｙ Ｈｉｓｔｏｒｙ Ｔａ
ｂｌｅ Ｄｅｓｃｒｉｐｔｏｒを読み出し、Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅの大きさと、Ｈｉｓｔｏｒｙ Ｔａｂ
ｌｅ中のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの数を
把握してＨｉｓｔｏｒｙ Ｔａｂｌｅをディスクから読
み出す。具体的には、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中の
Ｎｕｍｂｅｒ ｏｆ Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐ
ｔｏｒｓによってＨｉｓｔｏｒｙ Ｔａｂｌｅ中のＨｉ
ｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの数を、Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅ ＳｉｚｅからＨｉｓｔｏｒｙ Ｔａ
ｂｌｅの最後尾の位置を把握する事が可能となり、読み
出されたＨｉｓｔｏｒｙ Ｔａｂｌｅは制御部のメモリ
上でＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ毎に展開さ
れる。
【００９７】ステップＳ４２において、Ｈｉｓｔｏｒｙ
Ｔａｂｌｅ中の最後のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉ
ｐｔｏｒに注目をする。ステップＳ４３において、検索
対象を示す変数であるＳＥＡＲＣＨＫＥＹに目的のＦｉ
ｌｅ Ｉｄｅｎｔｉｆｉｅｒをセットする。ステップＳ
４４において、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中の全ての
Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを調べたかどう
かを判定し、全てのＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔ
ｏｒについて処理が終っていれば処理を終了する。まだ
処理が終っていない場合は、ステップＳ４５において、
注目しているＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの
Ｆｉｌｅ Ｉｄｅｎｔｉｆｉｅｒが対象としているファ
イルあるいはディレクトリと一致するかどうかを判定す
る。具体的にはＳＥＡＲＣＨＫＥＹと注目しているＨｉ
ｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒのＦｉｌｅ Ｉｄｅ
ｎｔｉｆｉｅｒを比較する事によって行う。一致しない
場合はステップＳ４７において注目するＨｉｓｔｏｒｙ
ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔｏｒｙ Ｔａｂｌｅ
中の１つ前のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒに
変更し、ステップＳ４４に戻り処理を繰り返す。
Ｔａｂｌｅ中の最後のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉ
ｐｔｏｒに注目をする。ステップＳ４３において、検索
対象を示す変数であるＳＥＡＲＣＨＫＥＹに目的のＦｉ
ｌｅ Ｉｄｅｎｔｉｆｉｅｒをセットする。ステップＳ
４４において、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中の全ての
Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを調べたかどう
かを判定し、全てのＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔ
ｏｒについて処理が終っていれば処理を終了する。まだ
処理が終っていない場合は、ステップＳ４５において、
注目しているＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの
Ｆｉｌｅ Ｉｄｅｎｔｉｆｉｅｒが対象としているファ
イルあるいはディレクトリと一致するかどうかを判定す
る。具体的にはＳＥＡＲＣＨＫＥＹと注目しているＨｉ
ｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒのＦｉｌｅ Ｉｄｅ
ｎｔｉｆｉｅｒを比較する事によって行う。一致しない
場合はステップＳ４７において注目するＨｉｓｔｏｒｙ
ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔｏｒｙ Ｔａｂｌｅ
中の１つ前のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒに
変更し、ステップＳ４４に戻り処理を繰り返す。
【００９８】ステップＳ４５において、注目しているＨ
ｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒのＦｉｌｅ Ｉｄ
ｅｎｔｉｆｉｅｒが対象としているファイルあるいはデ
ィレクトリと一致する場合、ステップＳ４６において現
在注目しているＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
は、更新履歴を取得しようとしている対象のファイルあ
るいはディレクトリに関する更新履歴であるものとし抽
出結果としてリストアップする事になる。ステップＳ４
７において注目するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔ
ｏｒをＨｉｓｔｏｒｙ Ｔａｂｌｅ中の１つ前のＨｉｓ
ｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒに変更し、ステップＳ
４４に戻り処理を繰り返す。
ｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒのＦｉｌｅ Ｉｄ
ｅｎｔｉｆｉｅｒが対象としているファイルあるいはデ
ィレクトリと一致する場合、ステップＳ４６において現
在注目しているＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
は、更新履歴を取得しようとしている対象のファイルあ
るいはディレクトリに関する更新履歴であるものとし抽
出結果としてリストアップする事になる。ステップＳ４
７において注目するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔ
ｏｒをＨｉｓｔｏｒｙ Ｔａｂｌｅ中の１つ前のＨｉｓ
ｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒに変更し、ステップＳ
４４に戻り処理を繰り返す。
【００９９】ステップＳ４７において注目するＨｉｓｔ
ｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔｏｒｙ Ｔａ
ｂｌｅ中の１つ前のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔ
ｏｒに変更し、ステップＳ４４に戻り処理を繰り返す。
ｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔｏｒｙ Ｔａ
ｂｌｅ中の１つ前のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔ
ｏｒに変更し、ステップＳ４４に戻り処理を繰り返す。
【０１００】このような処理によって、Ｈｉｓｔｏｒｙ
Ｔａｂｌｅから更新履歴を取得したいファイルあるい
はディレクトリに関する全てのＨｉｓｔｏｒｙ Ｄｅｓ
ｃｒｉｐｔｏｒを簡単に抽出する事が可能となる。具体
的には、処理が終わった段階の抽出結果リストに残って
いるＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが目的の情
報となる。
Ｔａｂｌｅから更新履歴を取得したいファイルあるい
はディレクトリに関する全てのＨｉｓｔｏｒｙ Ｄｅｓ
ｃｒｉｐｔｏｒを簡単に抽出する事が可能となる。具体
的には、処理が終わった段階の抽出結果リストに残って
いるＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが目的の情
報となる。
【０１０１】説明してきたＨｉｓｔｏｒｙ Ｔａｂｌｅ
では、アクセスしようとするファイルやディレクトリが
あらかじめ分かっている場合には、Ｈｉｓｔｏｒｙ Ｔ
ａｂｌｅに含まれる対応するＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒを探し出すだけの処理で終わる。仮に管理
情報のバックアップの対象となるファイルシステムの管
理情報が全くディスクから読み出せなくなり、どのよう
なファイルが記録されているか、あるいはどのようなデ
ィレクトリ構造の状態であるかが不明になる事も考えら
れる。このような状況が発生した場合には、Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅを再構築し残されたＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒを参照する事によって、バックア
ップ情報が保持するディレクトリ階層の構造を把握する
事が可能となり、バックアップ情報を介してファイルや
ディレクトリにアクセスしたり、管理情報の復旧をする
ための情報をして利用できる事になる。
では、アクセスしようとするファイルやディレクトリが
あらかじめ分かっている場合には、Ｈｉｓｔｏｒｙ Ｔ
ａｂｌｅに含まれる対応するＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒを探し出すだけの処理で終わる。仮に管理
情報のバックアップの対象となるファイルシステムの管
理情報が全くディスクから読み出せなくなり、どのよう
なファイルが記録されているか、あるいはどのようなデ
ィレクトリ構造の状態であるかが不明になる事も考えら
れる。このような状況が発生した場合には、Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅを再構築し残されたＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒを参照する事によって、バックア
ップ情報が保持するディレクトリ階層の構造を把握する
事が可能となり、バックアップ情報を介してファイルや
ディレクトリにアクセスしたり、管理情報の復旧をする
ための情報をして利用できる事になる。
【０１０２】ここで、ＵＤＦファイルシステムにおい
て、ファイルやディレクトリを管理するＦｉｌｅ Ｅｎ
ｔｒｙにアクセスできなかった場合に、バックアップ情
報を元に管理情報を復旧する手順を図１７に示すフロー
チャートに基づいて説明する。ステップＳ５０におい
て、ＵＤＦファイルシステムにおいてファイルやディレ
クトリを管理するＦｉｌｅ Ｅｎｔｒｙにアクセスでき
ない事が、例えば、Ｆｉｌｅ Ｅｎｔｒｙの読み出しが
物理的に失敗したり、読み出せた場合であってもＦｉｌ
ｅ Ｅｎｔｒｙのヘッダ情報に記録されているチェック
サムやＣＲＣ情報が正しくない事によって検出された場
合、ステップＳ５１において、問題のファイルやディレ
クトリを示すファイル名をフルパス表現で指定してＨｉ
ｓｔｏｒｙＴａｂｌｅより対応するバックアップ情報で
あるＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを抽出す
る。具体的な抽出方法は既に述べた通りである。
て、ファイルやディレクトリを管理するＦｉｌｅ Ｅｎ
ｔｒｙにアクセスできなかった場合に、バックアップ情
報を元に管理情報を復旧する手順を図１７に示すフロー
チャートに基づいて説明する。ステップＳ５０におい
て、ＵＤＦファイルシステムにおいてファイルやディレ
クトリを管理するＦｉｌｅ Ｅｎｔｒｙにアクセスでき
ない事が、例えば、Ｆｉｌｅ Ｅｎｔｒｙの読み出しが
物理的に失敗したり、読み出せた場合であってもＦｉｌ
ｅ Ｅｎｔｒｙのヘッダ情報に記録されているチェック
サムやＣＲＣ情報が正しくない事によって検出された場
合、ステップＳ５１において、問題のファイルやディレ
クトリを示すファイル名をフルパス表現で指定してＨｉ
ｓｔｏｒｙＴａｂｌｅより対応するバックアップ情報で
あるＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを抽出す
る。具体的な抽出方法は既に述べた通りである。
【０１０３】ステップＳ５２において、抽出したＨｉｓ
ｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの情報からＦｉｌｅ
Ｅｎｔｒｙの再生成を行うが、このＦｉｌｅ Ｅｎｔｒ
ｙには、Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒに含ま
れるＡｌｌｏｃａｔｉｏｎＤｅｓｃｒｉｐｔｏｒｓの内
容をコピーする。Ａｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉ
ｐｔｏｒｓにはファイルに対応するデータの記録位置情
報が格納されており、この情報が存在すればデータを読
み出すための位置情報がわかるのでデータの読み出しが
可能となる。再生成したＦｉｌｅ Ｅｎｔｒｙはディス
ク上に記録する。
ｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの情報からＦｉｌｅ
Ｅｎｔｒｙの再生成を行うが、このＦｉｌｅ Ｅｎｔｒ
ｙには、Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒに含ま
れるＡｌｌｏｃａｔｉｏｎＤｅｓｃｒｉｐｔｏｒｓの内
容をコピーする。Ａｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉ
ｐｔｏｒｓにはファイルに対応するデータの記録位置情
報が格納されており、この情報が存在すればデータを読
み出すための位置情報がわかるのでデータの読み出しが
可能となる。再生成したＦｉｌｅ Ｅｎｔｒｙはディス
ク上に記録する。
【０１０４】ステップＳ５３において、アクセスできな
かったＦｉｌｅ Ｅｎｔｒｙの記録位置を管理している
ＵＤＦのＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒ
ｉｐｔｏｒのＩＣＢフィールドを、記録し直したＦｉｌ
ｅ Ｅｎｔｒｙの記録位置を管理するように更新する。
再生成したＦｉｌｅ Ｅｎｔｒｙを、読み出せなかった
Ｆｉｌｅ Ｅｎｔｒｙと同じ位置に記録し直した場合は
上記の更新処理を行う必要はない。
かったＦｉｌｅ Ｅｎｔｒｙの記録位置を管理している
ＵＤＦのＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒ
ｉｐｔｏｒのＩＣＢフィールドを、記録し直したＦｉｌ
ｅ Ｅｎｔｒｙの記録位置を管理するように更新する。
再生成したＦｉｌｅ Ｅｎｔｒｙを、読み出せなかった
Ｆｉｌｅ Ｅｎｔｒｙと同じ位置に記録し直した場合は
上記の更新処理を行う必要はない。
【０１０５】続いて、ＵＤＦファイルシステムにおい
て、ディレクトリを管理するＦｉｌｅＥｎｔｒｙにアク
セスできなかった場合に、バックアップ情報を元に管理
情報を復旧する別の手順を図１８に示すフローチャート
に基づいて説明する。ステップＳ６０において、ＵＤＦ
ファイルシステムにおいてディレクトリを管理するＦｉ
ｌｅ Ｅｎｔｒｙにアクセスできない事が検出された場
合、ステップＳ６１において問題のディレクトリのＦｉ
ｌｅ Ｅｎｔｒｙが記録されている位置を管理している
Ｆｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏ
ｒを上位のディレクトリのディレクトリ情報から削除す
る。
て、ディレクトリを管理するＦｉｌｅＥｎｔｒｙにアク
セスできなかった場合に、バックアップ情報を元に管理
情報を復旧する別の手順を図１８に示すフローチャート
に基づいて説明する。ステップＳ６０において、ＵＤＦ
ファイルシステムにおいてディレクトリを管理するＦｉ
ｌｅ Ｅｎｔｒｙにアクセスできない事が検出された場
合、ステップＳ６１において問題のディレクトリのＦｉ
ｌｅ Ｅｎｔｒｙが記録されている位置を管理している
Ｆｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏ
ｒを上位のディレクトリのディレクトリ情報から削除す
る。
【０１０６】ステップＳ６２において、Ｈｉｓｔｏｒｙ
Ｔａｂｌｅから不要なＨｉｓｔｏｒｙ Ｄｅｓｃｒｉ
ｐｔｏｒを削除するＨｉｓｔｏｒｙ Ｔａｂｌｅの再構
築処理を行う。具体的な処理内容は前述した通りであ
る。ステップＳ６３において問題のディレクトリを示す
ディレクトリ名をフルパス表現で指定してＨｉｓｔｏｒ
ｙ Ｔａｂｌｅより対応するバックアップ情報を含めそ
のディレクトリの下位に作成されたファイルやディレク
トリに対応する全てのＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐ
ｔｏｒを抽出する。
Ｔａｂｌｅから不要なＨｉｓｔｏｒｙ Ｄｅｓｃｒｉ
ｐｔｏｒを削除するＨｉｓｔｏｒｙ Ｔａｂｌｅの再構
築処理を行う。具体的な処理内容は前述した通りであ
る。ステップＳ６３において問題のディレクトリを示す
ディレクトリ名をフルパス表現で指定してＨｉｓｔｏｒ
ｙ Ｔａｂｌｅより対応するバックアップ情報を含めそ
のディレクトリの下位に作成されたファイルやディレク
トリに対応する全てのＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐ
ｔｏｒを抽出する。
【０１０７】ステップＳ６４において、ステップＳ６３
で抽出したＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの情
報の中から、Ａｔｔｒｉｂｕｔｅ情報を参照しディレク
トリに関連するものだけ抜き出す。抜き出したディレク
トリに関するＨｉｓｔｏｒｙＤｅｓｃｒｉｐｔｏｒが示
すディレクトリを全て作成する。この処理によって、デ
ィレクトリ構造が問題の発生する前の状態に復旧される
ことになる。
で抽出したＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの情
報の中から、Ａｔｔｒｉｂｕｔｅ情報を参照しディレク
トリに関連するものだけ抜き出す。抜き出したディレク
トリに関するＨｉｓｔｏｒｙＤｅｓｃｒｉｐｔｏｒが示
すディレクトリを全て作成する。この処理によって、デ
ィレクトリ構造が問題の発生する前の状態に復旧される
ことになる。
【０１０８】ステップＳ６５において、ステップＳ６３
で抽出したＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒのＡ
ｔｔｒｉｂｕｔｅ情報を参照しファイルに関連するもの
だけを抜き出す。抜き出したファイルに関するＨｉｓｔ
ｏｒｙ ＤｅｓｃｒｉｐｔｏｒのＦｉｌｅ Ｉｄｅｎｔ
ｉｆｉｅｒを解析し、それぞれのファイルが記録されて
いるべきディレクトリのディレクトリ情報にＦｉｌｅ
ＩｄｅｎｔｉｆｉｅｒＤｅｓｃｒｉｐｔｏｒを追加して
いく。この時、対応するファイルのＦｉｌｅＥｎｔｒｙ
の記録位置を管理するＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ
Ｄｅｓｃｒｉｐｔｏｒ内のＩＣＢには、Ｈｉｓｔｏｒ
ｙ Ｄｅｓｃｒｉｐｔｏｒで管理するＬＢＮ ｏｆ Ｆ
Ｅの情報を記録する。
で抽出したＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒのＡ
ｔｔｒｉｂｕｔｅ情報を参照しファイルに関連するもの
だけを抜き出す。抜き出したファイルに関するＨｉｓｔ
ｏｒｙ ＤｅｓｃｒｉｐｔｏｒのＦｉｌｅ Ｉｄｅｎｔ
ｉｆｉｅｒを解析し、それぞれのファイルが記録されて
いるべきディレクトリのディレクトリ情報にＦｉｌｅ
ＩｄｅｎｔｉｆｉｅｒＤｅｓｃｒｉｐｔｏｒを追加して
いく。この時、対応するファイルのＦｉｌｅＥｎｔｒｙ
の記録位置を管理するＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ
Ｄｅｓｃｒｉｐｔｏｒ内のＩＣＢには、Ｈｉｓｔｏｒ
ｙ Ｄｅｓｃｒｉｐｔｏｒで管理するＬＢＮ ｏｆ Ｆ
Ｅの情報を記録する。
【０１０９】ファイルのＦｉｌｅ Ｅｎｔｒｙの復旧の
場合と異なり、ディスク上に記録されているファイルの
Ｆｉｌｅ Ｅｎｔｒｙには問題が全く無いので、Ｆｉｌ
ｅＩｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏｒからの
ポインタ情報を正しくセットするだけでファイルにアク
セスできる事になる。このようにＬＢＮ ｏｆ ＦＥは
ファイルのＦｉｌｅ Ｅｎｔｒｙへのポインタ情報を繋
ぎなおすために使用する。またＦｉｌｅ Ｉｄｅｎｔｉ
ｆｉｅｒ ＤｅｓｃｒｉｐｔｏｒのＦｉｌｅＩｄｅｎｔ
ｉｆｉｅｒには、Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏ
ｒのＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒからパス情報を取
り除いたものを記録する。この処理を全てのファイルに
対応するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒに対し
て行うことによってディレクトリ構造と共にファイル構
造の管理情報も復旧された事になる。なお後処理とし
て、ディスク上にどの管理情報からも参照されない管理
情報がゴミとして残る事になるので、不要な管理情報を
検出して空き領域情報を更新し未使用箇所として開放し
ても良い。
場合と異なり、ディスク上に記録されているファイルの
Ｆｉｌｅ Ｅｎｔｒｙには問題が全く無いので、Ｆｉｌ
ｅＩｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏｒからの
ポインタ情報を正しくセットするだけでファイルにアク
セスできる事になる。このようにＬＢＮ ｏｆ ＦＥは
ファイルのＦｉｌｅ Ｅｎｔｒｙへのポインタ情報を繋
ぎなおすために使用する。またＦｉｌｅ Ｉｄｅｎｔｉ
ｆｉｅｒ ＤｅｓｃｒｉｐｔｏｒのＦｉｌｅＩｄｅｎｔ
ｉｆｉｅｒには、Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏ
ｒのＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒからパス情報を取
り除いたものを記録する。この処理を全てのファイルに
対応するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒに対し
て行うことによってディレクトリ構造と共にファイル構
造の管理情報も復旧された事になる。なお後処理とし
て、ディスク上にどの管理情報からも参照されない管理
情報がゴミとして残る事になるので、不要な管理情報を
検出して空き領域情報を更新し未使用箇所として開放し
ても良い。
【０１１０】Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒで
管理するバックアップ対象のファイルやディレクトリを
特定するための識別情報として管理情報の記録媒体上の
記録位置情報を用いる第２の実施の形態について説明を
行なう。ここで、図１９にＰｒｉｍａｒｙ Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒの内容を示
す。Ｐｒｉｍａｒｙ Ｈｉｓｔｏｒｙ Ｔａｂｌｅ Ｄ
ｅｓｃｒｉｐｔｏｒは、Ｈｉｓｔｏｒｙ Ｔａｂｌｅを
管理するための情報やバックアップ領域の情報を管理す
る記述子である。
管理するバックアップ対象のファイルやディレクトリを
特定するための識別情報として管理情報の記録媒体上の
記録位置情報を用いる第２の実施の形態について説明を
行なう。ここで、図１９にＰｒｉｍａｒｙ Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒの内容を示
す。Ｐｒｉｍａｒｙ Ｈｉｓｔｏｒｙ Ｔａｂｌｅ Ｄ
ｅｓｃｒｉｐｔｏｒは、Ｈｉｓｔｏｒｙ Ｔａｂｌｅを
管理するための情報やバックアップ領域の情報を管理す
る記述子である。
【０１１１】Ａｒｅａ Ｓｉｚｅはバックアップ領域の
大きさをｂｙｔｅ数で表し、Ｕｉｎｔ３２型として記録
される。Ｌａｓｔ ＨＤ Ａｄｄｅｄ Ｔｉｍｅｓｔａ
ｍｐは、Ｈｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒがＨｉ
ｓｔｏｒｙ Ｔａｂｌｅに追加された最終日時を記録す
る。この情報によって、最後にＨｉｓｔｏｒｙ Ｄｅｓ
ｃｒｉｐｔｏｒを追加した日時を把握する事ができ、例
えばＵＤＦファイルシステムの管理情報との整合性を見
る場合などに利用する事ができる。ＬａｓｔＨＴ Ｕｐ
ｄａｔｅｄ Ｔｉｍｅｓｔａｍｐは、Ｈｉｓｔｏｒｙ
Ｔａｂｌｅを最後に再構築した日時を記録する。この情
報によりＨｉｓｔｏｒｙ Ｔａｂｌｅが保持する更新履
歴がいつからのものであるかを把握する事が可能とな
る。
大きさをｂｙｔｅ数で表し、Ｕｉｎｔ３２型として記録
される。Ｌａｓｔ ＨＤ Ａｄｄｅｄ Ｔｉｍｅｓｔａ
ｍｐは、Ｈｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒがＨｉ
ｓｔｏｒｙ Ｔａｂｌｅに追加された最終日時を記録す
る。この情報によって、最後にＨｉｓｔｏｒｙ Ｄｅｓ
ｃｒｉｐｔｏｒを追加した日時を把握する事ができ、例
えばＵＤＦファイルシステムの管理情報との整合性を見
る場合などに利用する事ができる。ＬａｓｔＨＴ Ｕｐ
ｄａｔｅｄ Ｔｉｍｅｓｔａｍｐは、Ｈｉｓｔｏｒｙ
Ｔａｂｌｅを最後に再構築した日時を記録する。この情
報によりＨｉｓｔｏｒｙ Ｔａｂｌｅが保持する更新履
歴がいつからのものであるかを把握する事が可能とな
る。
【０１１２】Ｎｕｍｂｅｒ ｏｆ Ｈｉｓｔｏｒｙ Ｄ
ｅｓｃｒｉｐｔｏｒｓは、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ
に記録されているＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏ
ｒの数を示し、Ｕｉｎｔ３２型で記録される。Ｈｉｓｔ
ｏｒｙ Ｔａｂｌｅ Ｓｉｚｅは、Ｈｉｓｔｏｒｙ Ｔ
ａｂｌｅのサイズをｂｙｔｅ数で表しＵｉｎｔ３２型で
記録される。Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中の全Ｈｉｓ
ｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの合計サイズをＢｙｔ
ｅ数で表す。ディスクへのＨｉｓｔｏｒｙ Ｄｅｓｃｒ
ｉｐｔｏｒの追加は論理セクタ単位で行うのが一般的な
ので、仮に１論理セクタのサイズが２ＫＢとすると、こ
のＨｉｓｔｏｒｙ Ｔａｂｌｅ Ｓｉｚｅを２ＫＢで割
り、その商がアクセスすべきバックアップ領域の最後の
論理セクタから１セクタ（ＰＨＴＤのサイズ）引いた箇
所からみた論理セクタ数となる。
ｅｓｃｒｉｐｔｏｒｓは、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ
に記録されているＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏ
ｒの数を示し、Ｕｉｎｔ３２型で記録される。Ｈｉｓｔ
ｏｒｙ Ｔａｂｌｅ Ｓｉｚｅは、Ｈｉｓｔｏｒｙ Ｔ
ａｂｌｅのサイズをｂｙｔｅ数で表しＵｉｎｔ３２型で
記録される。Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中の全Ｈｉｓ
ｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの合計サイズをＢｙｔ
ｅ数で表す。ディスクへのＨｉｓｔｏｒｙ Ｄｅｓｃｒ
ｉｐｔｏｒの追加は論理セクタ単位で行うのが一般的な
ので、仮に１論理セクタのサイズが２ＫＢとすると、こ
のＨｉｓｔｏｒｙ Ｔａｂｌｅ Ｓｉｚｅを２ＫＢで割
り、その商がアクセスすべきバックアップ領域の最後の
論理セクタから１セクタ（ＰＨＴＤのサイズ）引いた箇
所からみた論理セクタ数となる。
【０１１３】また、余りが追加を行うべき論理セクタに
既にデータが記録されている量である。つまり、追加を
行う場合には目的の論理セクタを一度読み出して、既に
記録されている情報の前にＨｉｓｔｏｒｙ Ｄｅｓｃｒ
ｉｐｔｏｒを追加して、その論理セクタの内容をディス
クに記録する事になる。
既にデータが記録されている量である。つまり、追加を
行う場合には目的の論理セクタを一度読み出して、既に
記録されている情報の前にＨｉｓｔｏｒｙ Ｄｅｓｃｒ
ｉｐｔｏｒを追加して、その論理セクタの内容をディス
クに記録する事になる。
【０１１４】なお、図中の、ＲＢＰはＲｅｌａｔｉｖｅ
Ｂｙｔｅ Ｐｏｓｉｔｉｏｎを意味し、先頭から見た
対応する管理項目の開始位置を示す情報で、Ｌｅｎはそ
の管理項目の大きさをＢｙｔｅで表し、Ｆｉｅｌｄ Ｎ
ａｍｅは管理項目名、Ｃｏｎｔｅｎｔｓは、管理項目が
どのような形式で記録されなければならないかというこ
とを示す。Ｃｏｎｔｅｎｔｓで用いられているデータ型
のうち、Ｕｉｎｔ８は符号無し８ｂｉｔ整数、Ｕｉｎｔ
１６は符号無し１６ｂｉｔ整数、Ｕｉｎｔ３２は符号無
し３２ｂｉｔ整数を意味する。Ｓｔｒｉｎｇは文字列を
格納するためのデータ型、Ｔｉｍｅｓｔａｍｐは日時情
報を格納する型である。
Ｂｙｔｅ Ｐｏｓｉｔｉｏｎを意味し、先頭から見た
対応する管理項目の開始位置を示す情報で、Ｌｅｎはそ
の管理項目の大きさをＢｙｔｅで表し、Ｆｉｅｌｄ Ｎ
ａｍｅは管理項目名、Ｃｏｎｔｅｎｔｓは、管理項目が
どのような形式で記録されなければならないかというこ
とを示す。Ｃｏｎｔｅｎｔｓで用いられているデータ型
のうち、Ｕｉｎｔ８は符号無し８ｂｉｔ整数、Ｕｉｎｔ
１６は符号無し１６ｂｉｔ整数、Ｕｉｎｔ３２は符号無
し３２ｂｉｔ整数を意味する。Ｓｔｒｉｎｇは文字列を
格納するためのデータ型、Ｔｉｍｅｓｔａｍｐは日時情
報を格納する型である。
【０１１５】図２０にＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐ
ｔｏｒの内容を示す。Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐ
ｔｏｒは、論理ファイルシステムにおけるファイルやデ
ィレクトリの管理情報のバックアップ情報であり、対応
するファイルやディレクトリにアクセスするための必要
最低限の情報で構成されている。
ｔｏｒの内容を示す。Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐ
ｔｏｒは、論理ファイルシステムにおけるファイルやデ
ィレクトリの管理情報のバックアップ情報であり、対応
するファイルやディレクトリにアクセスするための必要
最低限の情報で構成されている。
【０１１６】Ｆｉｌｅ Ｓｉｚｅは、バックアップの対
象となるファイルのファイルサイズをｂｙｔｅ数で示
し、Ｕｉｎｔ３２型で記録される。具体的には、対応す
るＵＤＦファイルシステムのＦｉｌｅ Ｅｎｔｒｙ内の
ファイルサイズの情報を示すＩｎｆｏｒｍａｔｉｏｎ
Ｌｅｎｇｔｈと同じ値を記録する。Ｍｏｄｉｆｉｃａｔ
ｉｏｎ Ｄａｔｅ ａｎｄ Ｔｉｍｅは、このファイル
やディレクトリが追加、変更、削除された時刻を示し、
Ｔｉｍｅｓｔａｍｐ型で記録される。バックアップ対象
がファイルの場合、対応するＵＤＦファイルシステムの
Ｆｉｌｅ Ｅｎｔｒｙ内の変更日時を示すＭｏｄｉｆｉ
ｃａｔｉｏｎ Ｄａｔｅ ａｎｄ Ｔｉｍｅと同じ値
を、ディレクトリの場合はＦｉｌｅ Ｅｎｔｒｙ内の作
成日時を示すＡｃｃｅｓｓ Ｄａｔａ ａｎｄ Ｔｉｍ
ｅと同じ値を記録する。また、ファイルやディレクトリ
の削除を示すＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの
場合は、実際の削除の日時を記録する。
象となるファイルのファイルサイズをｂｙｔｅ数で示
し、Ｕｉｎｔ３２型で記録される。具体的には、対応す
るＵＤＦファイルシステムのＦｉｌｅ Ｅｎｔｒｙ内の
ファイルサイズの情報を示すＩｎｆｏｒｍａｔｉｏｎ
Ｌｅｎｇｔｈと同じ値を記録する。Ｍｏｄｉｆｉｃａｔ
ｉｏｎ Ｄａｔｅ ａｎｄ Ｔｉｍｅは、このファイル
やディレクトリが追加、変更、削除された時刻を示し、
Ｔｉｍｅｓｔａｍｐ型で記録される。バックアップ対象
がファイルの場合、対応するＵＤＦファイルシステムの
Ｆｉｌｅ Ｅｎｔｒｙ内の変更日時を示すＭｏｄｉｆｉ
ｃａｔｉｏｎ Ｄａｔｅ ａｎｄ Ｔｉｍｅと同じ値
を、ディレクトリの場合はＦｉｌｅ Ｅｎｔｒｙ内の作
成日時を示すＡｃｃｅｓｓ Ｄａｔａ ａｎｄ Ｔｉｍ
ｅと同じ値を記録する。また、ファイルやディレクトリ
の削除を示すＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの
場合は、実際の削除の日時を記録する。
【０１１７】ＬＢＮ ｏｆ ＦＥは、バックアップ対象
となるファイルやディレクトリのＵＤＦファイルシステ
ムでのＦｉｌｅ Ｅｎｔｒｙの記録位置を示すＵＤＦパ
ーティション内の論理ブロック番号を示し、Ｕｉｎｔ３
２型で記録する。Ａｔｔｒｉｂｕｔｅｓは、バックアッ
プのイベント種別およびバックアップの対象がファイル
なのかディレクトリなのかをＵｉｎｔ１６型で示す。Ｂ
ｉｔ ０は、バックアップ対象がファイルなのかディレ
クトリなのかを示し、０の場合はファイル、１の場合は
ディレクトリを示す。Ｂｉｔ１と２は、符号無しの２ｂ
ｉｔの情報として扱い、この２ｂｉｔが０の場合「作
成」、１の場合は「変更」、２の場合は「削除」を示
す。
となるファイルやディレクトリのＵＤＦファイルシステ
ムでのＦｉｌｅ Ｅｎｔｒｙの記録位置を示すＵＤＦパ
ーティション内の論理ブロック番号を示し、Ｕｉｎｔ３
２型で記録する。Ａｔｔｒｉｂｕｔｅｓは、バックアッ
プのイベント種別およびバックアップの対象がファイル
なのかディレクトリなのかをＵｉｎｔ１６型で示す。Ｂ
ｉｔ ０は、バックアップ対象がファイルなのかディレ
クトリなのかを示し、０の場合はファイル、１の場合は
ディレクトリを示す。Ｂｉｔ１と２は、符号無しの２ｂ
ｉｔの情報として扱い、この２ｂｉｔが０の場合「作
成」、１の場合は「変更」、２の場合は「削除」を示
す。
【０１１８】Ｌｅｎｇｔｈ ｏｆ Ａｌｌｏｃａｔｉｏ
ｎ Ｄｅｓｃｒｉｐｔｏｒｓは、Ａｌｌｏｃａｔｉｏｎ
Ｄｅｓｃｒｉｐｔｏｒｓフィールドの長さをｂｙｔｅ
数で示し、Ｕｉｎｔ３２型で記録する。バックアップ対
象であるファイルやディレクトリのＵＤＦファイルシス
テムでのＦｉｌｅ ＥｎｔｒｙのＬｅｎｇｔｈ ｏｆＡ
ｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓと同じ値
を記録する。Ａｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔ
ｏｒｓ（ＡＤ）はディスク上のデータの記録位置を管理
するための管理構造であり、Ｕｉｎｔ３２型のＥｘｔｅ
ｎｔ Ｌｅｎｇｔｈと、Ｕｉｎｔ３２型のＥｘｔｅｎｔ
Ｐｏｓｉｔｉｏｎによって構成される。ここでは、Ｅ
ｘｔｅｎｔ ＬｅｎｇｔｈとＥｘｔｅｎｔ Ｐｏｓｉｔ
ｉｏｎを合わせてＳｈｏｒｔ＿ａｄ型として扱うものと
する。
ｎ Ｄｅｓｃｒｉｐｔｏｒｓは、Ａｌｌｏｃａｔｉｏｎ
Ｄｅｓｃｒｉｐｔｏｒｓフィールドの長さをｂｙｔｅ
数で示し、Ｕｉｎｔ３２型で記録する。バックアップ対
象であるファイルやディレクトリのＵＤＦファイルシス
テムでのＦｉｌｅ ＥｎｔｒｙのＬｅｎｇｔｈ ｏｆＡ
ｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓと同じ値
を記録する。Ａｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔ
ｏｒｓ（ＡＤ）はディスク上のデータの記録位置を管理
するための管理構造であり、Ｕｉｎｔ３２型のＥｘｔｅ
ｎｔ Ｌｅｎｇｔｈと、Ｕｉｎｔ３２型のＥｘｔｅｎｔ
Ｐｏｓｉｔｉｏｎによって構成される。ここでは、Ｅ
ｘｔｅｎｔ ＬｅｎｇｔｈとＥｘｔｅｎｔ Ｐｏｓｉｔ
ｉｏｎを合わせてＳｈｏｒｔ＿ａｄ型として扱うものと
する。
【０１１９】Ｅｘｔｅｎｔ Ｌｅｎｇｔｈは、分断の長
さをｂｙｔｅ数で示し、Ｅｘｔｅｎｔ Ｐｏｓｉｔｉｏ
ｎは分断の開始論理ブロック番号が記録される。１つの
ファイルであってもファイルに対応する実データはディ
スク上で分断されて記録する事も可能であるため、ファ
イルを構成する分断の数だけＡｌｌｏｃａｔｉｏｎＤｅ
ｓｃｒｉｐｔｏｒｓが記録されることになる。
さをｂｙｔｅ数で示し、Ｅｘｔｅｎｔ Ｐｏｓｉｔｉｏ
ｎは分断の開始論理ブロック番号が記録される。１つの
ファイルであってもファイルに対応する実データはディ
スク上で分断されて記録する事も可能であるため、ファ
イルを構成する分断の数だけＡｌｌｏｃａｔｉｏｎＤｅ
ｓｃｒｉｐｔｏｒｓが記録されることになる。
【０１２０】実際には、１つのＡｌｌｏｃａｔｉｏｎ
Ｄｅｓｃｒｉｐｔｏｒｓが８ｂｙｔｅなので、Ｌｅｎｇ
ｔｈ ｏｆ Ａｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔ
ｏｒｓで示される値を８で割ることによってＡｌｌｏｃ
ａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓの数が求まる。こ
のフィールドには、バックアップ対象のＵＤＦファイル
システムでのＦｉｌｅ Ｅｎｔｒｙ内のＡｌｌｏｃａｔ
ｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓと同じ内容を記録す
る。
Ｄｅｓｃｒｉｐｔｏｒｓが８ｂｙｔｅなので、Ｌｅｎｇ
ｔｈ ｏｆ Ａｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔ
ｏｒｓで示される値を８で割ることによってＡｌｌｏｃ
ａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓの数が求まる。こ
のフィールドには、バックアップ対象のＵＤＦファイル
システムでのＦｉｌｅ Ｅｎｔｒｙ内のＡｌｌｏｃａｔ
ｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓと同じ内容を記録す
る。
【０１２１】以上のような管理情報を用いた実際の実施
例を説明して行く。図２１に示すようなディレクトリ階
層のファイルやディレクトリがある場合、対応するＵＤ
Ｆファイルシステムが定義するパーティション内の論理
ファイルシステムの管理情報とデータ配置の様子の例を
図２２に示す。
例を説明して行く。図２１に示すようなディレクトリ階
層のファイルやディレクトリがある場合、対応するＵＤ
Ｆファイルシステムが定義するパーティション内の論理
ファイルシステムの管理情報とデータ配置の様子の例を
図２２に示す。
【０１２２】パーティション内の先頭から、パーティシ
ョン内の空き領域情報を管理するＳｐａｃｅ Ｂｉｔｍ
ａｐ Ｄｅｓｃｒｉｐｔｏｒ（ＳＢＤ）、ファイルシス
テムの基本管理情報であり、Ｒｏｏｔディレクトリを管
理するＦｉｌｅ Ｅｎｔｒｙ（ＦＥ Ｒｏｏｔ）へのポ
インタ情報を持つＦｉｌｅ Ｓｅｔ Ｄｅｓｃｒｉｐｔ
ｏｒ（ＦＳＤ）、Ｆｉｌｅ Ｓｅｔ Ｄｅｓｃｒｉｐｔ
ｏｒが終った事を示すＴｅｒｍｉｎａｔｉｎｇ Ｄｅｓ
ｃｒｉｐｔｏｒ（ＴＤ）が記録されている。
ョン内の空き領域情報を管理するＳｐａｃｅ Ｂｉｔｍ
ａｐ Ｄｅｓｃｒｉｐｔｏｒ（ＳＢＤ）、ファイルシス
テムの基本管理情報であり、Ｒｏｏｔディレクトリを管
理するＦｉｌｅ Ｅｎｔｒｙ（ＦＥ Ｒｏｏｔ）へのポ
インタ情報を持つＦｉｌｅ Ｓｅｔ Ｄｅｓｃｒｉｐｔ
ｏｒ（ＦＳＤ）、Ｆｉｌｅ Ｓｅｔ Ｄｅｓｃｒｉｐｔ
ｏｒが終った事を示すＴｅｒｍｉｎａｔｉｎｇ Ｄｅｓ
ｃｒｉｐｔｏｒ（ＴＤ）が記録されている。
【０１２３】また、Ｒｏｏｔディレクトリ、ＤＡＴＡデ
ィレクトリをそれぞれ管理するＦｉｌｅ Ｅｎｔｒｙ
（ＦＥ）と、各ディレクトリの下に定義されるファイル
のファイル名や属性情報、そしてそのファイルあるいは
下位のディレクトリを管理するＦｉｌｅ Ｅｎｔｒｙ
（ＦＥ）へのポインタ情報であるＦｉｌｅ Ｉｄｅｎｔ
ｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏｒ（ＦＩＤ）、Ｒｏｏ
ｔディレクトリの下に定義されているＲＥＡＤＭＥ．Ｔ
ＸＴを管理するＦｉｌｅ Ｅｎｔｒｙ（ＦＥ）とＤＡＴ
Ａディレクトリの下に定義される、ＦＩＬＥ１．ＤＡＴ
とＦＩＬＥ２．ＤＡＴを管理するＦｉｌｅ Ｅｎｔｒｙ
（ＦＥ）が記録されている。
ィレクトリをそれぞれ管理するＦｉｌｅ Ｅｎｔｒｙ
（ＦＥ）と、各ディレクトリの下に定義されるファイル
のファイル名や属性情報、そしてそのファイルあるいは
下位のディレクトリを管理するＦｉｌｅ Ｅｎｔｒｙ
（ＦＥ）へのポインタ情報であるＦｉｌｅ Ｉｄｅｎｔ
ｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏｒ（ＦＩＤ）、Ｒｏｏ
ｔディレクトリの下に定義されているＲＥＡＤＭＥ．Ｔ
ＸＴを管理するＦｉｌｅ Ｅｎｔｒｙ（ＦＥ）とＤＡＴ
Ａディレクトリの下に定義される、ＦＩＬＥ１．ＤＡＴ
とＦＩＬＥ２．ＤＡＴを管理するＦｉｌｅ Ｅｎｔｒｙ
（ＦＥ）が記録されている。
【０１２４】なお、Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔ
ｏｒ内のＬＢＮ ｏｆ ＦＥフィールドには、このファ
イルやディレクトリを管理するＦｉｌｅ Ｅｎｔｒｙが
記録された論理ブロック番号が記録されることになる。
図の例ではＲｏｏｔディレクトリ、 ＲＥＡＤＭＥ．Ｔ
ＸＴ、ＤＡＴＡディレクトリ、ＦＩＬＥ１．ＤＡＴ、Ｆ
ＩＬＥ２．ＤＡＴのＦｉｌｅ Ｅｎｔｒｙ（ＦＥ）はそ
れぞれ、ＬＢＮ（論理ブロック番号）１００、２００、
３００、４００、５００に記録されている。
ｏｒ内のＬＢＮ ｏｆ ＦＥフィールドには、このファ
イルやディレクトリを管理するＦｉｌｅ Ｅｎｔｒｙが
記録された論理ブロック番号が記録されることになる。
図の例ではＲｏｏｔディレクトリ、 ＲＥＡＤＭＥ．Ｔ
ＸＴ、ＤＡＴＡディレクトリ、ＦＩＬＥ１．ＤＡＴ、Ｆ
ＩＬＥ２．ＤＡＴのＦｉｌｅ Ｅｎｔｒｙ（ＦＥ）はそ
れぞれ、ＬＢＮ（論理ブロック番号）１００、２００、
３００、４００、５００に記録されている。
【０１２５】ファイルおよびディレクトリのＦｉｌｅ
Ｅｎｔｒｙはそれぞれ対応するデータが記録されている
ディスク上の分断情報をＥｘｔｅｎｔとしてＡｌｌｏｃ
ａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓによって管理して
いる。例えば、図２２の例においては、ＦＩＬＥ１．Ｄ
ＡＴに対応するデータはディスクでは分断して記録され
ており、Ｅｘｔｅｎｔ４および５によって構成されてい
る。またＦＩＬＥ２．ＤＡＴに対応するディスク上のデ
ータは連続的に記録されており、Ｅｘｔｅｎｔ６によっ
て構成されている。
Ｅｎｔｒｙはそれぞれ対応するデータが記録されている
ディスク上の分断情報をＥｘｔｅｎｔとしてＡｌｌｏｃ
ａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓによって管理して
いる。例えば、図２２の例においては、ＦＩＬＥ１．Ｄ
ＡＴに対応するデータはディスクでは分断して記録され
ており、Ｅｘｔｅｎｔ４および５によって構成されてい
る。またＦＩＬＥ２．ＤＡＴに対応するディスク上のデ
ータは連続的に記録されており、Ｅｘｔｅｎｔ６によっ
て構成されている。
【０１２６】このような状況のディレクトリ階層に対応
するＨｉｓｔｏｒｙ Ｔａｂｌｅの例を図２３に示す。
この図では、一番下にＰｒｉｍａｒｙ Ｈｉｓｔｏｒｙ
Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒが配置されてお
り、Ｈｉｓｔｏｒｙ Ｔａｂｌｅの最後尾は図の一番上
に相当する。この例では、Ｒｏｏｔディレクトリ
（￥）、ＲＥＡＤＭＥ．ＴＸＴ、￥ＤＡＴＡディレクト
リ、ＦＩＬＥ１．ＤＡＴ、ＦＩＬＥ２．ＤＡＴの順番で
作成された様子を示している。一番下の枠を除いて１つ
の枠が１つのＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒに
対応し、全てのＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
をまとめてＨｉｓｔｏｒｙ Ｔａｂｌｅを構成する。
するＨｉｓｔｏｒｙ Ｔａｂｌｅの例を図２３に示す。
この図では、一番下にＰｒｉｍａｒｙ Ｈｉｓｔｏｒｙ
Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒが配置されてお
り、Ｈｉｓｔｏｒｙ Ｔａｂｌｅの最後尾は図の一番上
に相当する。この例では、Ｒｏｏｔディレクトリ
（￥）、ＲＥＡＤＭＥ．ＴＸＴ、￥ＤＡＴＡディレクト
リ、ＦＩＬＥ１．ＤＡＴ、ＦＩＬＥ２．ＤＡＴの順番で
作成された様子を示している。一番下の枠を除いて１つ
の枠が１つのＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒに
対応し、全てのＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
をまとめてＨｉｓｔｏｒｙ Ｔａｂｌｅを構成する。
【０１２７】図２４に図２３に示す状態から、ＤＡＴＡ
ディレクトリの下にＦＩＬＥ３．ＤＡＴというファイル
が作成（追加）された場合の様子を示す。ＦＩＬＥ３．
ＤＡＴがＵＤＦファイルシステムで作成されると、それ
に対応するＨｉｓｔｏｒｙＤｅｓｃｒｉｐｔｏｒがＨｉ
ｓｔｏｒｙ Ｔａｂｌｅの最後尾（ディスク上では最前
部）に追加される。
ディレクトリの下にＦＩＬＥ３．ＤＡＴというファイル
が作成（追加）された場合の様子を示す。ＦＩＬＥ３．
ＤＡＴがＵＤＦファイルシステムで作成されると、それ
に対応するＨｉｓｔｏｒｙＤｅｓｃｒｉｐｔｏｒがＨｉ
ｓｔｏｒｙ Ｔａｂｌｅの最後尾（ディスク上では最前
部）に追加される。
【０１２８】この際、Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐ
ｔｏｒのＬＢＮ ｏｆ ＦＥにはＦＩＬＥ３．ＤＡＴを
管理するＦｉｌｅ Ｅｎｔｒｙの記録されたディスク上
での位置情報が記録され、Ｔｉｍｅｓｔａｍｐにはファ
イルの作成された日時、Ａｔｔｒｉｂｕｔｅにはファイ
ルおよび作成を示す００００ｈ、Ｆｉｌｅ Ｓｉｚｅに
はＦＩＬＥ３．ＤＡＴのファイルサイズを、Ｌｅｎｇｔ
ｈ ｏｆ Ａｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏ
ｒｓには、ＦＩＬＥ３．ＤＡＴに対応するデータのディ
スク上での分断数を８倍した値を、そしてＡｌｌｏｃａ
ｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓ（ＡＤ）にはそれぞ
れの分断に関する位置情報を記録する事になる。ここで
は、ＦＩＬＥ３．ＤＡＴはＥｘｔｅｎｔ７のみによって
構成されている（連続して記録されている）ことにな
る。
ｔｏｒのＬＢＮ ｏｆ ＦＥにはＦＩＬＥ３．ＤＡＴを
管理するＦｉｌｅ Ｅｎｔｒｙの記録されたディスク上
での位置情報が記録され、Ｔｉｍｅｓｔａｍｐにはファ
イルの作成された日時、Ａｔｔｒｉｂｕｔｅにはファイ
ルおよび作成を示す００００ｈ、Ｆｉｌｅ Ｓｉｚｅに
はＦＩＬＥ３．ＤＡＴのファイルサイズを、Ｌｅｎｇｔ
ｈ ｏｆ Ａｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏ
ｒｓには、ＦＩＬＥ３．ＤＡＴに対応するデータのディ
スク上での分断数を８倍した値を、そしてＡｌｌｏｃａ
ｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓ（ＡＤ）にはそれぞ
れの分断に関する位置情報を記録する事になる。ここで
は、ＦＩＬＥ３．ＤＡＴはＥｘｔｅｎｔ７のみによって
構成されている（連続して記録されている）ことにな
る。
【０１２９】図２５に、図２４で示された状態から、さ
らにＤＡＴＡディレクトリの下のＦＩＬＥ２．ＤＡＴの
内容が変更された場合の様子を示す。ＵＤＦファイルシ
ステムにおいてＦＩＬＥ２．ＤＡＴのディスク上の位置
が変更になったり、内容が変更になった場合、Ｈｉｓｔ
ｏｒｙ Ｔａｂｌｅの最後尾（ディスク上では最前部）
に、対応するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを
追加する。この際、Ａｔｔｒｉｂｕｔｅにはファイルお
よび変更を示す０００２ｈを記録する。また、ＦＩＬＥ
２．ＤＡＴのディスク上の位置が変更となり、Ａｌｌｏ
ｃａｔｉｏｎＤｅｓｃｒｉｐｔｏｒｓ（ＡＤ）が管理す
る分断がＥｘｔｅｎｔ８に変更になる。
らにＤＡＴＡディレクトリの下のＦＩＬＥ２．ＤＡＴの
内容が変更された場合の様子を示す。ＵＤＦファイルシ
ステムにおいてＦＩＬＥ２．ＤＡＴのディスク上の位置
が変更になったり、内容が変更になった場合、Ｈｉｓｔ
ｏｒｙ Ｔａｂｌｅの最後尾（ディスク上では最前部）
に、対応するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを
追加する。この際、Ａｔｔｒｉｂｕｔｅにはファイルお
よび変更を示す０００２ｈを記録する。また、ＦＩＬＥ
２．ＤＡＴのディスク上の位置が変更となり、Ａｌｌｏ
ｃａｔｉｏｎＤｅｓｃｒｉｐｔｏｒｓ（ＡＤ）が管理す
る分断がＥｘｔｅｎｔ８に変更になる。
【０１３０】このＦＩＬＥ２．ＤＡＴの変更に関するＨ
ｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが追加になった時
点で、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ内に既に存在してい
る、ＦＩＬＥ２．ＤＡＴを作成した際のＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒが古い情報となり、更新履歴情
報となる。
ｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが追加になった時
点で、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ内に既に存在してい
る、ＦＩＬＥ２．ＤＡＴを作成した際のＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒが古い情報となり、更新履歴情
報となる。
【０１３１】図２６に、図２５で示された状態から、さ
らにＤＡＴＡディレクトリの下のＦＩＬＥ１．ＤＡＴを
削除した場合の様子を示す。ＵＤＦファイルシステムに
おいてＦＩＬＥ１．ＤＡＴが削除された場合、Ｈｉｓｔ
ｏｒｙ Ｔａｂｌｅの最後尾（ディスク上では最前部）
に対応するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを追
加する。この際、Ａｔｔｒｉｂｕｔｅにはファイルおよ
び削除を示す０００４ｈを記録し、Ａｌｌｏｃａｔｉｏ
ｎ Ｄｅｓｃｒｉｐｔｏｒｓ（ＡＤ）には、削除する直
前のデータの位置情報を記録する。削除されるデータで
あるため直前の記録位置を記録しないようにしても良
い。このＦＩＬＥ１．ＤＡＴの削除に関するＨｉｓｔｏ
ｒｙ Ｄｅｓｃｒｉｐｔｏｒが追加になった時点で、Ｈ
ｉｓｔｏｒｙ Ｔａｂｌｅ内に既に存在しているＦＩＬ
Ｅ１．ＤＡＴを作成した際のＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒが古い情報となり、更新履歴情報となる。
らにＤＡＴＡディレクトリの下のＦＩＬＥ１．ＤＡＴを
削除した場合の様子を示す。ＵＤＦファイルシステムに
おいてＦＩＬＥ１．ＤＡＴが削除された場合、Ｈｉｓｔ
ｏｒｙ Ｔａｂｌｅの最後尾（ディスク上では最前部）
に対応するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを追
加する。この際、Ａｔｔｒｉｂｕｔｅにはファイルおよ
び削除を示す０００４ｈを記録し、Ａｌｌｏｃａｔｉｏ
ｎ Ｄｅｓｃｒｉｐｔｏｒｓ（ＡＤ）には、削除する直
前のデータの位置情報を記録する。削除されるデータで
あるため直前の記録位置を記録しないようにしても良
い。このＦＩＬＥ１．ＤＡＴの削除に関するＨｉｓｔｏ
ｒｙ Ｄｅｓｃｒｉｐｔｏｒが追加になった時点で、Ｈ
ｉｓｔｏｒｙ Ｔａｂｌｅ内に既に存在しているＦＩＬ
Ｅ１．ＤＡＴを作成した際のＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒが古い情報となり、更新履歴情報となる。
【０１３２】なお、図２４乃至２６においてイベント種
別が作成、変更、削除について説明したが、ファイルシ
ステム上では例えば、ファイルやディレクトリのコピー
や移動あるいは名称変更なども起きる。これらのイベン
トは基本的に前述の作成、変更、削除を組み合わせるこ
とによって更新情報を表現する事が可能である。例え
ば、あるファイルの移動であれば、移動元のファイルに
対応する削除を表すＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔ
ｏｒを作成し、移動先のファイルに対応する作成を表す
Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを作成する。ま
た、同様に名称変更でも、名称を変更する前のファイル
に対応する削除を表すＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐ
ｔｏｒを作成し、名称変更後のファイルに対応する作成
を表すＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを追加す
れば良いことになる。
別が作成、変更、削除について説明したが、ファイルシ
ステム上では例えば、ファイルやディレクトリのコピー
や移動あるいは名称変更なども起きる。これらのイベン
トは基本的に前述の作成、変更、削除を組み合わせるこ
とによって更新情報を表現する事が可能である。例え
ば、あるファイルの移動であれば、移動元のファイルに
対応する削除を表すＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔ
ｏｒを作成し、移動先のファイルに対応する作成を表す
Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを作成する。ま
た、同様に名称変更でも、名称を変更する前のファイル
に対応する削除を表すＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐ
ｔｏｒを作成し、名称変更後のファイルに対応する作成
を表すＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを追加す
れば良いことになる。
【０１３３】ここで、Ｈｉｓｔｏｒｙ Ｔａｂｌｅを再
構築する場合の様子を図２７に示す。Ｈｉｓｔｏｒｙ
Ｔａｂｌｅには、ＵＤＦファイルシステムにおいてファ
イルに関する作成、変更、削除、またディレクトリに関
する作成、削除と言ったイベントが発生する度にＨｉｓ
ｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが単純に追加になって
いく。Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを記録す
る領域は決まっているので、状況に応じてＨｉｓｔｏｒ
ｙ Ｔａｂｌｅから不要な情報を削除しＨｉｓｔｏｒｙ
Ｔａｂｌｅを再構築する事も必要となる。
構築する場合の様子を図２７に示す。Ｈｉｓｔｏｒｙ
Ｔａｂｌｅには、ＵＤＦファイルシステムにおいてファ
イルに関する作成、変更、削除、またディレクトリに関
する作成、削除と言ったイベントが発生する度にＨｉｓ
ｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが単純に追加になって
いく。Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを記録す
る領域は決まっているので、状況に応じてＨｉｓｔｏｒ
ｙ Ｔａｂｌｅから不要な情報を削除しＨｉｓｔｏｒｙ
Ｔａｂｌｅを再構築する事も必要となる。
【０１３４】この場合は、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ
の最後部（ディスク上では最前部）のＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒから順番に見て行き、同一のファ
イルやディレクトリに関する情報つまり更新履歴に相当
するＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔ
ｏｒｙ Ｔａｂｌｅから削除する。また、Ａｔｔｒｉｂ
ｕｔｅが削除のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
に関しても同様に削除する。
の最後部（ディスク上では最前部）のＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒから順番に見て行き、同一のファ
イルやディレクトリに関する情報つまり更新履歴に相当
するＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔ
ｏｒｙ Ｔａｂｌｅから削除する。また、Ａｔｔｒｉｂ
ｕｔｅが削除のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
に関しても同様に削除する。
【０１３５】図の例では、左側のＨｉｓｔｏｒｙ Ｔａ
ｂｌｅから更新履歴に相当する「ＦＩＬＥ２．ＤＡＴ作
成」と「ＦＩＬＥ１．ＤＡＴ作成」と、「ＦＩＬＥ１．
ＤＡＴ削除」のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
を削除し、右のＨｉｓｔｏｒｙ Ｔａｂｌｅのように最
構築する。この際、残ったＨｉｓｔｏｒｙ Ｄｅｓｃｒ
ｉｐｔｏｒのＡｔｔｒｉｂｕｔｅは全て作成に変更する
事になる。
ｂｌｅから更新履歴に相当する「ＦＩＬＥ２．ＤＡＴ作
成」と「ＦＩＬＥ１．ＤＡＴ作成」と、「ＦＩＬＥ１．
ＤＡＴ削除」のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
を削除し、右のＨｉｓｔｏｒｙ Ｔａｂｌｅのように最
構築する。この際、残ったＨｉｓｔｏｒｙ Ｄｅｓｃｒ
ｉｐｔｏｒのＡｔｔｒｉｂｕｔｅは全て作成に変更する
事になる。
【０１３６】ここで、処理の詳細をフローチャートで説
明する。図２８にＵＤＦファイルシステムにおいてファ
イルやディレクトリの作成、変更、削除と言ったイベン
トが発生した場合の処理の流れを示す。
明する。図２８にＵＤＦファイルシステムにおいてファ
イルやディレクトリの作成、変更、削除と言ったイベン
トが発生した場合の処理の流れを示す。
【０１３７】ステップＳ７０において、ファイルやディ
レクトリの作成、変更、削除イベントが発生すると、ス
テップＳ７１においてＰｒｉｍａｒｙ Ｈｉｓｔｏｒｙ
Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒを読み出し、Ｈｉ
ｓｔｏｒｙ Ｔａｂｌｅの最後部（ディスク上では最前
部）を把握する。
レクトリの作成、変更、削除イベントが発生すると、ス
テップＳ７１においてＰｒｉｍａｒｙ Ｈｉｓｔｏｒｙ
Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒを読み出し、Ｈｉ
ｓｔｏｒｙ Ｔａｂｌｅの最後部（ディスク上では最前
部）を把握する。
【０１３８】具体的には、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ
中のＨｉｓｔｏｒｙ ＴａｂｌｅＳｉｚｅからＨｉｓｔ
ｏｒｙ Ｔａｂｌｅの最後尾の位置を把握する事が可能
となる。ステップＳ７２において、ファイルやディレク
トリに対応するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
をＨｉｓｔｏｒｙ Ｔａｂｌｅの最後に追加する。この
際Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒには、図２１
に示すように、ファイルやディレクトリを管理するＦｉ
ｌｅ Ｅｎｔｒｙの記録位置をＬＢＮ ｏｆＦＥに、発
生したイベントの種類およびファイルかディレクトリな
のかをＡｔｔｒｉｂｕｔｅ、イベントが発生した日時、
イベントが発生した対象のＵＤＦファイルシステムにお
けるファイルの管理するディスク上の分断を管理する形
で、Ａｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓが
記録される。ステップＳ７３において、Ｐｒｉｍａｒｙ
Ｈｉｓｔｏｒｙ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒ
内の最後尾（ディスク上では最前部）にＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒを追加した時刻を示すＬａｓｔ
ＨＤ Ａｄｄｅｄ Ｔｉｍｅｓｔａｍｐと、Ｈｉｓｔ
ｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ数、Ｈｉｓｔｏｒｙ Ｔ
ａｂｌｅ Ｓｉｚｅを更新して処理を終了する。ＵＤＦ
におけるファイルに関するイベントが発生した際の処理
は以上のように、単純なＨｉｓｔｏｒｙ Ｄｅｓｃｒｉ
ｐｔｏｒの追加処理となる。
中のＨｉｓｔｏｒｙ ＴａｂｌｅＳｉｚｅからＨｉｓｔ
ｏｒｙ Ｔａｂｌｅの最後尾の位置を把握する事が可能
となる。ステップＳ７２において、ファイルやディレク
トリに対応するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
をＨｉｓｔｏｒｙ Ｔａｂｌｅの最後に追加する。この
際Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒには、図２１
に示すように、ファイルやディレクトリを管理するＦｉ
ｌｅ Ｅｎｔｒｙの記録位置をＬＢＮ ｏｆＦＥに、発
生したイベントの種類およびファイルかディレクトリな
のかをＡｔｔｒｉｂｕｔｅ、イベントが発生した日時、
イベントが発生した対象のＵＤＦファイルシステムにお
けるファイルの管理するディスク上の分断を管理する形
で、Ａｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓが
記録される。ステップＳ７３において、Ｐｒｉｍａｒｙ
Ｈｉｓｔｏｒｙ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒ
内の最後尾（ディスク上では最前部）にＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒを追加した時刻を示すＬａｓｔ
ＨＤ Ａｄｄｅｄ Ｔｉｍｅｓｔａｍｐと、Ｈｉｓｔ
ｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ数、Ｈｉｓｔｏｒｙ Ｔ
ａｂｌｅ Ｓｉｚｅを更新して処理を終了する。ＵＤＦ
におけるファイルに関するイベントが発生した際の処理
は以上のように、単純なＨｉｓｔｏｒｙ Ｄｅｓｃｒｉ
ｐｔｏｒの追加処理となる。
【０１３９】ファイルの場合とは異なり、バックアップ
対象がディレクトリの場合は、ディレクトリの存在のみ
をＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒで管理するこ
とにし、Ｆｉｌｅ ＳｉｚｅやＡｌｌｏｃａｔｉｏｎ
Ｄｅｓｃｒｉｐｔｏｒｓを記録しないようにしても良
い。
対象がディレクトリの場合は、ディレクトリの存在のみ
をＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒで管理するこ
とにし、Ｆｉｌｅ ＳｉｚｅやＡｌｌｏｃａｔｉｏｎ
Ｄｅｓｃｒｉｐｔｏｒｓを記録しないようにしても良
い。
【０１４０】このフローチャートでは、ＵＤＦのファイ
ルシステムにおいてファイルやディレクトリの作成、変
更、削除と言ったイベントが発生する度に対応するＨｉ
ｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔｏｒｙ
Ｔａｂｌｅに追加する説明になっているが、例えば電源
投入時やディスクを装着した時にＰｒｉｍａｒｙ Ｈｉ
ｓｔｏｒｙ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒを読み
出し、電源を切断する時やディスクを排出する時などに
その期間中に発生した全てのイベントに対応するＨｉｓ
ｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをまとめてＨｉｓｔｏ
ｒｙ Ｔａｂｌｅに追加しＰｒｉｍａｒｙ Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒを更新し記録
しても良い。つまりＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔ
ｏｒをメモリ上に保持しておき、あるタイミングで一度
にディスク上のＨｉｓｔｏｒｙＴａｂｌｅを更新しても
構わないものとする。
ルシステムにおいてファイルやディレクトリの作成、変
更、削除と言ったイベントが発生する度に対応するＨｉ
ｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔｏｒｙ
Ｔａｂｌｅに追加する説明になっているが、例えば電源
投入時やディスクを装着した時にＰｒｉｍａｒｙ Ｈｉ
ｓｔｏｒｙ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒを読み
出し、電源を切断する時やディスクを排出する時などに
その期間中に発生した全てのイベントに対応するＨｉｓ
ｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをまとめてＨｉｓｔｏ
ｒｙ Ｔａｂｌｅに追加しＰｒｉｍａｒｙ Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒを更新し記録
しても良い。つまりＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔ
ｏｒをメモリ上に保持しておき、あるタイミングで一度
にディスク上のＨｉｓｔｏｒｙＴａｂｌｅを更新しても
構わないものとする。
【０１４１】このように、ファイルやディレクトリに関
するイベントが発生する度にＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒを追記する訳である。ＵＤＦにおいてファ
イルやディレクトリにアクセスする場合、まずＦｉｌｅ
Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏｒにアク
セスしディレクトリ内に記録されているファイルやディ
レクトリ名を把握する。アクセスしたいファイルやディ
レクトリに対応するＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ
Ｄｅｓｃｒｉｐｔｏｒの情報より、対応するＦｉｌｅ
Ｅｎｔｒｙの記録位置を把握し、Ｆｉｌｅ Ｅｎｔｒｙ
にアクセスする。
するイベントが発生する度にＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒを追記する訳である。ＵＤＦにおいてファ
イルやディレクトリにアクセスする場合、まずＦｉｌｅ
Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏｒにアク
セスしディレクトリ内に記録されているファイルやディ
レクトリ名を把握する。アクセスしたいファイルやディ
レクトリに対応するＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ
Ｄｅｓｃｒｉｐｔｏｒの情報より、対応するＦｉｌｅ
Ｅｎｔｒｙの記録位置を把握し、Ｆｉｌｅ Ｅｎｔｒｙ
にアクセスする。
【０１４２】Ｆｉｌｅ Ｅｎｔｒｙにはファイルやディ
レクトリの実体の記録位置が管理されているので、この
情報を元に実体にアクセスする訳である。このときファ
イルやディレクトリにアクセスしようとしたが、それら
を管理するＦｉｌｅ Ｅｎｔｒｙにアクセスできない非
常時に、バックアップ情報であるＨｉｓｔｏｒｙ Ｔａ
ｂｌｅにアクセスする手段に関して図２９のフローチャ
ートを用いて説明する。
レクトリの実体の記録位置が管理されているので、この
情報を元に実体にアクセスする訳である。このときファ
イルやディレクトリにアクセスしようとしたが、それら
を管理するＦｉｌｅ Ｅｎｔｒｙにアクセスできない非
常時に、バックアップ情報であるＨｉｓｔｏｒｙ Ｔａ
ｂｌｅにアクセスする手段に関して図２９のフローチャ
ートを用いて説明する。
【０１４３】ステップＳ８０において、バックアップ情
報であるＨｉｓｔｏｒｙ Ｔａｂｌｅへのアクセス要求
が発生すると、ステップＳ８１において、Ｐｒｉｍａｒ
ｙＨｉｓｔｏｒｙ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒ
を読み出し、Ｈｉｓｔｏｒｙ Ｔａｂｌｅの大きさと、
Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中のＨｉｓｔｏｒｙＤｅｓ
ｃｒｉｐｔｏｒの数を把握してＨｉｓｔｏｒｙ Ｔａｂ
ｌｅをディスクから読み出す。具体的には、Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅ中のＮｕｍｂｅｒ ｏｆＨｉｓｔｏｒ
ｙ ＤｅｓｃｒｉｐｔｏｒｓによってＨｉｓｔｏｒｙ
Ｔａｂｌｅ中のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
の数を、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ ＳｉｚｅからＨ
ｉｓｔｏｒｙ Ｔａｂｌｅの最後尾の位置（ディスク上
では最前部）を把握する事が可能となり、読み出された
Ｈｉｓｔｏｒｙ Ｔａｂｌｅは制御部のメモリ上でＨｉ
ｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ毎に展開される。ス
テップＳ８２において、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中
の最後（時間的には最新）のＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒに注目をする。
報であるＨｉｓｔｏｒｙ Ｔａｂｌｅへのアクセス要求
が発生すると、ステップＳ８１において、Ｐｒｉｍａｒ
ｙＨｉｓｔｏｒｙ Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒ
を読み出し、Ｈｉｓｔｏｒｙ Ｔａｂｌｅの大きさと、
Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中のＨｉｓｔｏｒｙＤｅｓ
ｃｒｉｐｔｏｒの数を把握してＨｉｓｔｏｒｙ Ｔａｂ
ｌｅをディスクから読み出す。具体的には、Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅ中のＮｕｍｂｅｒ ｏｆＨｉｓｔｏｒ
ｙ ＤｅｓｃｒｉｐｔｏｒｓによってＨｉｓｔｏｒｙ
Ｔａｂｌｅ中のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
の数を、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ ＳｉｚｅからＨ
ｉｓｔｏｒｙ Ｔａｂｌｅの最後尾の位置（ディスク上
では最前部）を把握する事が可能となり、読み出された
Ｈｉｓｔｏｒｙ Ｔａｂｌｅは制御部のメモリ上でＨｉ
ｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ毎に展開される。ス
テップＳ８２において、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中
の最後（時間的には最新）のＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒに注目をする。
【０１４４】ステップＳ８３において、今アクセスした
いファイルあるいはディレクトリのＦｉｌｅ Ｅｎｔｒ
ｙの記録されている位置情報（ＬＢＮ）と注目している
Ｈｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒのＬＢＮ ｏｆ
ＦＥが一致するかどうかを判定する。一致しない場合
はステップＳ８４において全てのＨｉｓｔｏｒｙ Ｄｅ
ｓｃｒｉｐｔｏｒをサーチしたかどうかを判定する。全
てのＨｉｓｔｏｒｙＤｅｓｃｒｉｐｔｏｒをサーチした
場合は、探そうとしているバックアップ情報が見つから
ないという事になり、ステップＳ８７においてエラー処
理を行ない処理を終了する。ステップＳ８４においてま
だ全てのＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒをサー
チし終っていない場合は、ステップＳ８５において注目
しているＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉ
ｓｔｏｒｙ Ｔａｂｌｅ中の１つ前のＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒに変更し、ステップＳ８３に戻り
処理を繰り返す。
いファイルあるいはディレクトリのＦｉｌｅ Ｅｎｔｒ
ｙの記録されている位置情報（ＬＢＮ）と注目している
Ｈｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒのＬＢＮ ｏｆ
ＦＥが一致するかどうかを判定する。一致しない場合
はステップＳ８４において全てのＨｉｓｔｏｒｙ Ｄｅ
ｓｃｒｉｐｔｏｒをサーチしたかどうかを判定する。全
てのＨｉｓｔｏｒｙＤｅｓｃｒｉｐｔｏｒをサーチした
場合は、探そうとしているバックアップ情報が見つから
ないという事になり、ステップＳ８７においてエラー処
理を行ない処理を終了する。ステップＳ８４においてま
だ全てのＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒをサー
チし終っていない場合は、ステップＳ８５において注目
しているＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉ
ｓｔｏｒｙ Ｔａｂｌｅ中の１つ前のＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒに変更し、ステップＳ８３に戻り
処理を繰り返す。
【０１４５】ステップＳ８３においてＬＢＮ ｏｆ Ｆ
Ｅが一致すると判定された場合は、ステップＳ８６にお
いて注目しているＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏ
ｒのイベント種別を示すＡｔｔｒｉｂｕｔｅが削除であ
るかどうかを判定する。イベント種別が削除の場合、探
そうとしているファイルあるいはディレクトリのバック
アップ情報が削除状態を示すものであるためステップＳ
８７においてエラー処理して処理を終了する。ただし、
ここで、ファイルやディレクトリの削除した時点での情
報が取得したいのであれば、エラー処理を行わず抽出し
たＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを利用しても
構わない。ステップＳ８６においてイベント種別が削除
以外であれば、注目しているＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒが探し出すべきバックアップ情報であり、
サーチ処理を終了する。探し出したＨｉｓｔｏｒｙ Ｄ
ｅｓｃｒｉｐｔｏｒ中のＡｌｌｏｃａｔｉｏｎ Ｄｅｓ
ｃｒｉｐｔｏｒｓの情報を用いてファイルやディレクト
リのデータにアクセスが可能となるわけである。
Ｅが一致すると判定された場合は、ステップＳ８６にお
いて注目しているＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏ
ｒのイベント種別を示すＡｔｔｒｉｂｕｔｅが削除であ
るかどうかを判定する。イベント種別が削除の場合、探
そうとしているファイルあるいはディレクトリのバック
アップ情報が削除状態を示すものであるためステップＳ
８７においてエラー処理して処理を終了する。ただし、
ここで、ファイルやディレクトリの削除した時点での情
報が取得したいのであれば、エラー処理を行わず抽出し
たＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを利用しても
構わない。ステップＳ８６においてイベント種別が削除
以外であれば、注目しているＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒが探し出すべきバックアップ情報であり、
サーチ処理を終了する。探し出したＨｉｓｔｏｒｙ Ｄ
ｅｓｃｒｉｐｔｏｒ中のＡｌｌｏｃａｔｉｏｎ Ｄｅｓ
ｃｒｉｐｔｏｒｓの情報を用いてファイルやディレクト
リのデータにアクセスが可能となるわけである。
【０１４６】このように、ある特定のファイルやディレ
クトリのＵＤＦファイルシステム管理情報にアクセスで
きない場合に、Ｈｉｓｔｏｒｙ Ｔａｂｌｅから対応す
る最新のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを抽出
し、その情報から対応するデータの記録位置を把握しデ
ータにアクセスする事を可能とした。また、この情報を
利用して主の管理情報であるＵＤＦの管理情報を再構築
する事も可能である。
クトリのＵＤＦファイルシステム管理情報にアクセスで
きない場合に、Ｈｉｓｔｏｒｙ Ｔａｂｌｅから対応す
る最新のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを抽出
し、その情報から対応するデータの記録位置を把握しデ
ータにアクセスする事を可能とした。また、この情報を
利用して主の管理情報であるＵＤＦの管理情報を再構築
する事も可能である。
【０１４７】例えば、あるファイルを管理するＵＤＦの
Ｆｉｌｅ Ｅｎｔｒｙが読み出せなくなった場合は、対
応するバックアップ情報に相当するＨｉｓｔｏｒｙ Ｄ
ｅｓｃｒｉｐｔｏｒの情報を元にＦｉｌｅ Ｅｎｔｒｙ
をＵＤＦのパーティション内に記録し直す。
Ｆｉｌｅ Ｅｎｔｒｙが読み出せなくなった場合は、対
応するバックアップ情報に相当するＨｉｓｔｏｒｙ Ｄ
ｅｓｃｒｉｐｔｏｒの情報を元にＦｉｌｅ Ｅｎｔｒｙ
をＵＤＦのパーティション内に記録し直す。
【０１４８】Ｆｉｌｅ Ｅｎｔｒｙの情報としては、作
成時刻はＦｉｌｅ Ｅｎｔｒｙを作成し直した時刻、属
性情報は標準的な情報にセットされ、問題の発生する前
の状態とは必ずしも同じでは無いが、データにアクセス
するための必要最低限の情報であるデータの記録位置情
報に関しては完全に復活できるわけである。復旧したＵ
ＤＦのＦｉｌｅ Ｅｎｔｒｙの記録位置が問題のあった
元のＦｉｌｅ Ｅｎｔｒｙの記録位置と異なる場合、Ｆ
ｉｌｅ Ｅｎｔｒｙの記録位置を管理しているＵＤＦ管
理情報のＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒ
ｉｐｔｏｒ内のポインタ情報を新しく作成し直したＦｉ
ｌｅ Ｅｎｔｒｙの記録位置に更新を行う。
成時刻はＦｉｌｅ Ｅｎｔｒｙを作成し直した時刻、属
性情報は標準的な情報にセットされ、問題の発生する前
の状態とは必ずしも同じでは無いが、データにアクセス
するための必要最低限の情報であるデータの記録位置情
報に関しては完全に復活できるわけである。復旧したＵ
ＤＦのＦｉｌｅ Ｅｎｔｒｙの記録位置が問題のあった
元のＦｉｌｅ Ｅｎｔｒｙの記録位置と異なる場合、Ｆ
ｉｌｅ Ｅｎｔｒｙの記録位置を管理しているＵＤＦ管
理情報のＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒ
ｉｐｔｏｒ内のポインタ情報を新しく作成し直したＦｉ
ｌｅ Ｅｎｔｒｙの記録位置に更新を行う。
【０１４９】続いて、Ｈｉｓｔｏｒｙ Ｔａｂｌｅの再
構築の要求が発生した際の処理の流れを図３０に示した
フローチャートに基づいて説明する。
構築の要求が発生した際の処理の流れを図３０に示した
フローチャートに基づいて説明する。
【０１５０】ステップＳ９０において、Ｈｉｓｔｏｒｙ
Ｔａｂｌｅの再構築の要求が発生した場合、ステップ
Ｓ９１において、Ｐｒｉｍａｒｙ Ｈｉｓｔｏｒｙ Ｔ
ａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒを読み出し、Ｈｉｓｔ
ｏｒｙ Ｔａｂｌｅの大きさと、Ｈｉｓｔｏｒｙ Ｔａ
ｂｌｅ中のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの数
を把握してＨｉｓｔｏｒｙ Ｔａｂｌｅをディスクから
読み出す。具体的には、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中
のＮｕｍｂｅｒ ｏｆ Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉ
ｐｔｏｒｓによってＨｉｓｔｏｒｙ Ｔａｂｌｅ中のＨ
ｉｓｔｏｒｙＤｅｓｃｒｉｐｔｏｒの数を、Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅ ＳｉｚｅからＨｉｓｔｏｒｙ Ｔａ
ｂｌｅの最後尾の位置を把握する事が可能となり、読み
出されたＨｉｓｔｏｒｙ Ｔａｂｌｅは制御部のメモリ
上でＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ毎に展開さ
れる。
Ｔａｂｌｅの再構築の要求が発生した場合、ステップ
Ｓ９１において、Ｐｒｉｍａｒｙ Ｈｉｓｔｏｒｙ Ｔ
ａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒを読み出し、Ｈｉｓｔ
ｏｒｙ Ｔａｂｌｅの大きさと、Ｈｉｓｔｏｒｙ Ｔａ
ｂｌｅ中のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの数
を把握してＨｉｓｔｏｒｙ Ｔａｂｌｅをディスクから
読み出す。具体的には、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中
のＮｕｍｂｅｒ ｏｆ Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉ
ｐｔｏｒｓによってＨｉｓｔｏｒｙ Ｔａｂｌｅ中のＨ
ｉｓｔｏｒｙＤｅｓｃｒｉｐｔｏｒの数を、Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅ ＳｉｚｅからＨｉｓｔｏｒｙ Ｔａ
ｂｌｅの最後尾の位置を把握する事が可能となり、読み
出されたＨｉｓｔｏｒｙ Ｔａｂｌｅは制御部のメモリ
上でＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ毎に展開さ
れる。
【０１５１】ステップＳ９２において、Ｈｉｓｔｏｒｙ
Ｔａｂｌｅ中の最後のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉ
ｐｔｏｒに注目をする。ステップＳ９３において、Ｈｉ
ｓｔｏｒｙ Ｔａｂｌｅ中の全てのＨｉｓｔｏｒｙ Ｄ
ｅｓｃｒｉｐｔｏｒを見たかどうかを判定し、全てのＨ
ｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒについて処理が終
っていれば処理を終了する。まだ処理が終っていない場
合は、ステップＳ９４において、注目しているＨｉｓｔ
ｏｒｙ Ｄｅｓｃｒｉｐｔｏｒのイベント種別を表すＡ
ｔｔｒｉｂｕｔｅが削除かどうかを判定する。イベント
種別が削除の場合は、ステップＳ９８において注目して
いるＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを削除リス
トに追加する。具体的には注目しているＨｉｓｔｏｒｙ
ＤｅｓｃｒｉｐｔｏｒのＬＢＮ ｏｆ ＦＥを削除リ
ストに登録する事を行う。ステップＳ９９において注目
しているＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉ
ｓｔｏｒｙ Ｔａｂｌｅ中の１つ前のＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒに変更し、ステップＳ９３に戻り
処理を繰り返す。
Ｔａｂｌｅ中の最後のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉ
ｐｔｏｒに注目をする。ステップＳ９３において、Ｈｉ
ｓｔｏｒｙ Ｔａｂｌｅ中の全てのＨｉｓｔｏｒｙ Ｄ
ｅｓｃｒｉｐｔｏｒを見たかどうかを判定し、全てのＨ
ｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒについて処理が終
っていれば処理を終了する。まだ処理が終っていない場
合は、ステップＳ９４において、注目しているＨｉｓｔ
ｏｒｙ Ｄｅｓｃｒｉｐｔｏｒのイベント種別を表すＡ
ｔｔｒｉｂｕｔｅが削除かどうかを判定する。イベント
種別が削除の場合は、ステップＳ９８において注目して
いるＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを削除リス
トに追加する。具体的には注目しているＨｉｓｔｏｒｙ
ＤｅｓｃｒｉｐｔｏｒのＬＢＮ ｏｆ ＦＥを削除リ
ストに登録する事を行う。ステップＳ９９において注目
しているＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉ
ｓｔｏｒｙ Ｔａｂｌｅ中の１つ前のＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒに変更し、ステップＳ９３に戻り
処理を繰り返す。
【０１５２】ステップＳ９４においてイベント種別が削
除でない場合、ステップＳ９５において注目しているＨ
ｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが削除リストに含
まれているかを判定する。具体的には、注目しているＨ
ｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒのＬＢＮ ｏｆ
ＦＥと削除リストに含まれるＬＢＮ ｏｆ ＦＥを比較
する事によって行う。ステップＳ９６において削除リス
トに含まれていたかを判定し、含まれていた場合は、そ
のままステップＳ９９において注目しているＨｉｓｔｏ
ｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔｏｒｙ Ｔａｂ
ｌｅ中の１つ前のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏ
ｒに変更し、ステップＳ９３に戻り処理を繰り返す。
除でない場合、ステップＳ９５において注目しているＨ
ｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが削除リストに含
まれているかを判定する。具体的には、注目しているＨ
ｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒのＬＢＮ ｏｆ
ＦＥと削除リストに含まれるＬＢＮ ｏｆ ＦＥを比較
する事によって行う。ステップＳ９６において削除リス
トに含まれていたかを判定し、含まれていた場合は、そ
のままステップＳ９９において注目しているＨｉｓｔｏ
ｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔｏｒｙ Ｔａｂ
ｌｅ中の１つ前のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏ
ｒに変更し、ステップＳ９３に戻り処理を繰り返す。
【０１５３】ステップＳ９６において削除リストに含ま
れていないと判定された場合、ステップＳ９７において
抽出結果リストに追加する。具体的には注目しているＨ
ｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒをそのまま抽出結
果リストにコピーする事を行う。ステップＳ９８におい
て、注目しているＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏ
ｒを削除リストに追加し、ステップＳ９９において注目
しているＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉ
ｓｔｏｒｙ Ｔａｂｌｅ中の１つ前のＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒに変更し、ステップＳ９３に戻り
処理を繰り返す。
れていないと判定された場合、ステップＳ９７において
抽出結果リストに追加する。具体的には注目しているＨ
ｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒをそのまま抽出結
果リストにコピーする事を行う。ステップＳ９８におい
て、注目しているＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏ
ｒを削除リストに追加し、ステップＳ９９において注目
しているＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉ
ｓｔｏｒｙ Ｔａｂｌｅ中の１つ前のＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒに変更し、ステップＳ９３に戻り
処理を繰り返す。
【０１５４】このような処理を行う事によって、Ｈｉｓ
ｔｏｒｙ Ｔａｂｌｅ中の同じファイルやディレクトリ
を示す重複するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
を削除し、更新履歴として存在した不要な情報を削除す
る事が可能となる。具体的には、処理が終わった段階で
抽出結果リストに残っているＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒが目的の情報となる。
ｔｏｒｙ Ｔａｂｌｅ中の同じファイルやディレクトリ
を示す重複するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ
を削除し、更新履歴として存在した不要な情報を削除す
る事が可能となる。具体的には、処理が終わった段階で
抽出結果リストに残っているＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒが目的の情報となる。
【０１５５】続いて、Ｈｉｓｔｏｒｙ Ｔａｂｌｅから
あるファイルやディレクトリに関する更新履歴を取得し
たい要求が発生した際の処理の流れを図３１に示したフ
ローチャートに基づいて説明する。
あるファイルやディレクトリに関する更新履歴を取得し
たい要求が発生した際の処理の流れを図３１に示したフ
ローチャートに基づいて説明する。
【０１５６】ステップＳ１００において、Ｈｉｓｔｏｒ
ｙ Ｔａｂｌｅからあるファイルやディレクトリに関す
る更新履歴を取得したい要求が発生した場合、ステップ
Ｓ１０１において、Ｐｒｉｍａｒｙ Ｈｉｓｔｏｒｙ
Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒを読み出し、Ｈｉｓ
ｔｏｒｙ Ｔａｂｌｅの大きさと、ＨｉｓｔｏｒｙＴａ
ｂｌｅ中のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの
数を把握してＨｉｓｔｏｒｙ Ｔａｂｌｅをディスクか
ら読み出す。
ｙ Ｔａｂｌｅからあるファイルやディレクトリに関す
る更新履歴を取得したい要求が発生した場合、ステップ
Ｓ１０１において、Ｐｒｉｍａｒｙ Ｈｉｓｔｏｒｙ
Ｔａｂｌｅ Ｄｅｓｃｒｉｐｔｏｒを読み出し、Ｈｉｓ
ｔｏｒｙ Ｔａｂｌｅの大きさと、ＨｉｓｔｏｒｙＴａ
ｂｌｅ中のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの
数を把握してＨｉｓｔｏｒｙ Ｔａｂｌｅをディスクか
ら読み出す。
【０１５７】具体的には、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ
中のＮｕｍｂｅｒ ｏｆ Ｈｉｓｔｏｒｙ Ｄｅｓｃｒ
ｉｐｔｏｒｓによってＨｉｓｔｏｒｙ Ｔａｂｌｅ中の
Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの数を、Ｈｉｓ
ｔｏｒｙ Ｔａｂｌｅ ＳｉｚｅからＨｉｓｔｏｒｙ
Ｔａｂｌｅの最後尾の位置を把握する事が可能となり、
読み出されたＨｉｓｔｏｒｙ Ｔａｂｌｅは制御部のメ
モリ上でＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ毎に展
開される。
中のＮｕｍｂｅｒ ｏｆ Ｈｉｓｔｏｒｙ Ｄｅｓｃｒ
ｉｐｔｏｒｓによってＨｉｓｔｏｒｙ Ｔａｂｌｅ中の
Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒの数を、Ｈｉｓ
ｔｏｒｙ Ｔａｂｌｅ ＳｉｚｅからＨｉｓｔｏｒｙ
Ｔａｂｌｅの最後尾の位置を把握する事が可能となり、
読み出されたＨｉｓｔｏｒｙ Ｔａｂｌｅは制御部のメ
モリ上でＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒ毎に展
開される。
【０１５８】ステップＳ１０２において、Ｈｉｓｔｏｒ
ｙ Ｔａｂｌｅ中の最後のＨｉｓｔｏｒｙ Ｄｅｓｃｒ
ｉｐｔｏｒに注目をする。ステップＳ１０３において、
検索対象を示す変数であるＳＥＡＲＣＨＫＥＹに目的の
ＬＢＮ ｏｆ ＦＥをセットする。ＬＢＮ ｏｆ ＦＥ
は、検出対象のファイルやディレクトリを管理するＦｉ
ｌｅ Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏｒに
よって把握する事が可能である。ステップＳ１０４にお
いて、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中の全てのＨｉｓｔ
ｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを調べたかどうかを判定
し、全てのＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒにつ
いて処理が終っていれば処理を終了する。
ｙ Ｔａｂｌｅ中の最後のＨｉｓｔｏｒｙ Ｄｅｓｃｒ
ｉｐｔｏｒに注目をする。ステップＳ１０３において、
検索対象を示す変数であるＳＥＡＲＣＨＫＥＹに目的の
ＬＢＮ ｏｆ ＦＥをセットする。ＬＢＮ ｏｆ ＦＥ
は、検出対象のファイルやディレクトリを管理するＦｉ
ｌｅ Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏｒに
よって把握する事が可能である。ステップＳ１０４にお
いて、Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中の全てのＨｉｓｔ
ｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを調べたかどうかを判定
し、全てのＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒにつ
いて処理が終っていれば処理を終了する。
【０１５９】まだ処理が終っていない場合は、ステップ
Ｓ１０５において、注目しているＨｉｓｔｏｒｙ Ｄｅ
ｓｃｒｉｐｔｏｒのＬＢＮ ｏｆ ＦＥが対象としてい
るファイルあるいはディレクトリと一致するかどうかを
判定する。具体的にはＳＥＡＲＣＨＫＥＹと注目してい
るＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒのＬＢＮｏｆ
ＦＥ を比較する事によって行う。一致しない場合は
ステップＳ１０７において注目するＨｉｓｔｏｒｙ Ｄ
ｅｓｃｒｉｐｔｏｒをＨｉｓｔｏｒｙ Ｔａｂｌｅ中の
１つ前のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒに変更
し、ステップＳ１０４に戻り処理を繰り返す。
Ｓ１０５において、注目しているＨｉｓｔｏｒｙ Ｄｅ
ｓｃｒｉｐｔｏｒのＬＢＮ ｏｆ ＦＥが対象としてい
るファイルあるいはディレクトリと一致するかどうかを
判定する。具体的にはＳＥＡＲＣＨＫＥＹと注目してい
るＨｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒのＬＢＮｏｆ
ＦＥ を比較する事によって行う。一致しない場合は
ステップＳ１０７において注目するＨｉｓｔｏｒｙ Ｄ
ｅｓｃｒｉｐｔｏｒをＨｉｓｔｏｒｙ Ｔａｂｌｅ中の
１つ前のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒに変更
し、ステップＳ１０４に戻り処理を繰り返す。
【０１６０】ステップＳ１０５において、注目している
Ｈｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒのＬＢＮ ｏｆ
ＦＥが対象としているファイルあるいはディレクトリ
と一致する場合、ステップＳ１０６において現在注目し
ているＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒは、更新
履歴を取得しようとしている対象のファイルあるいはデ
ィレクトリに関する更新履歴であるものとし抽出結果と
してリストアップする事になる。ステップＳ１０７にお
いて注目するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを
Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中の１つ前のＨｉｓｔｏｒ
ｙ Ｄｅｓｃｒｉｐｔｏｒに変更し、ステップＳ１０４
に戻り処理を繰り返す。
Ｈｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒのＬＢＮ ｏｆ
ＦＥが対象としているファイルあるいはディレクトリ
と一致する場合、ステップＳ１０６において現在注目し
ているＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒは、更新
履歴を取得しようとしている対象のファイルあるいはデ
ィレクトリに関する更新履歴であるものとし抽出結果と
してリストアップする事になる。ステップＳ１０７にお
いて注目するＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを
Ｈｉｓｔｏｒｙ Ｔａｂｌｅ中の１つ前のＨｉｓｔｏｒ
ｙ Ｄｅｓｃｒｉｐｔｏｒに変更し、ステップＳ１０４
に戻り処理を繰り返す。
【０１６１】ステップＳ１０７において注目するＨｉｓ
ｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔｏｒｙ Ｔ
ａｂｌｅ中の１つ前のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐ
ｔｏｒに変更し、ステップＳ１０４に戻り処理を繰り返
す。
ｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔｏｒｙ Ｔ
ａｂｌｅ中の１つ前のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐ
ｔｏｒに変更し、ステップＳ１０４に戻り処理を繰り返
す。
【０１６２】このような処理によって、Ｈｉｓｔｏｒｙ
Ｔａｂｌｅから更新履歴を取得したいファイルあるい
はディレクトリに関する全てのＨｉｓｔｏｒｙ Ｄｅｓ
ｃｒｉｐｔｏｒを簡単に抽出する事が可能となる。具体
的には、処理が終わった段階の抽出結果リストに残って
いるＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが目的の情
報となる。
Ｔａｂｌｅから更新履歴を取得したいファイルあるい
はディレクトリに関する全てのＨｉｓｔｏｒｙ Ｄｅｓ
ｃｒｉｐｔｏｒを簡単に抽出する事が可能となる。具体
的には、処理が終わった段階の抽出結果リストに残って
いるＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒが目的の情
報となる。
【０１６３】説明してきたＨｉｓｔｏｒｙ Ｔａｂｌｅ
では、アクセスしようとするファイルやディレクトリが
あらかじめ分かっている場合には、Ｈｉｓｔｏｒｙ Ｔ
ａｂｌｅに含まれる対応するＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒを探し出すだけの処理で終わる。仮に管理
情報のバックアップの対象となるファイルシステムの管
理情報が全くディスクから読み出せなくなり、どのよう
なファイルが記録されているか、あるいはどのようなデ
ィレクトリ構造の状態であるかが不明になる事も考えら
れる。このような状況が発生した場合には、Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅを再構築し残されたＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒを参照する事によって、バックア
ップ情報を介してファイルの実体にアクセスしたり、管
理情報の復旧をするための情報をして利用できる事にな
る。
では、アクセスしようとするファイルやディレクトリが
あらかじめ分かっている場合には、Ｈｉｓｔｏｒｙ Ｔ
ａｂｌｅに含まれる対応するＨｉｓｔｏｒｙ Ｄｅｓｃ
ｒｉｐｔｏｒを探し出すだけの処理で終わる。仮に管理
情報のバックアップの対象となるファイルシステムの管
理情報が全くディスクから読み出せなくなり、どのよう
なファイルが記録されているか、あるいはどのようなデ
ィレクトリ構造の状態であるかが不明になる事も考えら
れる。このような状況が発生した場合には、Ｈｉｓｔｏ
ｒｙ Ｔａｂｌｅを再構築し残されたＨｉｓｔｏｒｙ
Ｄｅｓｃｒｉｐｔｏｒを参照する事によって、バックア
ップ情報を介してファイルの実体にアクセスしたり、管
理情報の復旧をするための情報をして利用できる事にな
る。
【０１６４】ここで、ＵＤＦファイルシステムにおい
て、ファイルやディレクトリを管理するＦｉｌｅ Ｅｎ
ｔｒｙにアクセスできなかった場合に、バックアップ情
報を元に管理情報を復旧する手順を図３２に示すフロー
チャートに基づいて説明する。
て、ファイルやディレクトリを管理するＦｉｌｅ Ｅｎ
ｔｒｙにアクセスできなかった場合に、バックアップ情
報を元に管理情報を復旧する手順を図３２に示すフロー
チャートに基づいて説明する。
【０１６５】ステップＳ１１０において、ＵＤＦファイ
ルシステムにおいてファイルやディレクトリを管理する
Ｆｉｌｅ Ｅｎｔｒｙにアクセスできない事が、例え
ば、Ｆｉｌｅ Ｅｎｔｒｙの読み出しが物理的に失敗し
たり、読み出せた場合であってもＦｉｌｅ Ｅｎｔｒｙ
のヘッダ情報に記録されているチェックサムやＣＲＣ情
報が正しくない事によって検出された場合、ステップＳ
１１１において、問題のファイルやディレクトリのＦｉ
ｌｅ Ｅｎｔｒｙの記録位置を示すＬＢＮ ｏｆＦＥで
指定してＨｉｓｔｏｒｙ Ｔａｂｌｅより対応するバッ
クアップ情報であるＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔ
ｏｒを抽出する。具体的な抽出方法は既に述べた通りで
ある。ステップＳ１１２において、抽出したＨｉｓｔｏ
ｒｙ Ｄｅｓｃｒｉｐｔｏｒの情報からＦｉｌｅ Ｅｎ
ｔｒｙの再生成を行うが、このＦｉｌｅ Ｅｎｔｒｙに
は、Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒに含まれる
Ａｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓの内容
をコピーする。
ルシステムにおいてファイルやディレクトリを管理する
Ｆｉｌｅ Ｅｎｔｒｙにアクセスできない事が、例え
ば、Ｆｉｌｅ Ｅｎｔｒｙの読み出しが物理的に失敗し
たり、読み出せた場合であってもＦｉｌｅ Ｅｎｔｒｙ
のヘッダ情報に記録されているチェックサムやＣＲＣ情
報が正しくない事によって検出された場合、ステップＳ
１１１において、問題のファイルやディレクトリのＦｉ
ｌｅ Ｅｎｔｒｙの記録位置を示すＬＢＮ ｏｆＦＥで
指定してＨｉｓｔｏｒｙ Ｔａｂｌｅより対応するバッ
クアップ情報であるＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔ
ｏｒを抽出する。具体的な抽出方法は既に述べた通りで
ある。ステップＳ１１２において、抽出したＨｉｓｔｏ
ｒｙ Ｄｅｓｃｒｉｐｔｏｒの情報からＦｉｌｅ Ｅｎ
ｔｒｙの再生成を行うが、このＦｉｌｅ Ｅｎｔｒｙに
は、Ｈｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒに含まれる
Ａｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒｓの内容
をコピーする。
【０１６６】Ａｌｌｏｃａｔｉｏｎ Ｄｅｓｃｒｉｐｔ
ｏｒｓにはファイルに対応するデータの記録位置情報が
格納されており、この情報が存在すればデータを読み出
すための位置情報がわかるのでデータの読み出しが可能
となる。再生成したＦｉｌｅＥｎｔｒｙはディスク上に
記録する。ステップＳ１１３において、アクセスできな
かったＦｉｌｅ Ｅｎｔｒｙの記録位置を管理している
ＵＤＦのＦｉｌｅＩｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒｉ
ｐｔｏｒのＩＣＢフィールドを、記録し直したＦｉｌｅ
Ｅｎｔｒｙの記録位置を管理するように更新する。再
生成したＦｉｌｅ Ｅｎｔｒｙを、読み出せなかったＦ
ｉｌｅ Ｅｎｔｒｙと同じ位置に記録し直した場合は上
記の更新処理を行う必要はない。
ｏｒｓにはファイルに対応するデータの記録位置情報が
格納されており、この情報が存在すればデータを読み出
すための位置情報がわかるのでデータの読み出しが可能
となる。再生成したＦｉｌｅＥｎｔｒｙはディスク上に
記録する。ステップＳ１１３において、アクセスできな
かったＦｉｌｅ Ｅｎｔｒｙの記録位置を管理している
ＵＤＦのＦｉｌｅＩｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒｉ
ｐｔｏｒのＩＣＢフィールドを、記録し直したＦｉｌｅ
Ｅｎｔｒｙの記録位置を管理するように更新する。再
生成したＦｉｌｅ Ｅｎｔｒｙを、読み出せなかったＦ
ｉｌｅ Ｅｎｔｒｙと同じ位置に記録し直した場合は上
記の更新処理を行う必要はない。
【０１６７】第２の実施形態では、Ｈｉｓｔｏｒｙ Ｄ
ｅｓｃｒｉｐｔｏｒで管理するバックアップ対象のファ
イルやディレクトリを特定するための識別情報として管
理情報の記録媒体上の記録位置情報を用い、ファイル名
やディレクトリ名は管理していない。よって、バックア
ップ情報単独でファイルの実体にアクセスする事は可能
であるが、そのファイル名やディレクトリ階層を再構築
する事はできない。つまり、通常はＵＤＦにおけるファ
イルやディレクトリの名前と対応するＦｉｌｅＥｎｔｒ
ｙの記録位置を管理するＦｉｌｅ Ｉｄｅｎｔｉｆｉｅ
ｒ Ｄｅｓｃｒｉｐｔｏｒの情報にアクセスできる事が
前提となる。よってＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ
Ｄｅｓｃｒｉｐｔｏｒにアクセスできなくなると、バッ
クアップ情報だけではファイル名やディレクトリ階層の
復旧ができなくなってしまう。
ｅｓｃｒｉｐｔｏｒで管理するバックアップ対象のファ
イルやディレクトリを特定するための識別情報として管
理情報の記録媒体上の記録位置情報を用い、ファイル名
やディレクトリ名は管理していない。よって、バックア
ップ情報単独でファイルの実体にアクセスする事は可能
であるが、そのファイル名やディレクトリ階層を再構築
する事はできない。つまり、通常はＵＤＦにおけるファ
イルやディレクトリの名前と対応するＦｉｌｅＥｎｔｒ
ｙの記録位置を管理するＦｉｌｅ Ｉｄｅｎｔｉｆｉｅ
ｒ Ｄｅｓｃｒｉｐｔｏｒの情報にアクセスできる事が
前提となる。よってＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ
Ｄｅｓｃｒｉｐｔｏｒにアクセスできなくなると、バッ
クアップ情報だけではファイル名やディレクトリ階層の
復旧ができなくなってしまう。
【０１６８】この問題を解決するために、図３３に示す
ようにディレクトリを管理するＦｉｌｅ Ｅｎｔｒｙと
ファイルやディレクトリの名前と対応するＦｉｌｅ Ｅ
ｎｔｒｙの記録位置等を管理するＦｉｌｅ Ｉｄｅｎｔ
ｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏｒをディレクトリ構造
用管理情報領域に記録する。この領域に記録されている
管理情報にアクセスする事によってディスクに記録され
ているファイルやディレクトリ構造を容易に把握する事
が可能となる。ファイルの実体を管理するＦｉｌｅ Ｅ
ｎｔｒｙをこの領域に記録しないため、大量のファイル
を作成しても領域として必要な大きさを抑える事が可能
である。これは、Ｆｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ Ｄ
ｅｓｃｒｉｐｔｏｒのデータ量が少ないためである。
ようにディレクトリを管理するＦｉｌｅ Ｅｎｔｒｙと
ファイルやディレクトリの名前と対応するＦｉｌｅ Ｅ
ｎｔｒｙの記録位置等を管理するＦｉｌｅ Ｉｄｅｎｔ
ｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏｒをディレクトリ構造
用管理情報領域に記録する。この領域に記録されている
管理情報にアクセスする事によってディスクに記録され
ているファイルやディレクトリ構造を容易に把握する事
が可能となる。ファイルの実体を管理するＦｉｌｅ Ｅ
ｎｔｒｙをこの領域に記録しないため、大量のファイル
を作成しても領域として必要な大きさを抑える事が可能
である。これは、Ｆｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ Ｄ
ｅｓｃｒｉｐｔｏｒのデータ量が少ないためである。
【０１６９】例えば１つのファイルを管理するＦｉｌｅ
Ｅｎｔｒｙはディスク上の１論理ブロック（２ＫＢ）
を占有してしまうが、Ｆｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ
Ｄｅｓｃｒｉｐｔｏｒは１２文字のファイル名の場合
５２ｂｙｔｅしか占有しない。よって同じ２ＫＢで管理
できるＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒｉ
ｐｔｏｒの数は約３９ファイル分となる。
Ｅｎｔｒｙはディスク上の１論理ブロック（２ＫＢ）
を占有してしまうが、Ｆｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ
Ｄｅｓｃｒｉｐｔｏｒは１２文字のファイル名の場合
５２ｂｙｔｅしか占有しない。よって同じ２ＫＢで管理
できるＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒｉ
ｐｔｏｒの数は約３９ファイル分となる。
【０１７０】例えば、図３３に示すように上記管理情報
用の領域をそのまま後続する領域全体をコピーしその領
域を１つのファイルとして管理する事が考えられる。こ
のディレクトリ構造管理情報用領域のバックアップファ
イルに特定の名前をつける事によって、ディレクトリ構
造を管理するＵＤＦの管理情報のバックアップにアクセ
スする事が可能となる。別の手段としてこの管理情報用
のバックアップをファイルとして管理するのではなく、
ＵＤＦのパーティションの外の記録位置が固定された専
用領域に記録しても良い。いずれにしても、Ｆｉｌｅ
Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏｒが２重化
されているため、万が一Ｆｉｌｅ Ｉｄｅｎｔｉｆｉｅ
ｒ Ｄｅｓｃｒｉｐｔｏｒにアクセスできないような問
題が発生した場合には、このディレクトリ構造の管理情
報のバックアップにアクセスする事によって問題を解決
する事が可能である。
用の領域をそのまま後続する領域全体をコピーしその領
域を１つのファイルとして管理する事が考えられる。こ
のディレクトリ構造管理情報用領域のバックアップファ
イルに特定の名前をつける事によって、ディレクトリ構
造を管理するＵＤＦの管理情報のバックアップにアクセ
スする事が可能となる。別の手段としてこの管理情報用
のバックアップをファイルとして管理するのではなく、
ＵＤＦのパーティションの外の記録位置が固定された専
用領域に記録しても良い。いずれにしても、Ｆｉｌｅ
Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏｒが２重化
されているため、万が一Ｆｉｌｅ Ｉｄｅｎｔｉｆｉｅ
ｒ Ｄｅｓｃｒｉｐｔｏｒにアクセスできないような問
題が発生した場合には、このディレクトリ構造の管理情
報のバックアップにアクセスする事によって問題を解決
する事が可能である。
【０１７１】本発明第１および第２の実施の形態では、
Ｈｉｓｔｏｒｙ Ｔａｂｌｅをディスク上に確保された
専用のバックアップ領域に記録したが、この情報を専用
領域に記録せずにバックアップの対象となるファイルシ
ステム内で普通のファイルとして記録する事も考えられ
る。このような構成を取る事によって、バックアップ用
の専用領域を用意する必要が無く、ファイルとして記録
されるのでバックアップ情報であるＨｉｓｔｏｒｙ Ｔ
ａｂｌｅをディスク上の任意の箇所に記録する事が可能
となる。
Ｈｉｓｔｏｒｙ Ｔａｂｌｅをディスク上に確保された
専用のバックアップ領域に記録したが、この情報を専用
領域に記録せずにバックアップの対象となるファイルシ
ステム内で普通のファイルとして記録する事も考えられ
る。このような構成を取る事によって、バックアップ用
の専用領域を用意する必要が無く、ファイルとして記録
されるのでバックアップ情報であるＨｉｓｔｏｒｙ Ｔ
ａｂｌｅをディスク上の任意の箇所に記録する事が可能
となる。
【０１７２】また、Ｈｉｓｔｏｒｙ Ｔａｂｌｅの内容
を不揮発性の半導体メモリに格納する事も考えられる。
このように、データ自体が記録されている記録媒体と異
なる媒体にＨｉｓｔｏｒｙ Ｔａｂｌｅを記録する場合
は、Ｈｉｓｔｏｒｙ Ｔａｂｌｅと対応するファイルシ
ステムが記録されているメディアを識別するための情報
と共に記録する事によって、ディスクメディアとＨｉｓ
ｔｏｒｙ Ｔａｂｌｅの対応を取る事が可能となる。
を不揮発性の半導体メモリに格納する事も考えられる。
このように、データ自体が記録されている記録媒体と異
なる媒体にＨｉｓｔｏｒｙ Ｔａｂｌｅを記録する場合
は、Ｈｉｓｔｏｒｙ Ｔａｂｌｅと対応するファイルシ
ステムが記録されているメディアを識別するための情報
と共に記録する事によって、ディスクメディアとＨｉｓ
ｔｏｒｙ Ｔａｂｌｅの対応を取る事が可能となる。
【０１７３】
【発明の効果】本発明によれば、論理ファイルシステム
の管理情報を多重する機能が無いようなファイルシステ
ムであっても、ファイルに関する作成、変更、削除、デ
ィレクトリに関する作成、削除と言ったイベントが発生
する度に、対応するファイルやディレクトリにアクセス
するための識別情報と、ファイルやディレクトリの管理
情報を復旧するための必要最低限の情報とで構成される
Ｈｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔｏｒ
ｙ Ｔａｂｌｅに単純な処理である追加処理を行う。ま
た、Ｈｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔ
ｏｒｙ Ｔａｂｌｅを記録する領域の後方から前方方向
へ順番に記録することによって、Ｈｉｓｔｏｒｙ Ｔａ
ｂｌｅ内のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒへの
アクセスを容易に実現させる事になる。
の管理情報を多重する機能が無いようなファイルシステ
ムであっても、ファイルに関する作成、変更、削除、デ
ィレクトリに関する作成、削除と言ったイベントが発生
する度に、対応するファイルやディレクトリにアクセス
するための識別情報と、ファイルやディレクトリの管理
情報を復旧するための必要最低限の情報とで構成される
Ｈｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔｏｒ
ｙ Ｔａｂｌｅに単純な処理である追加処理を行う。ま
た、Ｈｉｓｔｏｒｙ ＤｅｓｃｒｉｐｔｏｒをＨｉｓｔ
ｏｒｙ Ｔａｂｌｅを記録する領域の後方から前方方向
へ順番に記録することによって、Ｈｉｓｔｏｒｙ Ｔａ
ｂｌｅ内のＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒへの
アクセスを容易に実現させる事になる。
【０１７４】この事によって、論理ファイルシステムの
管理情報が読み出せなくなった場合にこのバックアップ
情報であるＨｉｓｔｏｒｙ Ｔａｂｌｅにアクセスする
事によって対応するファイルやディレクトリにアクセス
する事と管理情報の復旧が可能となる。
管理情報が読み出せなくなった場合にこのバックアップ
情報であるＨｉｓｔｏｒｙ Ｔａｂｌｅにアクセスする
事によって対応するファイルやディレクトリにアクセス
する事と管理情報の復旧が可能となる。
【０１７５】また、バックアップ情報であるＨｉｓｔｏ
ｒｙ Ｔａｂｌｅは、ファイルやディレクトリに関する
作成、変更、削除と言ったイベントが発生する度に追加
されるものなので、ファイルやディレクトリの更新履歴
情報としても用いる事が可能となる。
ｒｙ Ｔａｂｌｅは、ファイルやディレクトリに関する
作成、変更、削除と言ったイベントが発生する度に追加
されるものなので、ファイルやディレクトリの更新履歴
情報としても用いる事が可能となる。
【図１】本発明のディスク管理方法の実施形態における
ブロック図を示す説明図である。
ブロック図を示す説明図である。
【図２】本発明のディスク管理方法の実施形態において
ＵＤＦのパーティションとバックアップ領域の関係を示
す説明図である。
ＵＤＦのパーティションとバックアップ領域の関係を示
す説明図である。
【図３】本発明のディスク管理方法の実施形態において
バックアップ領域の内容を示す説明図である。
バックアップ領域の内容を示す説明図である。
【図４】本発明のディスク管理方法の第１実施形態にお
けるＰｒｉｍａｒｙ Ｈｉｓｔｏｒｙ Ｔａｂｌｅ Ｄ
ｅｓｃｒｉｐｔｏｒを示す説明図である。
けるＰｒｉｍａｒｙ Ｈｉｓｔｏｒｙ Ｔａｂｌｅ Ｄ
ｅｓｃｒｉｐｔｏｒを示す説明図である。
【図５】本発明のディスク管理方法の第１実施形態にお
けるＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを示す説明
図である。
けるＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを示す説明
図である。
【図６】本発明のディスク管理方法の第１実施形態にお
けるディレクトリ階層の例を示す説明図である。
けるディレクトリ階層の例を示す説明図である。
【図７】本発明のディスク管理方法の第１実施形態にお
ける図６に対応するＵＤＦ管理情報とデータのディスク
上での配置の例を示す説明図である。
ける図６に対応するＵＤＦ管理情報とデータのディスク
上での配置の例を示す説明図である。
【図８】本発明のディスク管理方法の第１実施形態にお
ける図７に対応するＨｉｓｔｏｒｙ Ｔａｂｌｅの一例
を示す説明図である。
ける図７に対応するＨｉｓｔｏｒｙ Ｔａｂｌｅの一例
を示す説明図である。
【図９】本発明のディスク管理方法の第１実施形態にお
いてファイルが追加になった場合のＨｉｓｔｏｒｙ Ｔ
ａｂｌｅの更新の様子を示す説明図である。
いてファイルが追加になった場合のＨｉｓｔｏｒｙ Ｔ
ａｂｌｅの更新の様子を示す説明図である。
【図１０】本発明のディスク管理方法の第１実施形態に
おいてファイルが変更になった場合のＨｉｓｔｏｒｙ
Ｔａｂｌｅの更新の様子を示す説明図である。
おいてファイルが変更になった場合のＨｉｓｔｏｒｙ
Ｔａｂｌｅの更新の様子を示す説明図である。
【図１１】本発明のディスク管理方法の第１実施形態に
おいてファイルが削除になった場合のＨｉｓｔｏｒｙ
Ｔａｂｌｅの更新の様子を示す説明図である。
おいてファイルが削除になった場合のＨｉｓｔｏｒｙ
Ｔａｂｌｅの更新の様子を示す説明図である。
【図１２】本発明のディスク管理方法の第１実施形態に
おいてＨｉｓｔｏｒｙ Ｔａｂｌｅを再構築する様子を
示す説明図である。
おいてＨｉｓｔｏｒｙ Ｔａｂｌｅを再構築する様子を
示す説明図である。
【図１３】本発明のディスク管理方法の第１実施形態に
おけるファイルやディレクトリの作成、変更、削除と言
ったイベントが発生した際の処理の手順を示すフローチ
ャートである。
おけるファイルやディレクトリの作成、変更、削除と言
ったイベントが発生した際の処理の手順を示すフローチ
ャートである。
【図１４】本発明のディスク管理方法の第１実施形態に
おけるバックアップ情報であるＨｉｓｔｏｒｙ Ｔａｂ
ｌｅにアクセスする際の処理の手順を示すフローチャー
トである。
おけるバックアップ情報であるＨｉｓｔｏｒｙ Ｔａｂ
ｌｅにアクセスする際の処理の手順を示すフローチャー
トである。
【図１５】本発明のディスク管理方法の第１実施形態に
おけるバックアップ情報であるＨｉｓｔｏｒｙ Ｔａｂ
ｌｅを再構築際の処理の手順を示すフローチャートであ
る。
おけるバックアップ情報であるＨｉｓｔｏｒｙ Ｔａｂ
ｌｅを再構築際の処理の手順を示すフローチャートであ
る。
【図１６】本発明のディスク管理方法の第１実施形態に
おけるバックアップ情報であるＨｉｓｔｏｒｙ Ｔａｂ
ｌｅから特定のファイルあるいはディレクトリに関する
更新履歴を把握する処理の手順を示すフローチャートで
ある。
おけるバックアップ情報であるＨｉｓｔｏｒｙ Ｔａｂ
ｌｅから特定のファイルあるいはディレクトリに関する
更新履歴を把握する処理の手順を示すフローチャートで
ある。
【図１７】本発明のディスク管理方法の第１実施形態に
おけるバックアップ情報であるＨｉｓｔｏｒｙ Ｔａｂ
ｌｅを用いてＵＤＦファイルシステムにおけるファイル
を管理するＦｉｌｅ Ｅｎｔｒｙを復旧する手順を示す
フローチャートである。
おけるバックアップ情報であるＨｉｓｔｏｒｙ Ｔａｂ
ｌｅを用いてＵＤＦファイルシステムにおけるファイル
を管理するＦｉｌｅ Ｅｎｔｒｙを復旧する手順を示す
フローチャートである。
【図１８】本発明のディスク管理方法の第１実施形態に
おけるバックアップ情報であるＨｉｓｔｏｒｙ Ｔａｂ
ｌｅを用いてＵＤＦファイルシステムにおけるディレク
トリを管理するＦｉｌｅ Ｅｎｔｒｙを復旧する手順を
示すフローチャートである。
おけるバックアップ情報であるＨｉｓｔｏｒｙ Ｔａｂ
ｌｅを用いてＵＤＦファイルシステムにおけるディレク
トリを管理するＦｉｌｅ Ｅｎｔｒｙを復旧する手順を
示すフローチャートである。
【図１９】本発明のディスク管理方法の第２実施形態に
おけるＰｒｉｍａｒｙ Ｈｉｓｔｏｒｙ Ｔａｂｌｅ
Ｄｅｓｃｒｉｐｔｏｒを示す説明図である。
おけるＰｒｉｍａｒｙ Ｈｉｓｔｏｒｙ Ｔａｂｌｅ
Ｄｅｓｃｒｉｐｔｏｒを示す説明図である。
【図２０】本発明のディスク管理方法の第２実施形態に
おけるＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを示す説
明図である。
おけるＨｉｓｔｏｒｙ Ｄｅｓｃｒｉｐｔｏｒを示す説
明図である。
【図２１】本発明のディスク管理方法の第２実施形態に
おけるディレクトリ階層の例を示す説明図である。
おけるディレクトリ階層の例を示す説明図である。
【図２２】本発明のディスク管理方法の第２実施形態に
おける図６に対応するＵＤＦ管理情報とデータのディス
ク上での配置の例を示す説明図である。
おける図６に対応するＵＤＦ管理情報とデータのディス
ク上での配置の例を示す説明図である。
【図２３】本発明のディスク管理方法の第２実施形態に
おける図７に対応するＨｉｓｔｏｒｙ Ｔａｂｌｅの一
例を示す説明図である。
おける図７に対応するＨｉｓｔｏｒｙ Ｔａｂｌｅの一
例を示す説明図である。
【図２４】本発明のディスク管理方法の第２実施形態に
おいてファイルが追加になった場合のＨｉｓｔｏｒｙ
Ｔａｂｌｅの更新の様子を示す説明図である。
おいてファイルが追加になった場合のＨｉｓｔｏｒｙ
Ｔａｂｌｅの更新の様子を示す説明図である。
【図２５】本発明のディスク管理方法の第２実施形態に
おいてファイルが変更になった場合のＨｉｓｔｏｒｙ
Ｔａｂｌｅの更新の様子を示す説明図である。
おいてファイルが変更になった場合のＨｉｓｔｏｒｙ
Ｔａｂｌｅの更新の様子を示す説明図である。
【図２６】本発明のディスク管理方法の第２実施形態に
おいてファイルが削除になった場合のＨｉｓｔｏｒｙ
Ｔａｂｌｅの更新の様子を示す説明図である。
おいてファイルが削除になった場合のＨｉｓｔｏｒｙ
Ｔａｂｌｅの更新の様子を示す説明図である。
【図２７】本発明のディスク管理方法の第２実施形態に
おいてＨｉｓｔｏｒｙ Ｔａｂｌｅを再構築する様子を
示す説明図である。
おいてＨｉｓｔｏｒｙ Ｔａｂｌｅを再構築する様子を
示す説明図である。
【図２８】本発明のディスク管理方法の第２実施形態に
おけるファイルやディレクトリの作成、変更、削除と言
ったイベントが発生した際の処理の手順を示すフローチ
ャートである。
おけるファイルやディレクトリの作成、変更、削除と言
ったイベントが発生した際の処理の手順を示すフローチ
ャートである。
【図２９】本発明のディスク管理方法の第２実施形態に
おけるバックアップ情報であるＨｉｓｔｏｒｙ Ｔａｂ
ｌｅにアクセスする際の処理の手順を示すフローチャー
トである。
おけるバックアップ情報であるＨｉｓｔｏｒｙ Ｔａｂ
ｌｅにアクセスする際の処理の手順を示すフローチャー
トである。
【図３０】本発明のディスク管理方法の第２実施形態に
おけるバックアップ情報であるＨｉｓｔｏｒｙ Ｔａｂ
ｌｅを再構築際の処理の手順を示すフローチャートであ
る。
おけるバックアップ情報であるＨｉｓｔｏｒｙ Ｔａｂ
ｌｅを再構築際の処理の手順を示すフローチャートであ
る。
【図３１】本発明のディスク管理方法の第２実施形態に
おけるバックアップ情報であるＨｉｓｔｏｒｙ Ｔａｂ
ｌｅから特定のファイルあるいはディレクトリに関する
更新履歴を把握する処理の手順を示すフローチャートで
ある。
おけるバックアップ情報であるＨｉｓｔｏｒｙ Ｔａｂ
ｌｅから特定のファイルあるいはディレクトリに関する
更新履歴を把握する処理の手順を示すフローチャートで
ある。
【図３２】本発明のディスク管理方法の第２実施形態に
おけるバックアップ情報であるＨｉｓｔｏｒｙ Ｔａｂ
ｌｅを用いてＵＤＦファイルシステムにおけるファイル
やディレクトリを管理するＦｉｌｅ Ｅｎｔｒｙを復旧
する手順を示すフローチャートである。
おけるバックアップ情報であるＨｉｓｔｏｒｙ Ｔａｂ
ｌｅを用いてＵＤＦファイルシステムにおけるファイル
やディレクトリを管理するＦｉｌｅ Ｅｎｔｒｙを復旧
する手順を示すフローチャートである。
【図３３】本発明のディスク管理方法の第２実施形態に
おけるディレクトリ構造を管理するＵＤＦ管理情報の２
重化の様子の説明図である。
おけるディレクトリ構造を管理するＵＤＦ管理情報の２
重化の様子の説明図である。
【図３４】従来技術における論理ファイルシステムの管
理情報とデータの記録される領域の様子の説明図であ
る。
理情報とデータの記録される領域の様子の説明図であ
る。
【図３５】従来技術における論理ファイルシステムの管
理情報とデータの記録される領域が別れているファイル
システムの様子の説明図である。
理情報とデータの記録される領域が別れているファイル
システムの様子の説明図である。
１ データ入出力部 ２ データ処理部 ３ メモリ ４ システム制御部 ５ ディスク制御部 ６ ディスク
───────────────────────────────────────────────────── フロントページの続き (72)発明者 西村 元秀 大阪府大阪市阿倍野区長池町22番22号 シ ャープ株式会社内 (72)発明者 木山 次郎 大阪府大阪市阿倍野区長池町22番22号 シ ャープ株式会社内 (72)発明者 山村 博幸 大阪府大阪市阿倍野区長池町22番22号 シ ャープ株式会社内 (72)発明者 山口 孝好 大阪府大阪市阿倍野区長池町22番22号 シ ャープ株式会社内 (72)発明者 木付 英士 大阪府大阪市阿倍野区長池町22番22号 シ ャープ株式会社内 Ｆターム(参考） 5B018 GA04 HA22 MA12 5B082 DE01 EA01 GA14
Claims (14)
- 【請求項１】 入力されたデータをファイルとして記録
媒体に記録し、各ファイルを少なくとも該ファイルの記
録媒体上における記録位置情報を含む管理情報により管
理する記録装置におけるファイル管理方法であって、 前記記録媒体へのファイルの追加、変更、削除のアクシ
ョンが行われる毎に、当該ファイルのファイル識別情報
と当該ファイルの記録媒体上の記録位置情報及びファイ
ルのアクション種別を対応づけた履歴情報を順次作成
し、 当該履歴情報を履歴テーブル領域に履歴情報の作成順に
記録することを特徴とするファイル管理方法。 - 【請求項２】 入力されたデータをファイルとして記録
媒体に記録し、各ファイルを少なくとも該ファイルの記
録媒体上における記録位置情報を含む管理情報により管
理する記録装置におけるファイル管理方法であって、 前記履歴情報を前記ファイル及び管理情報の記録領域と
は異なる履歴テーブル領域に履歴情報の作成順に記録す
ることを特徴とする請求項１に記載のファイル管理方
法。 - 【請求項３】 入力されたデータをファイルとして記録
媒体に記録し、各ファイルを少なくとも該ファイルの記
録媒体上における記録位置情報を含む管理情報により管
理する記録装置におけるファイル管理方法であって、 ファイルとして管理される、前記履歴情報を記録する履
歴テーブル領域に履歴情報の作成順に記録することを特
徴とする請求項１に記載のファイル管理方法。 - 【請求項４】 入力されたデータをファイルとして記録
媒体に記録し、各ファイルを少なくとも該ファイルの記
録媒体上における記録位置情報を含む管理情報により管
理する記録装置におけるファイル管理方法であって、 前記記録媒体へのファイルの追加、変更、削除のアクシ
ョンが行われる毎に、前記履歴テーブル領域に記録する
前記ファイル識別情報として、当該ファイルのファイル
名あるいはファイルＩＤを含むことを特徴とする請求項
１乃至請求項３に記載のファイル管理方法。 - 【請求項５】 入力されたデータをファイルとして記録
媒体に記録し、各ファイルを少なくとも該ファイルの記
録媒体上における記録位置情報を含む管理情報により管
理する記録装置におけるファイル管理方法であって、 前記記録媒体へのファイルの追加、変更、削除のアクシ
ョンが行われる毎に、前記履歴テーブル領域に記録する
前記ファイル識別情報として、当該ファイルを管理する
管理情報の記録媒体上の記録位置情報を含むことを特徴
とする請求項１乃至請求項３に記載のファイル管理方
法。 - 【請求項６】 入力されたデータをファイルとして記録
媒体に記録し、各ファイルを少なくとも該ファイルの記
録媒体上における記録位置情報を含む管理情報により管
理する記録装置におけるファイル管理方法であって、 前記記録媒体へのファイルの追加、変更、削除のアクシ
ョンが行われる毎に、前記履歴テーブル領域に記録する
前記履歴情報として、当該ファイルを管理する管理情報
の記録媒体上の記録位置情報を含むことを特徴とする請
求項４に記載のファイル管理方法。 - 【請求項７】 前記記録媒体へのファイルの追加、変
更、削除のアクションが行われる毎に、前記履歴情報を
記録装置のメモリ上に順次作成し、前記記録装置におい
て、前記記録媒体の取り出し指示が行われた場合、当該
履歴情報を該記録媒体上の履歴テーブル領域に記録する
ことを特徴とする前記請求項１乃至請求項６に記載のフ
ァイル管理方法。 - 【請求項８】 前記記録媒体へのファイルの追加、変
更、削除のアクションが行われる毎に、前記履歴情報を
記録装置のメモリ上に順次作成し、前記記録装置におい
て、メモリへの電源供給切断指示が行われた場合、当該
履歴情報を該記録媒体上の履歴テーブル領域に記録する
ことを特徴とする前記請求項１乃至請求項６に記載のフ
ァイル管理方法。 - 【請求項９】 履歴テーブルの履歴確認指示に基づい
て、前記履歴テーブル領域に記録された履歴情報のう
ち、所定のファイル識別情報を有する履歴情報のみを抽
出することを特徴とする前記請求項１乃至請求項８のい
ずれかに記載のファイル管理方法。 - 【請求項１０】 履歴テーブルの再構築指示に基づい
て、前記履歴テーブル領域に記録された履歴情報のう
ち、同一のファイル識別情報を有する履歴情報を、当該
履歴情報のアクション種別に応じて一つの履歴情報に統
合し、履歴テーブル領域を縮小することを特徴とする前
記請求項１乃至請求項９のいずれかに記載のファイル管
理方法。 - 【請求項１１】 前記管理情報は、ディレクトリの管理
情報を含み、前記記録媒体へのディレクトリ情報の追
加、削除のアクションが行われる毎に、当該ディレクト
リの識別情報とアクション種別を対応づけた履歴情報を
順次作成し、当該履歴情報を履歴テーブル領域に順次追
記記録することを特徴とする前記請求項１乃至請求項１
０のいずれかに記載のファイル管理方法。 - 【請求項１２】 前記履歴情報を履歴テーブル領域に順
次追記記録する際、前記履歴テーブル領域の後方から前
方方向へ順番に記録することを特徴する前記請求項１乃
至請求項１１のいずれかに記載のファイル管理方法。 - 【請求項１３】 ファイルの読出し指示に基づいて、前
記管理情報を検索して、ファイルの読出しを行う際、当
該ファイルの管理情報が読み出せない場合、前記履歴テ
ーブル領域から、当該ファイルのファイル識別情報を有
する最新の履歴情報を読出し、当該履歴情報に基づいて
ファイルの読出しを行うことを特徴とする前記請求項１
乃至請求項１２に記載のファイル管理方法。 - 【請求項１４】 管理情報の再構築指示に基づいて、前
記履歴テーブル領域から履歴情報を読みだし、当該履歴
情報に基づいて、管理情報を生成し、当該管理情報を記
録媒体に記録することを特徴とする前記請求項１乃至請
求項１３のいずれかに記載のファイル管理方法。
Priority Applications (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001170443A JP2002082825A (ja) | 2000-06-23 | 2001-06-06 | ファイル管理方法 |
| KR1020027017476A KR100546524B1 (ko) | 2000-06-23 | 2001-06-21 | 파일 관리 방법 |
| US10/312,483 US20030163449A1 (en) | 2000-06-23 | 2001-06-21 | File managing method |
| CNB018144322A CN1265293C (zh) | 2000-06-23 | 2001-06-21 | 文件管理方法 |
| EP01941155A EP1306761B1 (en) | 2000-06-23 | 2001-06-21 | File managing method |
| PCT/JP2001/005315 WO2001098905A1 (fr) | 2000-06-23 | 2001-06-21 | Procédé de gestion des fichiers |
| DE60144424T DE60144424D1 (de) | 2000-06-23 | 2001-06-21 | Dateiverwaltungsverfahren |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000-188671 | 2000-06-23 | ||
| JP2000188671 | 2000-06-23 | ||
| JP2001170443A JP2002082825A (ja) | 2000-06-23 | 2001-06-06 | ファイル管理方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2002082825A true JP2002082825A (ja) | 2002-03-22 |
Family
ID=26594509
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001170443A Pending JP2002082825A (ja) | 2000-06-23 | 2001-06-06 | ファイル管理方法 |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US20030163449A1 (ja) |
| EP (1) | EP1306761B1 (ja) |
| JP (1) | JP2002082825A (ja) |
| KR (1) | KR100546524B1 (ja) |
| CN (1) | CN1265293C (ja) |
| DE (1) | DE60144424D1 (ja) |
| WO (1) | WO2001098905A1 (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100600933B1 (ko) | 2003-06-24 | 2006-07-13 | 인터내셔널 비지네스 머신즈 코포레이션 | 파일 시스템 백업 방법, 컴퓨터 판독 가능 기록 매체 및 데이터 처리 시스템 |
| JP2007080185A (ja) * | 2005-09-16 | 2007-03-29 | Canon Inc | 情報処理装置、情報処理方法、プログラム及び記憶媒体 |
Families Citing this family (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7185013B2 (en) * | 2001-04-12 | 2007-02-27 | International Business Machines Corporation | Method for constructing and caching a chain of file identifiers and enabling inheritance of resource properties in file systems |
| GB0302602D0 (en) * | 2003-02-04 | 2003-03-12 | Young Arthur P | Equipment and methods for real time application |
| TW200519592A (en) * | 2003-11-06 | 2005-06-16 | Matsushita Electric Ind Co Ltd | Information recording medium, access apparatus thereof and recording region setting method |
| KR100992679B1 (ko) | 2003-11-14 | 2010-11-05 | 엘지전자 주식회사 | 이동통신 단말기의 컨텐츠 첨부 방법 |
| JP4106662B2 (ja) * | 2003-11-17 | 2008-06-25 | ソニー株式会社 | 情報記録再生装置および方法、プログラム格納媒体、並びにプログラム |
| US7328217B2 (en) * | 2003-11-26 | 2008-02-05 | Symantec Operating Corporation | System and method for detecting and storing file identity change information within a file system |
| KR20050058939A (ko) * | 2003-12-13 | 2005-06-17 | 삼성전자주식회사 | 광디스크의 파일 시스템 포맷의 변환 방법 및 그 장치 |
| US20050152251A1 (en) * | 2004-01-08 | 2005-07-14 | Victor Company Of Japan, Ltd. | Method and apparatus for recording check data of file system on recording medium |
| JP2005267559A (ja) * | 2004-03-22 | 2005-09-29 | Sony Corp | 記録再生装置、情報転送管理方法および記録媒体 |
| US7610296B2 (en) * | 2004-12-17 | 2009-10-27 | Microsoft Corporation | Prioritized files |
| JP4665963B2 (ja) * | 2005-02-14 | 2011-04-06 | セイコーエプソン株式会社 | 外部記録媒体書き込み装置を用いたデータ管理方法およびデータ管理システム |
| US7672979B1 (en) * | 2005-04-22 | 2010-03-02 | Symantec Operating Corporation | Backup and restore techniques using inconsistent state indicators |
| JP2007128448A (ja) * | 2005-11-07 | 2007-05-24 | Sony Corp | ファイルシステム及びファイル情報処理方法 |
| KR100843075B1 (ko) * | 2006-05-29 | 2008-07-03 | 삼성전자주식회사 | 데이터를 관리하는 장치 및 방법 |
| KR100877063B1 (ko) * | 2006-05-29 | 2009-01-07 | 삼성전자주식회사 | 데이터를 관리하는 장치 및 방법 |
| CN101237512B (zh) * | 2007-01-31 | 2010-09-15 | 三洋电机株式会社 | 内容处理设备 |
| JP5132676B2 (ja) * | 2007-04-25 | 2013-01-30 | パナソニック株式会社 | 情報再生方法及び情報再生装置 |
| KR101207510B1 (ko) * | 2008-12-18 | 2012-12-03 | 한국전자통신연구원 | 클러스터 데이터 관리시스템 및 클러스터 데이터 관리 시스템에서 공유 재수행 로그를 이용한 데이터 재구축 방법 |
| US8073875B2 (en) * | 2009-04-22 | 2011-12-06 | International Business Machines Corporation | Managing deleted directory entries |
| US8285754B2 (en) * | 2009-04-22 | 2012-10-09 | International Business Machines Corporation | Preserving references to deleted directory entries |
| JP2014067112A (ja) * | 2012-09-25 | 2014-04-17 | Sony Corp | 情報処理装置および方法、並びにプログラム |
| US9892121B2 (en) * | 2014-07-15 | 2018-02-13 | Hitachi, Ltd. | Methods and systems to identify and use event patterns of application workflows for data management |
| US20160026941A1 (en) * | 2014-07-26 | 2016-01-28 | International Business Machines Corporation | Updating and synchronizing existing case instances in response to solution design changes |
| CN106156129A (zh) * | 2015-04-08 | 2016-11-23 | 联想(北京)有限公司 | 文件管理方法及装置 |
| US9910968B2 (en) * | 2015-12-30 | 2018-03-06 | Dropbox, Inc. | Automatic notifications for inadvertent file events |
| KR20210026143A (ko) | 2019-08-29 | 2021-03-10 | 삼성전자주식회사 | 파일 시스템에 저장된 파일 또는 디렉토리의 크기를 획득하기 위한 전자 장치 및 방법 |
| US11586493B2 (en) * | 2021-03-29 | 2023-02-21 | Red Hat, Inc. | Efficient checksum computation |
| CN116541347B (zh) * | 2023-06-29 | 2023-12-01 | 北京数场科技有限责任公司 | 获得文档认知的方法、装置以及计算设备 |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4827462A (en) * | 1987-03-26 | 1989-05-02 | International Business Machines Corporation | Modular data storage directories for large-capacity data storage units |
| JP2633614B2 (ja) * | 1988-03-29 | 1997-07-23 | 株式会社日立製作所 | フアイル保護装置 |
| US5214781A (en) * | 1988-07-25 | 1993-05-25 | Matsushita Electric Industrial Co., Ltd. | Method of managing storage medium |
| JPH02132516A (ja) * | 1988-11-11 | 1990-05-22 | Matsushita Electric Ind Co Ltd | 書込可能型光ディスク管理システム及び方法 |
| JPH0620442A (ja) * | 1992-07-02 | 1994-01-28 | Toshiba Corp | 光磁気ディスクの障害復旧方法 |
| JPH08147702A (ja) * | 1994-11-11 | 1996-06-07 | Mitsumi Electric Co Ltd | 光ディスク書き込み方法 |
-
2001
- 2001-06-06 JP JP2001170443A patent/JP2002082825A/ja active Pending
- 2001-06-21 CN CNB018144322A patent/CN1265293C/zh not_active Expired - Fee Related
- 2001-06-21 WO PCT/JP2001/005315 patent/WO2001098905A1/ja active IP Right Grant
- 2001-06-21 EP EP01941155A patent/EP1306761B1/en not_active Expired - Lifetime
- 2001-06-21 US US10/312,483 patent/US20030163449A1/en not_active Abandoned
- 2001-06-21 KR KR1020027017476A patent/KR100546524B1/ko not_active IP Right Cessation
- 2001-06-21 DE DE60144424T patent/DE60144424D1/de not_active Expired - Lifetime
Non-Patent Citations (4)
| Title |
|---|
| CSNB200100200001, ヴァハリア ユーレッシュ, 最前線ＵＮＩＸのカーネル 初版, 20000515, 第１版, ｐ．３９７−４１４, JP, 株式会社ピアソン・エデュケーション * |
| CSND200200686010, 石川 睦, "最新ファイル・システムを検証する Ｐａｒｔ３ Ｅｘｔ３ ｖｓ ＲｅｉｓｅｒＦＳ ｖｓ ＸＦＳ", ＵＮＩＸ ＵＳＥＲ, 20000601, 第９巻第６号, ｐ． ９９−１０８, JP, ソフトバンクパブリッシング株式会社 * |
| JPN6010052670, ヴァハリア ユーレッシュ, 最前線ＵＮＩＸのカーネル 初版, 20000515, 第１版, ｐ．３９７−４１４, JP, 株式会社ピアソン・エデュケーション * |
| JPN6010052671, 石川 睦, "最新ファイル・システムを検証する Ｐａｒｔ３ Ｅｘｔ３ ｖｓ ＲｅｉｓｅｒＦＳ ｖｓ ＸＦＳ", ＵＮＩＸ ＵＳＥＲ, 20000601, 第９巻第６号, ｐ． ９９−１０８, JP, ソフトバンクパブリッシング株式会社 * |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100600933B1 (ko) | 2003-06-24 | 2006-07-13 | 인터내셔널 비지네스 머신즈 코포레이션 | 파일 시스템 백업 방법, 컴퓨터 판독 가능 기록 매체 및 데이터 처리 시스템 |
| US7092976B2 (en) | 2003-06-24 | 2006-08-15 | International Business Machines Corporation | Parallel high speed backup for a storage area network (SAN) file system |
| JP2007080185A (ja) * | 2005-09-16 | 2007-03-29 | Canon Inc | 情報処理装置、情報処理方法、プログラム及び記憶媒体 |
| JP4708938B2 (ja) * | 2005-09-16 | 2011-06-22 | キヤノン株式会社 | 情報処理装置、情報処理方法、プログラム及び記憶媒体 |
Also Published As
| Publication number | Publication date |
|---|---|
| DE60144424D1 (de) | 2011-05-26 |
| KR100546524B1 (ko) | 2006-01-26 |
| WO2001098905A1 (fr) | 2001-12-27 |
| US20030163449A1 (en) | 2003-08-28 |
| CN1265293C (zh) | 2006-07-19 |
| EP1306761A4 (en) | 2004-10-20 |
| CN1447939A (zh) | 2003-10-08 |
| KR20030010751A (ko) | 2003-02-05 |
| EP1306761A1 (en) | 2003-05-02 |
| EP1306761B1 (en) | 2011-04-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2002082825A (ja) | ファイル管理方法 | |
| JP3938594B2 (ja) | ファイル名生成装置 | |
| US7934064B1 (en) | System and method for consolidation of backups | |
| US6665815B1 (en) | Physical incremental backup using snapshots | |
| JP4256851B2 (ja) | ファイル・システム・スナップショットの永続性のための方法および装置 | |
| CN108319602B (zh) | 数据库管理方法及数据库系统 | |
| US8874517B2 (en) | Summarizing file system operations with a file system journal | |
| CN108009098B (zh) | 具有经压缩的正向映射的存储分层 | |
| US9773059B2 (en) | Tape data management | |
| JPH10124367A (ja) | ファイルおよびディレクトリを変換する方法 | |
| US5963961A (en) | Database reconstruction using embedded database backup codes | |
| JP2007233638A (ja) | 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム | |
| KR100927282B1 (ko) | 기록 방법, 기록 장치 및 기록 매체 | |
| JP2005050073A (ja) | データ復旧方法およびデータ記録装置 | |
| US20050262033A1 (en) | Data recording apparatus, data recording method, program for implementing the method, and program recording medium | |
| US6697813B1 (en) | Data structures and methods for imaging computer readable media | |
| JP2005189982A (ja) | データ保存装置及びデータ保存方法 | |
| CN111258503B (zh) | 一种cirros文件系统的管理方法和装置 | |
| JP2002373099A (ja) | ディスク管理方法 | |
| JP2001249838A (ja) | ファイル管理方法 | |
| JPH09152983A (ja) | フラッシュメモリに内在するファイルシステムにおけるリエントラントガーベジコレクション処理 | |
| JPH0844609A (ja) | データバックアップ方法 | |
| WO2001067251A1 (fr) | Procede de gestion de fichiers | |
| JP2004206742A (ja) | 記録再生装置 | |
| JP2001092701A (ja) | ファイル復旧方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20071026 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20071205 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20100513 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100914 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20110125 |