JP2001249838A - File managing method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To solve problems that the maximum number of files which can be managed is restricted by the size of a management area since the management area and a management area for backup have to be secured in advance when backup is performed by separating the management area from an actual data area beforehand and duplicating the management area in a file system and technique to duplicate the whole management area cannot be applied since no concept of the management area exists in the file system to record the management area and the data area in the same area. SOLUTION: These problems are solved by successively creating pieces of history information in which the file identifiers of the files are correlated to the recording position information on the files on a recording medium and the action types of the files whenever adding, changing and deleting actions of the files in the recording medium are performed and recording the history information in a history table area different from the recording areas of he files and management information in the order of creation of pieces of the history information.

Description

【発明の詳細な説明】DETAILED DESCRIPTION OF THE INVENTION

【０００１】[0001]

【発明の属する技術分野】本発明は、記録媒体における
ファイルのバックアップ等に関するファイル管理方法に
関するものである。BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a file management method for backing up a file on a recording medium.

【０００２】[0002]

【従来の技術】PC用途やAV用途など様々な用途でディス
ク媒体にデータを記録する場合、論理ファイルシステム
を用いる事が一般的である。論理ファイルシステムを用
いる事によって、記録したデータをファイルとして管理
し、ディレクトリ階層を構築する事が可能となり管理が
容易となる。論理ファイルシステムとしては、広く普及
しているFAT方式やDVDなどで導入されているUDF（Unive
rsal Disk Format）などが挙げられる。2. Description of the Related Art When recording data on a disk medium for various uses such as PC use and AV use, it is common to use a logical file system. By using a logical file system, recorded data can be managed as a file, and a directory hierarchy can be constructed, which facilitates management. As a logical file system, UDF (Unive
rsal Disk Format).

【０００３】論理ファイルシステムとは、ディスクに記
録されたデータに対してデータを識別するための情報
と、データが記録されたディスク上の位置情報などを管
理情報としてディスクに記録し、それらの情報にアクセ
スする事によってファイルアクセスを可能とする仕組み
の事である。例えば、論理ファイルシステムの管理情報
には、ファイル名、そのファイルに関する作成日時、フ
ァイルサイズ、状態を示す情報などの属性情報、対応す
る実データが記録されているディスク上の位置情報など
が記録されている。FATやUDFなどと言った様々な種類の
論理ファイルシステムが存在するが、これらの管理情報
の構成や管理する属性情報が異なるだけで、ファイル名
あるいはそれに準ずる情報からディスク上の目的のデー
タにアクセスができると言った意味では同じ目的のため
のものである。[0003] A logical file system records information for discriminating data recorded on a disc, positional information on the disc on which the data is recorded, and the like as management information on the disc. Is a mechanism that enables file access by accessing. For example, in the management information of the logical file system, attribute information such as a file name, a creation date and time, a file size, information indicating a status of the file, and position information on the disk where the corresponding actual data is recorded are recorded. ing. There are various types of logical file systems such as FAT and UDF, but only the structure of the management information and the attribute information to be managed are different, and the target data on the disk can be accessed from the file name or similar information. In the sense that they can be done for the same purpose.

【０００４】このような論理ファイルシステムを用いた
ディスクを通常使用している場合には全く問題は無い
が、場合によってディスクに記録した情報が読み出せな
いと言った事が起こる可能性がある。例えば、何らかの
ショックによってディスク自体に傷が付いてしまった
り、書き込み中にショックが加わり本来書き込むべき箇
所でない所に書き込みを行ない記録内容を書き変えてし
まったり、リムーバブルディスクの場合はディスクの表
面に汚れが付着してしまったりする事によって発生する
事が考えられる。There is no problem when a disk using such a logical file system is normally used, but there is a possibility that information recorded on the disk cannot be read in some cases. For example, the disk itself may be damaged by a shock, a shock may be applied during writing, writing may be performed at a place that should not be written, and the recorded contents may be rewritten.In the case of a removable disk, the surface of the disk may become dirty. It is conceivable that this may be caused by adhering.

【０００５】ディスクに書き込む前に問題のある箇所が
発見できた場合には、ディスクの問題の箇所の代わりに
代替領域に記録するディフェクトマネジメント機能を利
用する事によって問題を回避できるが、情報を書いた後
に問題が発生すると、その情報をディスクから読み出せ
なくなってしまい問題がある。記録したデータ自体が読
みだせない事も問題であるが、前述した論理ファイルシ
ステムの管理情報がディスクから読みだせない事の方が
問題となる。仮にあるファイルにアクセスするための論
理ファイルシステムの管理情報が何らかの理由によって
読み出せないと、例えディスク上のデータに影響が無く
ても、対応するデータがディスクのどこに記録されてい
たかが不明となるため、データにアクセスできなくなっ
てしまう。[0005] If a problematic part is found before writing to the disc, the problem can be avoided by using a defect management function of recording in an alternative area instead of the problematic part of the disc. If a problem occurs after the operation, the information cannot be read from the disk, which causes a problem. The problem is that the recorded data itself cannot be read, but the problem is that the management information of the logical file system cannot be read from the disk. If the management information of the logical file system for accessing a certain file cannot be read for some reason, it is unknown where the corresponding data is recorded on the disk even if the data on the disk is not affected. , The data becomes inaccessible.

【０００６】PC用途で使用しているディスクでは、この
ような事が起こる可能性は稀である。これは、PC用途の
ドライブが物理的に安定した環境で使用されていること
が多いためである。一方、AV用途でリムーバブルディス
クを記録媒体としたビデオカメラなどを考えた場合、必
ずしも物理的に安定した環境で使用されるとは限らな
い。ビデオカメラなので手に持って撮影するが、走りな
がらの撮影や、何かにぶつかったりとディスクにデータ
を記録している最中にショックが加わる事も考えられ
る。このように、PC用途で使用する場合と比較して苛酷
な状況で使用される事が考えられ、前述したような予期
せねディスクからデータが読み出せないと言った状況が
発生する確率が高くなる。[0006] In a disk used for PC use, such a possibility is rarely caused. This is because PC drives are often used in physically stable environments. On the other hand, when considering a video camera or the like using a removable disk as a recording medium for AV use, it is not always used in a physically stable environment. Since it is a video camera, you can hold it in your hand and shoot, but it is possible that a shock will be applied while recording data on the disc such as shooting while running or hitting something. In this way, it is conceivable that it will be used in a more severe situation than when it is used for PC applications, and there is a high probability that the situation that data cannot be read from the disk unexpectedly as described above will occur. Become.

【０００７】このような、論理ファイルシステムの管理
情報が読み出せない事によって、データにアクセス出来
なくなってしまう問題を解決するためには、論理ファイ
ルシステムの管理情報を多重する事が考えられる。つま
り、ディスク上に論理ファイルシステムの管理情報を多
重する事によって、万が一ある管理情報が読み出せなく
なった場合でも多重化してあるバックアップの管理情報
を元に、データへのアクセスを可能とする事ができる。In order to solve such a problem that data cannot be accessed due to the inability to read the management information of the logical file system, it is conceivable to multiplex the management information of the logical file system. In other words, by multiplexing the management information of the logical file system on the disk, it is possible to access data based on the management information of the multiplexed backup even in the event that certain management information cannot be read. it can.

【０００８】図１８にその様子を示す。このファイルシ
ステムでは、ファイルシステムの管理情報とデータを記
録する領域を区別し、それぞれがディスク上の対応する
領域に記録される。ファイルシステムの管理情報が実際
にはファイルが記録される領域とは別の所定の領域に記
録されるので、管理領域は必ずこの領域内に記録される
ことになる。よって、この管理情報記録領域と全く同じ
状態のバックアップ用の領域を用意する事によって管理
情報を多重する事が可能となる。FIG. 18 shows the situation. In this file system, areas for recording data and management information of the file system are distinguished, and each is recorded in a corresponding area on the disk. Since the management information of the file system is actually recorded in a predetermined area different from the area where the file is recorded, the management area is always recorded in this area. Therefore, by preparing a backup area in the same state as the management information recording area, management information can be multiplexed.

【０００９】[0009]

【発明が解決しようとする課題】上記した図１８に示す
ように、管理領域と実データ領域を予め分離しておき、
管理領域を２重化することでバックアップを行う場合、
逆に管理領域及びバックアップ用の管理領域を予め確保
しておく必要があるため、管理領域の大きさから管理で
きる最大ファイル数の制限がでてきてしまうという問題
がある。As shown in FIG. 18, the management area and the real data area are separated in advance,
When performing backup by duplicating the management area,
Conversely, since it is necessary to secure a management area and a management area for backup in advance, there is a problem that the maximum number of files that can be managed is limited due to the size of the management area.

【００１０】また、上記したFATやUDFファイルシステム
は図１７に示すように管理領域とデータ領域が同じ領域
に記録されていくことになる。このようなファイルシス
テムにおいて、管理領域という概念はないので、管理領
域ごと２重化するという手法は適用できない。In the FAT or UDF file system described above, the management area and the data area are recorded in the same area as shown in FIG. In such a file system, since there is no concept of a management area, a method of duplicating each management area cannot be applied.

【００１１】また、ファイルシステムの管理情報はディ
レクトリ階層を構成するように管理されており、各管理
情報の間にはこのディレクトリ階層に従った結び付き
（ディスク上のアドレス位置でリンクされている）があ
るため、単純に管理情報を２重化することは容易ではな
い。例えば、ディレクトリを管理する管理情報にはその
ディレクトリ内に定義されるファイルやディレクトリを
管理する管理情報が記録されているアドレス位置が記述
されている。よって、これらの論理ファイルシステムの
管理情報を所定のバックアップ領域に単純にコピーする
という方法で多重化する場合、管理情報間の連結情報で
あるディスク上のアドレスを、バックアップ領域内に記
録する管理情報の記録位置に応じて変更しなければなら
ない。The management information of the file system is managed so as to form a directory hierarchy, and a link (linked at an address position on a disk) according to the directory hierarchy is established between the management information. Therefore, it is not easy to simply duplicate management information. For example, in the management information for managing a directory, an address position where management information for managing a file defined in the directory or the directory is described. Therefore, when the management information of these logical file systems is multiplexed by simply copying the management information to a predetermined backup area, the management information for recording the address on the disk, which is the link information between the management information, in the backup area. Must be changed according to the recording position of

【００１２】このような構成であると、ファイルの作
成、変更、削除のタイミングで、実際の管理情報を更新
するとともに、バックアップの管理情報のアドレスの更
新処理を行う必要があり、バックアップ作成に多くの処
理が必要となってしまう。With such a configuration, it is necessary to update the actual management information at the time of file creation, change, and deletion, and to update the address of the backup management information. Processing is required.

【００１３】本願は上記したような課題を解決するもの
であり、ファイルやディレクトリに関する作成、変更、
削除などといったイベントが発生した場合、そのファイ
ル或いはディレクトリの識別情報と、当該ファイルのデ
ィスク上での位置あるいはディレクトリ情報（そのディ
レクトリに含まれるファイルやディレクトリの管理情報
が記録されているディスク上の位置）の位置とを対応づ
けて履歴情報として作成し、当該履歴情報をファイルや
管理情報を記録する領域以外の領域に記録することで、
管理情報が正常に読み出せない場合においても、ファイ
ルを読み出すことを可能とし、また、バックアップ作成
時に複雑な処理を行う必要がない。[0013] The present invention solves the above-described problems, and includes creation and modification of files and directories.
When an event such as deletion occurs, the identification information of the file or directory and the location of the file on the disk or directory information (the location on the disk where the management information of the file or directory included in the directory is recorded) ) Is created as history information in association with the position, and the history information is recorded in an area other than the area where the file or the management information is recorded.
Even when the management information cannot be read normally, it is possible to read the file, and it is not necessary to perform complicated processing when creating a backup.

【００１４】[0014]

【課題を解決するための手段】本願の第１の発明によれ
ば、入力されたデータをファイルとして記録媒体に記録
し、各ファイルを少なくとも該ファイルの記録媒体上に
おける記録位置情報を含む管理情報により管理する記録
装置におけるファイル管理方法であって、前記記録媒体
へのファイルの追加、変更、削除のアクションが行われ
る毎に、当該ファイルのファイル識別子と当該ファイル
の記録媒体上の記録位置情報及びファイルのアクション
種別を対応づけた履歴情報を順次作成し、当該履歴情報
を前記ファイル及び管理情報の記録領域とは異なる履歴
テーブル領域に履歴情報の作成順に記録することにより
上記課題を解決する。According to the first aspect of the present invention, input data is recorded on a recording medium as a file, and each file contains management information including at least recording position information of the file on the recording medium. A file management method in a recording device that manages a file by adding, changing, and deleting a file to or from the recording medium each time an action is performed, the file identifier of the file, the recording position information of the file on the recording medium, and The above object is achieved by sequentially creating history information in which file action types are associated and recording the history information in a history table area different from the file and management information recording areas in the order in which the history information is created.

【００１５】本願の第２の発明によれば、前記記録媒体
へのファイルの追加、変更、削除のアクションが行われ
る毎に、前記履歴情報を記録装置のメモリ上に順次作成
し、前記記録装置において、前記記録媒体の取り出し指
示が行われた場合、当該履歴情報を該記録媒体上の前記
ファイル及び管理情報の記録領域とは異なる履歴テーブ
ル領域に記録することにより上記課題を解決する。According to the second aspect of the present invention, each time an action of adding, changing, or deleting a file to or from the recording medium is performed, the history information is sequentially created on a memory of a recording device. In the above, when the removal instruction of the recording medium is issued, the above problem is solved by recording the history information in a history table area different from the recording area of the file and the management information on the recording medium.

【００１６】本願の第３の発明によれば、前記記録媒体
へのファイルの追加、変更、削除のアクションが行われ
る毎に、前記履歴情報を記録装置のメモリ上に順次作成
し、前記記録装置において、メモリへの電源供給切断指
示が行われた場合、当該履歴情報を該記録媒体上の前記
ファイル及び管理情報の記録領域とは異なる履歴テーブ
ル領域に記録することにより上記課題を解決する。According to the third aspect of the present invention, each time an action of adding, changing, or deleting a file to or from the recording medium is performed, the history information is sequentially created on a memory of a recording device. In the above, when the power supply cutoff instruction to the memory is issued, the above-described problem is solved by recording the history information in a history table area different from a recording area of the file and the management information on the recording medium.

【００１７】本願の第４の発明によれば、履歴テーブル
の履歴確認指示に基づいて、前記履歴テーブル領域に記
録された履歴情報のうち、所定のファイル識別子を有す
る履歴情報のみを抽出することにより上記課題を解決す
る。According to the fourth aspect of the present invention, only history information having a predetermined file identifier is extracted from the history information recorded in the history table area based on the history check instruction of the history table. Solution to the Problems

【００１８】本願の第５の発明によれば、履歴テーブル
の再構築指示に基づいて、前記履歴テーブル領域に記録
された履歴情報のうち、同一のファイル識別子を有する
履歴情報を、当該履歴情報のアクション種別に応じて一
つの履歴情報に統合し、履歴テーブル領域を縮小するこ
とにより上記課題を解決する。According to the fifth aspect of the present invention, the history information having the same file identifier among the history information recorded in the history table area is changed based on the history table restructuring instruction. The above problem is solved by integrating into one piece of history information according to the action type and reducing the history table area.

【００１９】本願の第６の発明によれば、前記履歴情報
は、ファイル識別子の変更を示す履歴情報を含み、ファ
イル識別子の変更により変更されたファイル識別子は、
変更後のファイル識別子と同一ファイルとして履歴確認
或いは再構築を行うことにより上記課題を解決する。According to the sixth aspect of the present invention, the history information includes history information indicating a change of a file identifier, and the file identifier changed by the change of the file identifier is:
The above problem is solved by confirming the history or reconstructing the file as the same file as the changed file identifier.

【００２０】本願の第７の発明によれば、前記管理情報
は、ディレクトリの管理情報を含み、前記記録媒体への
ディレクトリ情報の追加、変更、削除のアクションが行
われる毎に、当該ディレクトリの識別子と当該ディレク
トリ情報の記録媒体上の記録位置情報及びアクション種
別を対応づけた履歴情報を順次作成し、当該履歴情報を
前記ファイル及びディレクトリ情報及び管理情報の記録
領域とは異なる履歴テーブル領域に順次追記記録するこ
とにより上記課題を解決する。According to the seventh aspect of the present invention, the management information includes directory management information, and each time an action of adding, changing, or deleting directory information to the recording medium is performed, an identifier of the directory is used. And record information on the recording medium of the directory information and the action type are sequentially created, and the history information is sequentially added to a history table area different from the recording area of the file, directory information, and management information. The above problem is solved by recording.

【００２１】本願の第８の発明によれば、ファイルの読
出し指示に基づいて、前記管理情報を検索して、ファイ
ルの読出しを行う際、当該ファイルの管理情報が読み出
せない場合、前記履歴テーブル領域から、当該ファイル
のファイル識別子を有する最新の履歴情報を読出し、当
該履歴情報に基づいてファイルの読出しを行うことによ
り上記課題を解決する。According to the eighth aspect of the present invention, when the management information is searched based on a file reading instruction and the file is read, if the management information of the file cannot be read, the history table is read. The above-mentioned problem is solved by reading the latest history information having the file identifier of the file from the area, and reading the file based on the history information.

【００２２】本願の第９の発明によれば、管理情報の再
構築指示に基づいて、前記履歴テーブル領域から履歴情
報を読みだし、当該履歴情報に基づいて、管理情報を生
成し、当該管理情報を記録媒体に記録することにより上
記課題を解決する。According to the ninth aspect of the present invention, history information is read from the history table area based on a management information restructuring instruction, and management information is generated based on the history information. Is recorded on a recording medium to solve the above problem.

【００２３】[0023]

【発明の実施の形態】以下、本発明のディスク管理方法
に関する実施形態について、図1乃至図18とともに詳細
について説明する。本実施例は、ディスク装置として、
AV記録再生を目的としたディスクを用いた携帯型のビデ
オカメラやビデオデッキ、PCに接続された外部記憶装置
などを想定するものである。ディスク媒体は、リムーバ
ブルディスクが好ましいが、ハードディスクなどの据え
付け型であっても構わない。また、説明の都合上ディス
クに用いる論理ファイルシステムとしてOSTA（OpticalS
torage Technology Association）の規格であるUDF（Un
iversal Disk Format）を想定するが、その他の汎用論
理ファイルシステムであっても構わない。DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment relating to a disk management method according to the present invention will be described below in detail with reference to FIGS. In this embodiment, the disk device
It is assumed that a portable video camera or VCR using a disc for AV recording and reproduction, an external storage device connected to a PC, and the like are assumed. The disk medium is preferably a removable disk, but may be a stationary type such as a hard disk. For convenience of explanation, OSTA (OpticalS) is used as a logical file system used for disks.
torage Technology Association) UDF (Un
iversal Disk Format), but other general-purpose logical file systems may be used.

【００２４】一般的なディスク装置の構成を図1に示
す。データ入力出力部１はカメラなどから入力される映
像信号を取り込んだり、再生するデータをモニタ等に出
力したりする。データ処理部2は、例えばMPEG符号をエ
ンコードしたり、デコードしたりする信号処理等を行う
処理部であり、処理されたデータはメモリ3に格納され
る。データを記録する場合は、ディスク制御部5におい
て、ディスク6を制御しディスク上の目的の箇所にデー
タが記録され、再生時には、ディスク6を制御しディス
ク上の目的の箇所からデータが読み出されてメモリ3に
格納される。各処理部はシステム制御部4によって制御
される。FIG. 1 shows the configuration of a general disk drive. The data input / output unit 1 captures a video signal input from a camera or the like and outputs reproduced data to a monitor or the like. The data processing unit 2 is a processing unit that performs, for example, signal processing for encoding and decoding an MPEG code, and the processed data is stored in the memory 3. When recording data, the disc control unit 5 controls the disc 6 to record data at a target location on the disc, and at the time of reproduction, controls the disc 6 to read data from the target location on the disc. And stored in the memory 3. Each processing unit is controlled by the system control unit 4.

【００２５】このようなディスク装置における論理ファ
イルシステムで、論理ファイルシステムの管理情報とデ
ータを記録する領域が明確にわかれている場合、管理情
報の領域を多重する事によって容易に管理情報のバック
アップを持つ事が可能である。しかしながら、論理ファ
イルシステムの管理情報とデータを記録する領域が明確
に分かれていない場合、つまり論理ファイルシステムの
管理情報とデータが同一のディスク空間に記録される場
合は、管理情報のバックアップを容易に持つ事はできな
い。In the logical file system in such a disk device, when the area for recording the management information and data of the logical file system is clearly separated, the management information can be easily backed up by multiplexing the management information area. It is possible to have. However, when the management information of the logical file system and the area for recording the data are not clearly separated, that is, when the management information and the data of the logical file system are recorded in the same disk space, it is easy to back up the management information. You cannot have it.

【００２６】管理情報とデータを記録する領域が明確に
分かれている場合とは異なり、ディスクに分散している
管理情報をある特定の大きさのバックアップ用領域に記
録する事ができないからである。これは、ディレクトリ
の管理情報にそのディレクトリに含まれるファイルやデ
ィレクトリの管理情報が記録されているディスク上のア
ドレスが記述されており、バックアップ領域にバックア
ップする場合、論理ファイルシステムの管理情報間の連
結情報であるディスク上のアドレスを、バックアップ領
域内の管理情報の記録位置に応じて変更しなけらばなら
ない事を意味する。This is because, unlike the case where the areas for recording the management information and the data are clearly separated, the management information distributed on the disk cannot be recorded in a backup area of a specific size. This is because the directory management information describes the addresses on the disk where the files included in the directory and the directory management information are recorded. When backing up to the backup area, the connection between the logical file system management information is performed. This means that the address on the disk, which is information, must be changed according to the recording position of the management information in the backup area.

【００２７】そこで、本発明では特にファイルやディレ
クトリなどの管理情報を多重に持つ機能の無い汎用の論
理ファイルシステムにおいて、管理情報が読み出せなく
なる事によるデータの読み出しが不可能になる事を防ぐ
事を目標としている。Therefore, in the present invention, especially in a general-purpose logical file system having no function of multiplexing management information such as files and directories, it is possible to prevent data reading from becoming impossible due to inability to read management information. The goal is.

【００２８】既にディスクに記録されているファイルや
ディレクトリはUDFのような論理ファイルシステムによ
って管理されているので、論理ファイルシステムの管理
情報のバックアップを取るのにあまり繁雑な操作が発生
してしまっては意味が無い。そこで本発明では、バック
アップ情報として、ファイルやディレクトリにアクセス
するのに必要最低限の情報のみをバックアップするもの
とする。この必要最低限のバックアップ情報をバックア
ップの対象となるファイルシステムの管理する領域とは
別の領域を用意してその領域中に記録する。Since the files and directories already recorded on the disk are managed by a logical file system such as UDF, a very complicated operation has to be performed to back up the management information of the logical file system. Is meaningless. Therefore, in the present invention, as backup information, only minimum information necessary for accessing a file or a directory is backed up. An area different from the area managed by the file system to be backed up is prepared and recorded in the necessary minimum backup information.

【００２９】図2に、本発明で用いるバックアップ領域
とUDF規格によって規定されるパーティションの関係を
示す。UDFでは論理セクタ番号256とディスク上の最後の
論理セクタ番号−256にAnchor Volume Descriptor Poin
terが記録される事が決まっており、この情報にアクセ
スする事によって、Volume Descriptor Sequenceを把握
する事が可能となる。論理セクタ番号とは、ユーザシス
テムがアクセスできるディスク上の空間に昇順に付加さ
れたアドレスの事である。FIG. 2 shows the relationship between the backup area used in the present invention and partitions defined by the UDF standard. In UDF, Anchor Volume Descriptor Point is assigned to logical sector number 256 and last logical sector number -256 on the disk.
It is determined that ter is recorded, and by accessing this information, it is possible to grasp the Volume Descriptor Sequence. The logical sector number is an address added in ascending order to a space on a disk that can be accessed by a user system.

【００３０】また、Anchor Volume Descriptor Pointer
には、Volume全体を管理する管理情報で構成される、Vo
lume Descriptor Sequenceの記録位置が管理されてい
る。Volume Descriptor Sequenceには、Volume内に定義
されるパーティションに関する管理情報が管理されてお
り、実際にファイルやディレクトリを作成するUDFのフ
ァイルシステムを構築するパーティションの位置情報を
取得する事が可能となる。本発明においては、UDFパー
ティション内に記録される論理ファイルシステムの管理
情報のバックアップをUDFパーティションと異なる領域
であるバックアップ情報用領域に記録していく。Also, Anchor Volume Descriptor Pointer
Is composed of management information that manages the entire Volume.
The recording position of the lume Descriptor Sequence is managed. In the Volume Descriptor Sequence, management information on partitions defined in the Volume is managed, and it is possible to acquire the position information of the partition that constructs the UDF file system that actually creates files and directories. In the present invention, the backup of the management information of the logical file system recorded in the UDF partition is recorded in a backup information area which is an area different from the UDF partition.

【００３１】このバックアップ情報用領域の位置情報
は、例えば、論理セクタ番号128に記録される本発明用
のAnchor Descriptorによって把握する事が可能とな
る。また、バックアップ情報用領域の領域の位置を把握
するためのAnchor Descriptorを用いないで、ある特定
の固定位置に領域があると決めて確保しても構わない。
図の例ではVolumeの管理情報のバックアップであるRese
rved Volume Descriptor SequenceがMain Volume Descr
iptor Sequenceの後にも記録されている。The position information of the backup information area can be grasped by, for example, the Anchor Descriptor for the present invention recorded in the logical sector number 128. Alternatively, it is possible to determine and secure an area at a specific fixed position without using an anchor descriptor for grasping the position of the area of the backup information area.
In the example shown in the figure, Rese is a backup of Volume management information.
rved Volume Descriptor Sequence is Main Volume Descr
It is also recorded after the iptor Sequence.

【００３２】また、図3にバックアップ領域の中の様子
を示す。図の中のVolume管理情報は、図2においてバッ
クアップ情報用領域の手前までの領域に対応する。バッ
クアップ領域には、Primary History Table Descriptor
（PHTD）と複数のHistory Descriptor（HD）が記録され
ている。PHTDと全てのHDを合わせてHistory Tableと呼
ぶ事とする。このHistory TableがUDFファイルシステム
の管理情報のバックアップ情報（履歴情報）となる。FIG. 3 shows a state in the backup area. The Volume management information in the figure corresponds to the area up to the backup information area in FIG. The backup area contains the Primary History Table Descriptor
(PHTD) and multiple History Descriptors (HD) are recorded. The PHTD and all HDs are collectively called the History Table. This History Table becomes backup information (history information) of the management information of the UDF file system.

【００３３】UDFファイルシステムにおいてファイルや
ディレクトリが新規に作成されたり、変更が発生した
り、削除された場合、そのファイルやディレクトリ毎に
1つのHistory DescriptorがHistory Tableに追加され
る。PHTDには、History Tableの大きさが管理されてお
り、常にHistory Tableの最後尾が分かるようになって
いるので、History Descriptorの追加は容易に行なう事
が可能である。UDFなどの汎用ファイルシステムと異な
り今までに記録されたHistory Descriptor（ファイルや
ディレクトリのバックアップ情報）をHistory Tableか
らは削除しない。つまり、UDFファイルシステムにおい
てファイルやディレクトリの作成、変更、削除などと言
ったイベントが発生する度に、単純にそれらのイベント
に対応するHistory DescriptorがHistory Tableの最後
尾に追加されるだけある。When a file or directory is newly created, changed, or deleted in the UDF file system, each file or directory is
One History Descriptor is added to the History Table. Since the size of the History Table is managed in the PHTD and the end of the History Table is always known, it is possible to easily add the History Descriptor. Unlike a general-purpose file system such as UDF, the History Descriptor (file or directory backup information) recorded so far is not deleted from the History Table. In other words, every time an event such as creation, modification, or deletion of a file or directory occurs in the UDF file system, the corresponding History Descriptor is simply added to the end of the History Table.

【００３４】仮に、UDFファイルシステムの管理情報が
読み出せないと言った状況になった場合、目的のファイ
ルやディレクトリを特定するためのファイル名をキーと
して、History Tableの最後尾から順番に、対応するHis
tory Descriptorが見つかるまで見ていく。探し出したH
istory Descriptorを参照する事によって、対応するフ
ァイルやディレクトリが記録されているディスク上の位
置情報を把握する事ができ、データにアクセスできない
と言った問題点を解決する。If the management information of the UDF file system cannot be read out, the file name for specifying the target file or directory is used as a key in order from the end of the history table. His
Keep looking until you find a tory Descriptor. H found
By referring to the istory Descriptor, the position information on the disk where the corresponding file or directory is recorded can be grasped, and the problem that data cannot be accessed is solved.

【００３５】目的のHistory Descriptorを探し出すの
に、History Tableをサーチしなければならないが、本
発明の目的であるバックアップ用途であり、この情報に
アクセスする場合は非常時である事を考慮すれば許容で
きるものである。その反面、UDFファイルシステムにお
けるファイルやディレクトリの作成、変更、削除と言っ
たイベントが発生した際のHistory Tableの更新は、His
tory Descriptorの追加のみと必要最低限の処理に抑え
られている事が特徴となる。The History Table must be searched to find the target History Descriptor. However, this is a backup purpose which is the object of the present invention, and access to this information is permissible considering that it is an emergency. You can do it. On the other hand, when an event such as creation, modification, or deletion of a file or directory in the UDF file system occurs, the History Table is updated
The feature is that only the addition of the tory Descriptor is kept to the minimum necessary processing.

【００３６】またHistory Tableには、History Tableを
作り始めてからのUDFファイルシステムにおけるファイ
ルやディレクトリの作成、変更、削除と言ったイベント
に対応するHistory Descriptorが記録されている事にな
るので、History Tableは単純なUDFファイルシステムの
管理情報のバックアップだけではなく、ファイルシステ
ムの管理情報の更新履歴としても使う事が可能である。Since the History Table records History Descriptors corresponding to events such as creation, change, and deletion of files and directories in the UDF file system since the creation of the History Table, the History Table is recorded. Can be used not only as a backup of simple UDF file system management information, but also as an update history of file system management information.

【００３７】History DescriptorはHistory Tableに追
加されて行くだけなので、使用過程においてHistory Ta
bleが巨大になってしまったり、バックアップ領域の空
きの残量が無くなってしまう事も考えられる。そこで、
History TableからUDFファイルシステムで定義されてい
るファイルやディレクトリに対応するHistory Descript
orだけ残してその他のHistory Descriptorを全て削除し
History Tableを再構築する事も可能である。Since the History Descriptor is only added to the History Table, the History
It is conceivable that ble becomes huge or the backup area runs out of space. Therefore,
History Descript corresponding to files and directories defined in UDF file system from History Table
Delete all other History Descriptors except or
It is also possible to rebuild the History Table.

【００３８】ここで、図4にPrimary History Table Des
criptorの内容を示す。Primary History Table Descrip
torは、History Tableを管理するための情報やバックア
ップ領域の情報を管理する記述子である。FIG. 4 shows the Primary History Table Des
Show the contents of criptor. Primary History Table Descrip
tor is a descriptor for managing information for managing the History Table and information for the backup area.

【００３９】Area Sizeはバックアップ領域の大きさを
論理セクタ数で表し、Uint32型として記録される。Last
History Descriptor Added Timestampは、History Des
criptorがHistory Tableに追加された最終時刻を記録す
る。この情報によって、最後にHistory Descriptorを追
加した時刻を把握する事ができ、例えばUDFファイルシ
ステムの管理情報との整合性を見る場合などに利用する
事ができる。Last History Table Updated Timestamp
は、History Tableを最後に再構築した時刻を記録す
る。この情報によりHistory Tableが保持する更新履歴
がいつからのものであるかを把握する事が可能となる。The Area Size indicates the size of the backup area by the number of logical sectors and is recorded as a Uint32 type. Last
History Descriptor Added Timestamp, History Des
Record the last time the criptor was added to the History Table. With this information, the time when the History Descriptor was last added can be grasped, and this can be used, for example, when checking the consistency with the management information of the UDF file system. Last History Table Updated Timestamp
Records the last time the History Table was rebuilt. With this information, it is possible to know when the update history stored in the History Table is from.

【００４０】Number of History Descriptorsは、Histo
ry Tableに記録されているHistoryDescriptorの数を示
し、Uint32型で記録される。History Table Sizeは、Hi
story Tableのサイズをbyte数で表しUint32型で記録さ
れる。Primary History TableDescriptorの先頭から最
後のHistory Descriptorの最後部までのByte数を表す。
ディスクへのHistory Descriptorの追加は論理セクタ単
位で行なうのが一般的なので、仮に1論理セクタのサイ
ズが2KBとすると、このHistory Table Sizeを2KBで割
り、その商がアクセスすべきバックアップ領域の先頭か
らみた論理セクタ数となる。また、余りが最後の論理セ
クタに既にデータが記録されている量である。つまり、
追加を行なう場合には目的の論理セクタを一度読み出し
て、既に記録されている情報の後にHistory Descriptor
を追加して、その論理セクタの内容をディスクに記録す
る事になる。The Number of History Descriptors is Histo
Indicates the number of HistoryDescriptors recorded in the ry Table, and is recorded in Uint32 type. History Table Size is Hi
The size of story table is expressed in bytes and recorded in Uint32. Represents the number of Bytes from the beginning of the Primary History TableDescriptor to the end of the last History Descriptor.
Since it is common to add the History Descriptor to the disk in units of logical sectors, if the size of one logical sector is 2 KB, divide this History Table Size by 2 KB and start from the top of the backup area that the quotient should access. This is the number of logical sectors seen. The remainder is the amount of data already recorded in the last logical sector. That is,
When adding, read the target logical sector once, and add the History Descriptor after the already recorded information.
And the contents of the logical sector are recorded on the disk.

【００４１】なお、図中の、RBPはRelative Byte Posit
ionを意味し、先頭から見た対応する管理項目の開始位
置を示す情報で、Lenはその管理項目の大きさをByteで
表し、Field Nameは管理項目名、Contentsは、管理項目
がどのような形式で記録されなければならないかという
ことを示す。Contentsで用いられているデータ型のう
ち、Uint8は符号無し8bit整数、Uint16は符号無し16bit
整数、Uint32は符号無し32bit整数を意味する。String
は文字列を格納するためのデータ型、Timestampは日時
情報を格納する型である。In the figure, RBP stands for Relative Byte Posit.
ion means information indicating the start position of the corresponding management item as viewed from the top, Len represents the size of the management item in Byte, Field Name is the name of the management item, Contents is what kind of management item is Indicates whether it must be recorded in a format. Of the data types used in Contents, Uint8 is an unsigned 8-bit integer, Uint16 is an unsigned 16-bit
An integer, Uint32, means an unsigned 32-bit integer. String
Is a data type for storing character strings, and Timestamp is a type for storing date and time information.

【００４２】図5にHistory Descriptorの内容を示す。H
istory Descriptorは、論理ファイルシステムにおける
ファイルやディレクトリの管理情報のバックアップ情報
であり、対応するファイルやディレクトリにアクセスす
るための必要最低限の情報で構成されている。FIG. 5 shows the contents of the History Descriptor. H
The istory Descriptor is backup information of file and directory management information in the logical file system, and is composed of minimum necessary information for accessing the corresponding file or directory.

【００４３】Length of File Identifierは、ファイル
やディレクトリを識別するための情報であるFile Ident
ifierの長さをbyte数で示し、Uint16型で記録される。F
ileIdentifierは、ファイルやディレクトリを識別する
ための情報であり、Length of File Identifier byteだ
けstring形式で記録される。ファイルやディレクトリを
識別するための情報とは通常はファイル名やディレクト
リ名である。ここで、File Identifierにはファイルや
ディレクトリのパス名を併記して記録するものとする。
例えば、Rootディレクトリ下のDATAディレクトリ下のFI
LE1.DATというファイルの場合は、\DATA\FILE1.DATと記
録する。また、前述のLength of FileIdentifierはこの
場合、15byteとなる。File Identifierはファイル名で
ある必要はなく、例えばファイルID番号などファイルや
ディレクトリが特定できるものであれば構わない。ただ
し、同一ディスクに色々な種類のFile Identifierが混
在できるという意味ではない。The Length of File Identifier is information for identifying a file or directory.
Indicates the length of the ifier in bytes and is recorded in Uint16 type. F
The ileIdentifier is information for identifying a file or a directory, and is recorded in a string format of Length of File Identifier byte. The information for identifying a file or a directory is usually a file name or a directory name. Here, it is assumed that the file identifier is recorded together with the path name of the file or directory.
For example, FI under DATA directory under Root directory
If the file is LE1.DAT, record it as \ DATA \ FILE1.DAT. In this case, the above-mentioned Length of FileIdentifier is 15 bytes. The File Identifier does not need to be a file name, and may be any file or directory that can specify a file ID number, for example. However, this does not mean that various types of File Identifiers can be mixed on the same disk.

【００４４】Length of Original File Identifierは、
ファイルやディレクトリの名前が変更になった場合に使
用されるフィールドであり、ファイル名やディレクトリ
名が変更になる前のファイルやディレクトリを識別する
ための情報であるOriginal File Identifierの長さをby
te数で示し、Uint16型で記録される。ファイル名やディ
レクトリ名の変更が無い場合は0を記録しなければなら
ない。Original File Identifierは、ファイルやディレ
クトリの名前が変更になった場合のみに使われるフィー
ルドであり、変更前のファイルやディレクトリを識別す
るための情報をLength of Original File Identifier b
yteだけstring型で記録される。なお、変更後の名前はF
ile Identifierフィールドに記録する。Timestampは、
このファイルやディレクトリが追加、変更、削除された
時刻を示し、Timestamp型で記録される。The Length of Original File Identifier is
This field is used when the name of a file or directory is changed, and specifies the length of the Original File Identifier, which is information for identifying the file or directory before the file or directory name is changed.
Indicated by te number, recorded in Uint16 type. If the file name or directory name has not been changed, 0 must be recorded. Original File Identifier is a field that is used only when a file or directory is renamed, and contains information for identifying the file or directory before the change. Length of Original File Identifier b
Only yte is recorded in string type. The name after the change is F
Record in the ile Identifier field. Timestamp is
Indicates the time when this file or directory was added, changed, or deleted, and is recorded in Timestamp type.

【００４５】Action Typeは、論理ファイルシステムに
おいてファイルやディレクトリが作成されたのか、内容
が変更されたのか、名前が変更されたのか、削除された
のかを示すものである。新たに作成された場合は01h
を、内容が変更された場合は02h、名前が変更された場
合は03h、削除された場合は04hを記録する。File Type
は、History Descriptorが管理するのがファイルかディ
レクトリかを示す。ファイルの場合は00h、ディレクト
リの場合は01hを記録する。File Sizeは、History Desc
riptorの管理するファイルやディレクトリのサイズをby
te数で管理する。The Action Type indicates whether a file or directory has been created, its contents have been changed, its name has been changed, or it has been deleted in the logical file system. 01h if newly created
Is recorded, 02h is recorded when the content is changed, 03h is recorded when the name is changed, and 04h is recorded when the name is deleted. File Type
Indicates whether the History Descriptor manages files or directories. 00h is recorded for a file, and 01h is recorded for a directory. File Size is History Desc
By the size of files and directories managed by riptor
Manage by te number.

【００４６】Number of Extentsは、History Descripto
rの管理するファイルやディレクトリに対応するディス
ク上のデータの分断数を示し、Uint16型で記録する。対
応するデータが連続的に記録されている場合は0001h、2
つに分断されて記録されている場合は0002hを記録す
る。Location of Extentは、対応するファイルやディレ
クトリの管理するデータのディスク上の位置情報を示
す。Location of Extentは、Start AddressとLengthで
構成され、それぞれ管理するExtentの開始アドレスと長
さを管理しUint32型で記録される。Location of Extent
はNumber of Extent個連続して記録される。この時アド
レスはバックアップ対象となるファイルシステム内で管
理しているアドレスと長さ情報を合わせる。例えば、バ
ックアップ対象とするファイルシステムが構築されてい
るパーティション内でアドレスが論理ブロック番号であ
ればそれに従い、長さ情報が論理ブロック数で扱われて
いるのであればそれに従う。Paddingは、History Descr
iptorの総バイト数が偶数になるように調整を行なう情
報であり、必要な場合は00hを記録する。Number of Extents is a history descriptor
Indicates the number of data partitions on the disk corresponding to the files and directories managed by r, and is recorded in Uint16 format. 0001h, 2 if the corresponding data is recorded continuously
If it is divided and recorded, 0002h is recorded. Location of Extent indicates the location information on the disk of the data managed by the corresponding file or directory. The Location of Extent is composed of Start Address and Length, and manages the start address and length of the managed Extent, and is recorded in Uint32 format. Location of Extent
Are continuously recorded as Number of Extent. At this time, the address matches the length information with the address managed in the file system to be backed up. For example, if the address is a logical block number in the partition where the file system to be backed up is constructed, the address is followed, and if the length information is handled by the number of logical blocks, it is followed. Padding, History Descr
This information adjusts the total number of bytes of the iptor to be an even number, and records 00h if necessary.

【００４７】以上のような管理情報を用いた実際の実施
例を説明して行く。図6に示すようなディレクトリ階層
のファイルやディレクトリがある場合、対応するUDFフ
ァイルシステムが定義するパーティション内の論理ファ
イルシステムの管理情報とデータ配置の様子の例を図7
に示す。An actual embodiment using the above management information will be described. When there are files and directories in the directory hierarchy as shown in FIG. 6, an example of the state of management information and data arrangement of the logical file system in the partition defined by the corresponding UDF file system is shown in FIG.
Shown in

【００４８】パーティション内の先頭から、パーティシ
ョン内の空き領域情報を管理するSpace Bitmap Descrip
tor (SBD)、ファイルシステムの基本管理情報であり、R
ootディレクトリを管理するFile Entry(FE Root)へのポ
インタ情報を持つFile SetDescriptor (FSD)、File Set
Descriptorが終った事を示すTerminating Descriptor
(TD)が記録されている。また、Rootディレクトリ、DATA
ディレクトリをそれぞれ管理するFile Entry (FE)と、
各ディレクトリの下に定義されるファイルのファイル名
や属性情報、そしてそのファイルあるいは下位のディレ
クトリを管理するFile Entry(FE)へのポインタ情報であ
るFile Identifier Descriptor (FID)、Rootディレクト
リの下に定義されているREADME.TXTを管理するFile Ent
ry (FE)とDATAディレクトリの下に定義される、FILE1.D
ATとFILE2.DATを管理するFileEntry (FE)が記録されて
いる。ファイルおよびディレクトリのFile Entryはそれ
ぞれ対応するデータが記録されているディスク上の分断
情報をExtentとして管理している。例えば、図７の例に
おいては、FILE1.DATに対応するデータはディスクでは
分断して記録されており、Extent4および5によって構成
されている。またFILE2.DATに対応するディスク上のデ
ータは連続的に記録されており、Extent6によって構成
されている。Space Bitmap Descrip which manages free space information in a partition from the top of the partition
tor (SBD), basic management information of the file system, R
File Set Descriptor (FSD), File Set with pointer information to File Entry (FE Root) that manages oot directory
Terminating Descriptor indicating that Descriptor is over
(TD) is recorded. Also, Root directory, DATA
File Entry (FE) that manages each directory,
File Identifier Descriptor (FID), which is the file name and attribute information of the file defined under each directory, and pointer information to the File Entry (FE) that manages the file or lower directory, defined under the Root directory Fileent which manages README.TXT
FILE1.D defined under ry (FE) and DATA directory
FileEntry (FE) that manages AT and FILE2.DAT is recorded. The File Entry of the file and the directory manage the division information on the disk in which the corresponding data is recorded as Extent. For example, in the example of FIG. 7, the data corresponding to FILE1.DAT is recorded separately on the disk, and is constituted by Extents 4 and 5. Data on the disk corresponding to FILE2.DAT is continuously recorded, and is constituted by Extent6.

【００４９】このような状況のディレクトリ階層に対応
するHistory Tableの例を図8に示す。この図では、一番
下にPrimary History Table Descriptorが配置されてお
り、History Tableの最後尾は図の一番上に相当する。
この例では、Rootディレクトリ(\)、\README.TXT、\DAT
Aディレクトリ、\DATA\FILE1.DAT、\DATA\FILE2.DATの
順番で作成された様子を示している。一番下の枠を除い
て１つの枠が1つのHistory Descriptorに対応し、全て
の枠をまとめてHistory Tableを構成する。FIG. 8 shows an example of the History Table corresponding to the directory hierarchy in such a situation. In this figure, the Primary History Table Descriptor is arranged at the bottom, and the tail of the History Table corresponds to the top of the figure.
In this example, the root directory (\), \ README.TXT, \ DAT
A directory, \ DATA \ FILE1.DAT, and \ DATA \ FILE2.DAT are created in this order. Except for the bottom frame, one frame corresponds to one History Descriptor, and all the frames constitute a History Table.

【００５０】図9に図８で示す状態から、DATAディレク
トリの下にFILE3.DATというファイルが作成（追加）さ
れた場合の様子を示す。FILE3.DATがUDFファイルシステ
ムで作成されると、それに対応するHistory Descriptor
がHistory Tableの最後尾に追加される。この際、Histo
ry TableのFile Identifierには\DATA\FILE3.DATが記録
され、Timestampにはファイルの作成された日時、Actio
n Typeには作成を示す01h、File Typeにはファイルを示
す00h、File SizeにはFILE3.DATのファイルサイズを、N
umber of Extentsには、FILE3.DATに対応するデータの
ディスク上での分断数を、そしてLocation of Extentに
はそれぞれの分断に関する位置情報を記録する事にな
る。ここでは、FILE3.DATはExtent7のみによって構成さ
れている（連続して記録されている）ことになる。FIG. 9 shows a state where a file FILE3.DAT is created (added) under the DATA directory from the state shown in FIG. When FILE3.DAT is created in UDF file system, the corresponding History Descriptor
Is added to the end of the History Table. At this time, Histo
\ DATA \ FILE3.DAT is recorded in the File Identifier of the ry Table, and the date and time when the file was created, Actio is recorded in the Timestamp
n Type indicates 01h indicating creation, File Type indicates 00h indicating file, File Size indicates the file size of FILE3.DAT, N
In the umber of Extents, the number of divisions of the data corresponding to FILE3.DAT on the disk is recorded, and in the Location of Extent, position information on each division is recorded. Here, FILE3.DAT is constituted only by Extent7 (recorded continuously).

【００５１】図10に、図９で示された状態から、さらに
DATAディレクトリの下のFILE2.DATの内容が変更された
場合の様子を示す。UDFファイルシステムにおいてFILE
2.DATのディスク上の位置が変更になったり、内容が変
更になった場合、History Tableの最後尾に、対応するH
istory Descriptorを追加する。この際、Action Typeに
は内容変更を示す02hを記録する。また、FILE2.DATのデ
ィスク上の位置が変更となり、Location of ExtentがEx
tent8に変更になる。このFILE2.DATの内容変更に関する
History Descriptorが追加になった時点で、History Ta
ble内に既に存在している、FILE2.DATを作成した際のHi
story Descriptorが古い情報となり、更新履歴情報とな
る。FIG. 10 further shows the state shown in FIG.
The following shows how the contents of FILE2.DAT under the DATA directory are changed. FILE in UDF file system
2. If the location of the DAT on the disk has changed or its contents have changed, the corresponding H
Add istory Descriptor. At this time, 02h indicating the content change is recorded in the Action Type. Also, the location of FILE2.DAT on the disk has changed, and the Location of Extent
It will be changed to tent8. Regarding change of contents of this FILE2.DAT
When the History Descriptor is added, the History Ta
Hi when creating FILE2.DAT that already exists in ble
The story Descriptor becomes old information and becomes update history information.

【００５２】図11に、図１０で示された状態から、さら
にDATAディレクトリの下のFILE1.DATを削除した場合の
様子を示す。UDFファイルシステムにおいてFILE1.DATが
削除された場合、History Tableの最後尾に対応するHis
tory Descriptorを追加する。この際、Action Typeには
削除を示す04hを記録し、Location of Extent情報に
は、削除する直前のデータの位置情報を記録する。この
FILE1.DATの削除に関するHistory Descriptorが追加に
なった時点で、History Table内に既に存在しているFIL
E1.DATを作成した際のHistory Descriptorが古い情報と
なり、更新履歴情報となる。FIG. 11 shows a state in which FILE1.DAT under the DATA directory is further deleted from the state shown in FIG. If FILE1.DAT is deleted in the UDF file system, the His corresponding to the end of the History Table
Add tory Descriptor. At this time, 04h indicating the deletion is recorded in the Action Type, and the location information of the data immediately before the deletion is recorded in the Location of Extent information. this
When the History Descriptor for deleting FILE1.DAT is added, the FIL that already exists in the History Table
History Descriptor when E1.DAT was created becomes old information and becomes update history information.

【００５３】ここで、History Tableを再構築するする
場合の様子を図12に示す。History Tableには、UDFファ
イルシステムにおいてファイルやディレクトリに関して
作成、変更、削除と言ったイベントが発生する度にHist
ory Descriptorが一方的に追加になっていく。History
Descriptorを記録する領域は決まっているので、状況に
応じてHistory Tableから不要な情報を削除しHistory T
ableを再構築する事も必要となる。この場合は、Histor
y Tableの最後部のHistory Descriptorから順番に見て
行き、同一のファイルやディレクトリに関する情報つま
り更新履歴に相当するHistory DescriptorをHistory Ta
bleから削除する。また、Action Typeが削除のHistory
Descriptorに関しても同様に削除する。図の例では、左
側のHistory Tableから更新履歴に相当する「\DATA\FIL
E2.DAT作成」と「\DATA\FILE1.DAT作成」と、「\DATA\F
ILE1.DAT削除」のHistory Descriptorを削除し、Histor
yTableのように最構築する。この際、残ったHistory De
scriptorのAction Typeは全て作成に変更する事にな
る。FIG. 12 shows how the History Table is reconstructed. Each time an event such as creation, change, or deletion of a file or directory occurs in the UDF file system, the History Table
ory Descriptor is added unilaterally. History
Since the area for recording the Descriptor is fixed, unnecessary information is deleted from the History Table according to the situation, and the History T
You need to rebuild able. In this case, Histor
y Look at the History Descriptor at the end of the table in order, and find information about the same file or directory, that is, the History Descriptor corresponding to the update history
Delete from ble. Also, the History of Action Type is deleted
Descriptor is deleted in the same way. In the example of the figure, "\ DATA \ FIL" corresponding to the update history from the History Table on the left
E2.DAT creation "and" \ DATA \ FILE1.DAT creation "and" \ DATA \ F
Delete the History Descriptor of "ILE1.DAT deletion"
Rebuild like yTable. At this time, the remaining History De
All the action types of scriptor will be changed to creation.

【００５４】ここで、処理の詳細をフローチャートで説
明する。図13にUDFファイルシステムにおいてファイル
やディレクトリの作成、変更、削除と言ったイベントが
発生した場合の処理の流れを示す。Here, the details of the processing will be described with reference to flowcharts. FIG. 13 shows the flow of processing when an event such as creation, change, or deletion of a file or directory occurs in the UDF file system.

【００５５】ステップS1において、ファイル・ディレク
トリの作成、変更、削除イベントが発生すると、ステッ
プS2においてPrimary History Table Descriptorを読み
出し、History Tableの最後部を把握する。具体的に
は、History Table中のHistoryTable SizeからHistory
Tableの最後尾の位置を把握する事が可能となる。ステ
ップS3において、ファイルあるいはディレクトリに対応
すHistory DescriptorをHistory Tableの最後に追加す
る。この際History Descriptorには、図５に示すよう
に、ファイルやディレクトリの名前をFile Identifier
に、発生したイベントの種類をAction Type、ファイル
かディレクトリなのかをFile Type、イベントが発生し
た日時、イベントが発生した対象のファイルあるいはデ
ィレクトリの管理するディスク上の領域を管理する形
で、Location of Extentが記録される。ステップS4にお
いて、Primary History Table Descriptor内の最後尾に
History Descriptorを追加した時刻を示すLast History
Descriptor Added Timestampと、History Descriptor
数、History Table Sizeを更新して処理を終了する。UD
Fにおけるファイルやディレクトリに関するイベントが
発生した際の処理は以上のように、単純なHistory Desc
riptorの追加処理となる。When a file / directory creation, change, or deletion event occurs in step S1, the Primary History Table Descriptor is read in step S2, and the last part of the History Table is grasped. Specifically, the History Table Size in the History Table
It is possible to know the position of the tail of the Table. In step S3, a History Descriptor corresponding to the file or directory is added to the end of the History Table. At this time, as shown in FIG. 5, the name of the file or directory is set in the History Descriptor.
In the form of managing the type of event that occurred, the Action Type, whether the event was a file or a directory, the File Type, the date and time when the event occurred, and the area on the disk managed by the file or directory where the event occurred, Extent is recorded. In step S4, at the end of the Primary History Table Descriptor
Last History indicating the time when the History Descriptor was added
Descriptor Added Timestamp and History Descriptor
The number and the History Table Size are updated and the process ends. UD
The processing when an event related to a file or directory occurs in F is simple History Desc
It is an additional process of riptor.

【００５６】上記したようにファイルがあるディレクト
リに追加された場合、実際のディスク上では、ディレク
トリのFile Entryが示す分断に、File Identifier Desc
riptorを追加することになる。ここで、File Identifie
r Descriptorが記録される領域は、例えば2KB単位（１
論理ブロック）で領域サイズが定義されているので、Fi
le Identifier Descriptorが追加されることで、１論理
ブロック単位を越えて、File Identifier Descriptorが
記録される領域全体のサイズが変更した場合は、ディレ
クトリの変更があったこととなり、ディレクトリに対し
て変更イベントを行うことになる。When a file is added to a certain directory as described above, on the actual disk, the file identifier indicated by the File Entry of the directory is divided into two parts.
You will add a riptor. Where File Identifie
The area where the r Descriptor is recorded is, for example, 2 KB units (1
Logical block) defines the area size, so
If the size of the entire area where the File Identifier Descriptor is recorded changes beyond one logical block due to the addition of the le Identifier Descriptor, it means that the directory has changed, and the change event for the directory Will be done.

【００５７】このフローチャートでは、UDFのファイル
システムにおいてファイルやディレクトリの作成、変
更、削除と言ったイベントが発生する度に対応するHist
ory DescriptorをHistory Tableに追加する説明になっ
ているが、例えば電源投入時やディスクを装着した時に
Primary History Table Descriptorを読み出し、電源を
切断する時やディスクを排出する時などにその期間中に
発生した全てのイベントに対応するHistory Descriptor
をまとめてHistory Tableに追加しPrimary History Tab
le Descriptorを更新し記録しても良い。つまりHistory
Descriptorをメモリ上に保持しておき、あるタイミン
グで一度にディスク上のHistory Tableを更新しても構
わないものとする。In this flowchart, each time an event such as creation, change, or deletion of a file or directory occurs in the UDF file system,
Ory Descriptor is added to the History Table, but for example, when turning on the power or loading a disk
History Descriptor that reads the Primary History Table Descriptor and responds to all events that occurred during that period, such as when turning off the power or ejecting the disc
Primary History Tab
The le Descriptor may be updated and recorded. In other words, History
The Descriptor is stored in the memory, and the History Table on the disk may be updated at a certain timing at a time.

【００５８】このように、ファイルやディレクトリに関
するイベントが発生する度にHistory Tableを更新する
訳であるが、UDFファイルシステムにおいてあるファイ
ルやディレクトリにアクセスしようとしたが、それらを
管理する論理ファイルシステムの管理情報にアクセスで
きない非常時に、バックアップ情報であるHistory Tabl
eにアクセスする手段に関して図14のフローチャートを
用いて説明する。As described above, the History Table is updated every time an event related to a file or directory occurs. However, an attempt is made to access a file or directory in the UDF file system. History Tabl, which is backup information in case of emergency access to management information
The means for accessing e will be described with reference to the flowchart in FIG.

【００５９】ステップS10において、バックアップ情報
であるHistory Tableへのアクセス要求が発生すると、
ステップS11において、Primary History Table Descrip
torを読み出し、History Tableの大きさと、History Ta
ble中のHistory Descriptorの数を把握してHistory Tab
leをディスクから読み出す。具体的には、History Tabl
e中のNumber of History DescriptorsによってHistory
Table中のHistory Descriptorの数を、History Table S
izeからHistory Tableの最後尾の位置を把握する事が可
能となり、読み出されたHistory Tableは制御部のメモ
リ上でHistory Descriptor毎に展開される。ステップS1
2において、History Table中の最後のHistory Descript
orに注目をする。In step S10, when an access request to the History Table, which is backup information, occurs,
In step S11, the Primary History Table Descrip
Read tor, the size of History Table and History Ta
Know the number of History Descriptors in ble and make History Tab
Read le from disk. Specifically, History Tabl
History by Number of History Descriptors in e
Enter the number of History Descriptors in the History Table S
The position of the tail of the history table can be grasped from ize, and the read history table is expanded for each history descriptor on the memory of the control unit. Step S1
In 2, the last History Descript in the History Table
Pay attention to or.

【００６０】ステップS13において、今アクセスしたい
ファイルあるいはディレクトリの名前と注目しているHi
story DescriptorのFile Identifierが一致するかどう
かを判定する。一致しない場合はステップS14において
全てのHistory Descriptorをサーチしたかどうかを判定
する。全てのHistory Descriptorをサーチした場合は、
探そうとしているバックアップ情報が見つからないとい
う事になり、ステップS17においてエラー処理を行ない
処理を終了する。ステップS14においてまだ全てのHisto
ry Descriptorをサーチし終っていない場合は、ステッ
プS15において注目しているHistory DescriptorをHisto
ry Table中の1つ前のHistory Descriptorに変更し、ス
テップS13に戻り処理を繰り返す。In step S13, the name of the file or directory to be accessed now and the Hi
Determines whether the File Identifier of the story Descriptor matches. If they do not match, it is determined in step S14 whether all History Descriptors have been searched. If you search all History Descriptors,
This means that the backup information to be searched for cannot be found, so that error processing is performed in step S17, and the processing ends. In step S14, all Histo still
If the search for ry Descriptor has not been completed, the History Descriptor of interest in step S15 is
Change to the previous History Descriptor in the ry Table, return to step S13, and repeat the process.

【００６１】ステップS13において名前が一致すると判
定された場合は、ステップS16において注目しているHis
tory Descriptorのイベント種別を示すAction Typeが削
除であるかどうかを判定する。イベント種別が削除の場
合、探そうとしているファイルあるいはディレクトリの
バックアップ情報が削除状態を示すものであるためステ
ップS17においてエラー処理して処理を終了する。ただ
し、ここで、ファイルやディレクトリの削除した時点で
の情報が取得したいのであれば、エラー処理を行なわず
抽出したHistory Descriptorを利用しても構わない。ス
テップS16においてイベント種別が削除以外であれば、
注目しているHistory Descriptorが探し出すべきバック
アップ情報であり、サーチ処理を終了する。探し出した
HistoryDescriptor中のLocation of Extent情報を用い
てファイルやディレクトリのデータにアクセスが可能と
なるわけである。If it is determined in step S13 that the names match, in step S16 the His
It is determined whether the Action Type indicating the event type of the tory Descriptor is deletion. If the event type is “delete”, the backup information of the file or directory to be searched for indicates the deleted state, and an error process is performed in step S17, and the process ends. However, if it is desired to obtain information at the time of deleting a file or a directory, a history descriptor extracted without performing error processing may be used. If the event type is other than delete in step S16,
The History Descriptor of interest is the backup information to be found, and the search process ends. Sought out
Using the Location of Extent information in the HistoryDescriptor, it is possible to access data of files and directories.

【００６２】このように、ある特定のファイルやディレ
クトリのUDFファイルシステム管理情報にアクセスでき
ない場合に、History Tableから対応する最新のHistory
Descriptorを抽出し、その情報から対応するデータの
記録位置を把握しデータにアクセスする事を可能とし
た。また、この情報を利用して主の管理情報であるUDF
の管理情報を再構築する事も可能である。例えば、ある
ファイルを管理するUDFのFile Entryが読み出せなくな
った場合は、対応するバックアップ情報に相当するHist
ory Descriptorの情報を元にFile EntryをUDFのパーテ
ィション内に記録し直す。File Entryの情報としては、
作成時刻はFile Entryを作成し直した時刻、属性情報は
標準的な情報にセットされ、問題の発生する前の状態と
は必ずしも同じでは無いが、データにアクセスするため
の必要最低限の情報であるデータの記録位置情報に関し
ては完全に復活できるわけである。この処理の際、ファ
イルの管理情報であるFile Entryの記録位置を管理して
いるUDF管理情報のFile Identifier Descriptor内のポ
インタ情報を新しく作成し直したFile Entryの記録位置
を管理するように更新を行う。As described above, when it is not possible to access the UDF file system management information of a specific file or directory, the latest History corresponding to the history table is obtained from the History Table.
The Descriptor is extracted, and the recording position of the corresponding data is grasped from the information and the data can be accessed. UDF that is the main management information is used by using this information.
It is also possible to reconstruct the management information of. For example, if the File Entry of the UDF that manages a file cannot be read, the Hist corresponding to the corresponding backup information
File Entry is re-recorded in the UDF partition based on the information of the ory Descriptor. File Entry information includes
The creation time is the time when the File Entry was recreated, the attribute information is set to standard information, and it is not necessarily the same as the state before the problem occurred, but it is the minimum necessary information for accessing data The recording position information of certain data can be completely restored. During this process, update the pointer information in the File Identifier Descriptor of the UDF management information that manages the recording position of the File Entry, which is the file management information, to manage the recording position of the newly created File Entry. Do.

【００６３】続いて、History Tableの再構築の要求が
発生した際の処理の流れを図15に示したフローチャート
に基づいて説明する。Next, the flow of processing when a request for restructuring the History Table has occurred will be described with reference to the flowchart shown in FIG.

【００６４】ステップS20において、History Tableの再
構築の要求が発生した場合、ステップS21において、Pri
mary History Table Descriptorを読み出し、History T
ableの大きさと、History Table中のHistory Descripto
rの数を把握してHistory Tableをディスクから読み出
す。具体的には、History Table中のNumber of History
DescriptorsによってHistory Table中のHistory Descri
ptorの数を、History Table SizeからHistory Tableの
最後尾の位置を把握する事が可能となり、読み出された
History Tableは制御部のメモリ上でHistory Descripto
r毎に展開される。In step S20, if a request to rebuild the History Table is issued, in step S21 Pri
Reads mary History Table Descriptor, History T
The size of able and the history descriptor in the history table
Determine the number of r and read the History Table from the disk. Specifically, the Number of History in the History Table
History Descri in History Table by Descriptors
The number of ptors can be ascertained from the History Table Size and the position of the tail of the History Table is read.
History Table is a history descriptor on the control unit memory.
Expanded every r.

【００６５】ステップS22において、History Table中の
最後のHistory Descriptorに注目をする。ステップS23
において、History Table中の全てのHistory Descripto
rを見たかどうかを判定し、全てのHistory Descriptor
について処理が終っていれば処理を終了する。まだ処理
が終っていない場合は、ステップS24において、注目し
ているHistory Descriptorのイベント種別を表すAction
Typeが削除かどうかを判定する。イベント種別が削除
の場合は、ステップS28において注目しているHistory D
escriptorを削除リストに追加する。具体的には注目し
ているHistory DescriptorのFile Identifierを削除リ
ストに登録する事を行う。ステップS29において注目し
ているHistory DescriptorをHistory Table中の1つ前の
History Descriptorに変更し、ステップS23に戻り処理
を繰り返す。In step S22, attention is paid to the last History Descriptor in the History Table. Step S23
In, all History Descripto in History Table
Determine if you have seen r and all History Descriptors
If the processing has been completed for, the processing ends. If the processing has not been completed yet, in step S24, an Action representing the event type of the focused History Descriptor
It is determined whether Type is deleted. If the event type is “Delete”, the History D
Add escriptor to the delete list. Specifically, register the File Identifier of the History Descriptor of interest in the deletion list. The History Descriptor that is of interest in step S29 is the previous one in the History Table.
Change to History Descriptor, return to step S23, and repeat the process.

【００６６】ステップS24においてイベント種別が削除
でない場合、ステップS25において注目しているHistory
Descriptorが削除リストに含まれているかを判定す
る。具体的には、注目しているHistory DescriptorのFi
le Identifierと削除リストに含まれる名前を比較する
事によって行う。ステップS26において削除リストに含
まれていたかを判定し、含まれていた場合は、そのまま
ステップS29において注目しているHistory Descriptor
をHistory Table中の1つ前のHistory Descriptorに変更
し、ステップS23に戻り処理を繰り返す。If the event type is not deleted in step S24, the history of interest in step S25
Determine whether Descriptor is included in the deletion list. Specifically, the History Descriptor's Fi
This is done by comparing the le Identifier with the names in the deletion list. In step S26, it is determined whether or not it is included in the deletion list.
Is changed to the immediately preceding History Descriptor in the History Table, and the process returns to step S23 to repeat the processing.

【００６７】ステップS26において削除リストに含まれ
ていないと判定された場合、ステップS27において抽出
結果リストに追加する。具体的には注目しているHistor
y Descriptorをそのまま抽出結果リストにコピーする事
を行う。ステップS28において、注目しているHistory D
escriptorを削除リストに追加し、ステップS29において
注目しているHistory DescriptorをHistory Table中の1
つ前のHistory Descriptorに変更し、ステップS23に戻
り処理を繰り返す。If it is determined in step S26 that the item is not included in the deletion list, it is added to the extraction result list in step S27. Specifically, Histor who is paying attention
y Descriptor is copied to the extraction result list as it is. In step S28, the History D of interest
escriptor is added to the deletion list, and the History Descriptor of interest in step S29 is set to 1 in the History Table.
Change to the previous History Descriptor, return to step S23, and repeat the process.

【００６８】このような処理を行なう事によって、Hist
ory Table中の同じファイルやディレクトリを示す重複
するHistory Descriptorを削除し、更新履歴として存在
した不要な情報を削除する事が可能となる。具体的に
は、処理が終わった段階で抽出結果リストに残っている
History Descriptorが目的の情報となる。By performing such processing, the Hist
It is possible to delete the duplicate History Descriptor indicating the same file or directory in the ory Table, and delete unnecessary information existing as the update history. Specifically, it remains in the extraction result list at the stage when processing is completed
History Descriptor is the target information.

【００６９】続いて、History Tableからあるファイル
やディレクトリに関する更新履歴を取得したい要求が発
生した際の処理の流れを図16に示したフローチャートに
基づいて説明する。Next, the flow of processing when a request to acquire an update history related to a certain file or directory from the History Table occurs will be described with reference to the flowchart shown in FIG.

【００７０】ステップS40において、History Tableから
あるファイルやディレクトリに関する更新履歴を取得し
たい要求が発生した場合、ステップS41において、Prima
ry History Table Descriptorを読み出し、History Tab
leの大きさと、History Table中のHistory Descriptor
の数を把握してHistory Tableをディスクから読み出
す。具体的には、History Table中のNumber of History
DescriptorsによってHistory Table中のHistory Descr
iptorの数を、History Table SizeからHistory Tableの
最後尾の位置を把握する事が可能となり、読み出された
History Tableは制御部のメモリ上でHistory Descripto
r毎に展開される。In step S40, when a request to acquire an update history related to a certain file or directory from the History Table occurs, in step S41, Prima
Read the ry History Table Descriptor, and press the History Tab
The size of le and the history descriptor in the history table
And read the History Table from the disk. Specifically, the Number of History in the History Table
History Descr in History Table by Descriptors
The number of iptors can be ascertained at the end of the history table from the history table size and read
History Table is a history descriptor on the control unit memory.
Expanded every r.

【００７１】ステップS42において、History Table中の
最後のHistory Descriptorに注目をする。ステップS43
において、検索対象を示す変数であるSEARCHKEYに目的
のFileIdentifierをセットする。ステップS44におい
て、History Table中の全てのHistory Descriptorを調
べたかどうかを判定し、全てのHistory Descriptorにつ
いて処理が終っていれば処理を終了する。まだ処理が終
っていない場合は、ステップS45において、注目してい
るHistory DescriptorのFile Identifierが対象として
いるファイルあるいはディレクトリと一致するかどうか
を判定する。具体的にはSEARCHKEYと注目しているHisto
ry DescriptorのFile Identifierを比較する事によって
行う。一致しない場合はステップS49において注目するH
istory DescriptorをHistory Table中の1つ前のHistory
Descriptorに変更し、ステップS44に戻り処理を繰り返
す。At step S42, attention is paid to the last History Descriptor in the History Table. Step S43
In, set the target FileIdentifier to SEARCHKEY, which is a variable indicating the search target. In step S44, it is determined whether all the History Descriptors in the History Table have been checked, and if the processing has been completed for all the History Descriptors, the process ends. If the processing has not been completed, it is determined in step S45 whether the File Identifier of the focused History Descriptor matches the target file or directory. To be specific, Histo is paying attention to SEARCHKEY
This is done by comparing the File Identifier of the ry Descriptor. If they do not match, H of interest in step S49
The istory Descriptor is set to the previous History in the History Table.
Change to Descriptor, return to step S44, and repeat the process.

【００７２】ステップS45において、注目しているHisto
ry DescriptorのFile Identifierが対象としているファ
イルあるいはディレクトリと一致する場合、ステップS4
6において現在注目しているHistory Descriptorは、更
新履歴を取得しようとしている対象のファイルあるいは
ディレクトリに関する更新履歴であるものとし抽出結果
としてリストアップする事になる。ステップS47におい
て注目しているHistoryDescriptorのイベント種別を表
すAction Typeが名前変更かどうかを判定する。Action
Typeが名前変更の場合、ステップS48において、今後出
現する変更前と同じFile Identifierを持つHistory Des
criptorが抽出対象であるものとして扱うものとする。
具体的には、検索対象である事を示す変数であるSEARCH
KEYに注目しているHistory DescriptorのOriginal File
Identifierをセットする事になる。ステップS49におい
て注目するHistory DescriptorをHistory Table中の1つ
前のHistory Descriptorに変更し、ステップS44に戻り
処理を繰り返す。At step S45, the Histo
If the File Identifier of the ry Descriptor matches the target file or directory, step S4
The History Descriptor that is currently focused on in 6 is the update history of the file or directory for which the update history is to be obtained, and is listed as an extraction result. In step S47, it is determined whether the Action Type representing the event type of the HistoryDescriptor of interest is a name change. Action
If the Type is renamed, in Step S48, a History Des that has the same File Identifier as before the change that appears in the future
It is assumed that criptor is treated as an extraction target.
Specifically, SEARCH is a variable that indicates the search target.
History Descriptor Original File focusing on KEY
Identifier will be set. In step S49, the History Descriptor of interest is changed to the immediately preceding History Descriptor in the History Table, and the process returns to step S44 to repeat the processing.

【００７３】ステップS47において、Action Typeが名前
変更以外であれば、ステップS49において注目するHisto
ry DescriptorをHistory Table中の1つ前のHistory Des
criptorに変更し、ステップS44に戻り処理を繰り返す。If it is determined in step S47 that the Action Type is other than the name change, the Histo
ry Descriptor to the previous History Des in the History Table
Change to criptor, return to step S44, and repeat the process.

【００７４】このような処理によって、History Table
から更新履歴を取得したいファイルあるいはディレクト
リに関する全てのHistory Descriptorを簡単に抽出する
事が可能となる。具体的には、処理が終わった段階の抽
出結果リストに残っているHistory Descriptorが目的の
情報となる。By such processing, the History Table
You can easily extract all History Descriptors for files or directories for which you want to obtain update history from. Specifically, the History Descriptor remaining in the extraction result list at the stage when the processing is completed is the target information.

【００７５】説明してきたHistory Tableでは、アクセ
スしようとするファイルやディレクトリがあらかじめ分
かっている場合には、History Tableに含まれる対応す
るHistory Descriptorを探し出すだけの処理で終わる。
仮に管理情報のバックアップの対象となるファイルシス
テムの管理情報が全くディスクから読み出せなくなり、
どのようなファイルが記録されているか、あるいはどの
ようなディレクトリ構造の状態であるかが不明になる事
も考えられる。このような状況が発生した場合には、Hi
story Tableを再構築し残されたHistory Descriptorを
参照する事によって、バックアップ情報が保持するディ
レクトリ階層の構造を把握する事が可能となり、バック
アップ情報を介してファイルやディレクトリにアクセス
したり、管理情報の復旧をするための情報をして利用で
きる事になる。In the history table described above, if the file or directory to be accessed is known in advance, the process ends only by searching for the corresponding history descriptor included in the history table.
If the management information of the file system for which the management information is backed up cannot be read from the disk at all,
It is also conceivable that it is unclear what file is being recorded or what the state of the directory structure is. If this situation occurs, Hi
By reconstructing the story table and referring to the remaining History Descriptor, it is possible to understand the structure of the directory hierarchy held by the backup information, access files and directories via the backup information, and You will be able to use the information for recovery.

【００７６】また、上述した実施の形態ではファイルや
ディレクトリに関するイベントが発生した場合にHistor
y DescriptorをHistory Tableに追加する処理を説明し
てきた。別の実施形態としてディレクトリに関するイベ
ントを除外し、ファイルに関するイベントが発生した場
合のみHistory DescriptorをHistory Tableに追加する
ようにしても良い。この場合ディレクトリ内に定義され
ているファイルやディレクトリを管理するファイルシス
テムの管理情報にはアクセスできなくなるが、ユーザに
とっては重要な情報ではないので問題にはならない。ま
たユーザがアクセスしたいファイルに対応するバックア
ップ情報であるHistory Descriptorは記録されているの
で、ファイルへのアクセスは問題なく行える。In the above-described embodiment, when an event related to a file or directory occurs,
The process of adding the y Descriptor to the History Table has been described. As another embodiment, an event related to a directory may be excluded, and a history descriptor may be added to the history table only when an event related to a file occurs. In this case, the file defined in the directory and the management information of the file system that manages the directory cannot be accessed, but this is not a problem because it is not important information for the user. Also, since the History Descriptor, which is backup information corresponding to the file that the user wants to access, is recorded, the file can be accessed without any problem.

【００７７】本発明では、History Tableをディスク上
に確保された専用のバックアップ領域に記録したが、こ
の情報を専用領域に記録せずにバックアップの対象とな
るファイルシステム内で普通のファイルとして記録する
事も考えられる。このような構成を取る事によって、バ
ックアップ用の専用領域を用意する必要が無く、ファイ
ルとして記録されるのでバックアップ情報であるHistor
y Tableをディスク上の任意の箇所に記録する事が可能
となる。また、History Tableの内容を不揮発性の半導
体メモリに格納する事も考えられる。このように、デー
タ自体が記録されている記録媒体と異なる媒体にHistor
y Tableを記録する場合は、History Tableと対応するフ
ァイルシステムが記録されているメディアを識別するた
めの情報と共に記録する事によって、ディスクメディア
とHistory Tableの対応を取る事が可能となる。In the present invention, the History Table is recorded in the dedicated backup area secured on the disk. However, this information is recorded as a normal file in the file system to be backed up without being recorded in the dedicated area. Things are also possible. By adopting such a configuration, there is no need to prepare a dedicated area for backup, and it is recorded as a file.
It is possible to record the y Table at any location on the disk. It is also conceivable to store the contents of the History Table in a nonvolatile semiconductor memory. In this way, the Histor is stored on a medium different from the recording medium on which the data itself is recorded.
When the y Table is recorded, it is possible to establish a correspondence between the disc medium and the History Table by recording the y Table together with information for identifying the medium on which the file system corresponding to the History Table is recorded.

【００７８】[0078]

【発明の効果】本発明によれば、論理ファイルシステム
の管理情報を多重する機能が無いようなファイルシステ
ムであっても、ファイルやディレクトリに関する作成、
変更、削除と言ったイベントが発生する度に、対応する
ファイルやディレクトリにアクセスするために必要最低
限の情報で構成されるHistory DescriptorをHistory Ta
bleに単純な処理である追加処理を行なう。この事によ
って、論理ファイルシステムの管理情報が読み出せなく
なった場合にこのバックアップ情報であるHistory Tabl
eにアクセスする事によって対応するファイルやディレ
クトリにアクセスする事が可能となる。According to the present invention, even if the file system does not have a function of multiplexing the management information of the logical file system, creation of files and directories can be performed.
Each time an event such as change or deletion occurs, the History Descriptor consisting of the minimum information necessary to access the corresponding file or directory
Perform an additional process that is a simple process on ble. As a result, when the management information of the logical file system cannot be read, the backup information, History Tabl
By accessing e, the corresponding file or directory can be accessed.

【００７９】また、バックアップ情報であるHistory Ta
bleは、ファイルやディレクトリに関する作成、変更、
削除と言ったイベントが発生する度に追加されるものな
ので、ファイルやディレクトリの更新履歴情報としても
用いる事が可能となる。Further, History Ta, which is backup information,
ble creates, modifies,
Since it is added every time an event such as deletion occurs, it can be used as update history information of files and directories.

【図面の簡単な説明】[Brief description of the drawings]

【図１】本発明のディスク管理方法の実施形態における
ブロック図示す説明図である。FIG. 1 is an explanatory diagram showing a block diagram in a disk management method according to an embodiment of the present invention.

【図２】本発明のディスク管理方法の実施形態において
UDFのパーティションとバックアップ領域の関係を示す
説明図である。FIG. 2 shows an embodiment of a disk management method according to the present invention.
FIG. 4 is an explanatory diagram showing a relationship between a UDF partition and a backup area.

【図３】本発明のディスク管理方法の実施形態において
バックアップ領域の無いようを示す説明図である。FIG. 3 is an explanatory diagram showing that there is no backup area in the embodiment of the disk management method of the present invention.

【図４】本発明のディスク管理方法の実施形態における
Primary History Table Descriptorを示す説明図であ
る。FIG. 4 shows an embodiment of a disk management method according to the present invention.
It is an explanatory view showing a Primary History Table Descriptor.

【図５】本発明のディスク管理方法の実施形態における
History Descriptorを示す説明図である。FIG. 5 shows a disk management method according to an embodiment of the present invention.
It is an explanatory view showing History Descriptor.

【図６】本発明のディスク管理方法の実施形態における
ディレクトリ階層の例を示す説明図である。FIG. 6 is an explanatory diagram showing an example of a directory hierarchy in the embodiment of the disk management method of the present invention.

【図７】本発明のディスク管理方法の実施形態における
図６に対応するＵＤＦ管理情報とデータのディスク上で
の配置の例を示す説明図である。FIG. 7 is an explanatory diagram showing an example of an arrangement of UDF management information and data on a disk corresponding to FIG. 6 in the embodiment of the disk management method of the present invention.

【図８】本発明のディスク管理方法の実施形態における
図７に対応するHistory Tableの一例を示す説明図であ
る。FIG. 8 is an explanatory diagram showing an example of a History Table corresponding to FIG. 7 in the embodiment of the disk management method of the present invention.

【図９】本発明のディスク管理方法の実施形態において
ファイルが追加になった場合のHistory Tableの更新の
様子を示す説明図である。FIG. 9 is an explanatory diagram showing how a History Table is updated when a file is added in the embodiment of the disk management method of the present invention.

【図１０】本発明のディスク管理方法の実施形態におい
てファイルが変更になった場合のHistory Tableの更新
の様子を示す説明図である。FIG. 10 is an explanatory diagram showing how a History Table is updated when a file is changed in the embodiment of the disk management method of the present invention.

【図１１】本発明のディスク管理方法の実施形態におい
てファイルが削除になった場合のHistory Tableの更新
の様子を示す説明図である。FIG. 11 is an explanatory diagram showing how a History Table is updated when a file is deleted in the embodiment of the disk management method of the present invention.

【図１２】本発明のディスク管理方法の実施形態におい
てHistory Tableを再構築する様子を示す説明図であ
る。FIG. 12 is an explanatory diagram showing how a History Table is reconstructed in the embodiment of the disk management method of the present invention.

【図１３】本発明のディスク管理方法の実施形態におけ
るファイルやディレクトリの作成、変更、削除と言った
イベントが発生した際の処理の手順を示すフローチャー
トである。FIG. 13 is a flowchart showing a processing procedure when an event such as creation, change, or deletion of a file or directory occurs in the embodiment of the disk management method of the present invention.

【図１４】本発明のディスク管理方法の実施形態におけ
るバックアップ情報であるHistory Tableにアクセスす
る際の処理の手順を示すフローチャートである。FIG. 14 is a flowchart showing a procedure of processing when accessing a History Table which is backup information in the embodiment of the disk management method of the present invention.

【図１５】本発明のディスク管理方法の実施形態におけ
るバックアップ情報であるHistory Tableを再構築際の
処理の手順を示すフローチャートである。FIG. 15 is a flowchart showing a procedure of a process when rebuilding a History Table which is backup information in the embodiment of the disk management method of the present invention.

【図１６】本発明のディスク管理方法の実施形態におけ
るバックアップ情報であるHistory Tableから特定のフ
ァイルあるいはディレクトリに関する更新履歴を把握す
る処理の手順を示すフローチャートである。FIG. 16 is a flowchart showing a procedure of a process for grasping an update history related to a specific file or directory from a history table as backup information in the embodiment of the disk management method of the present invention.

【図１７】従来技術における論理ファイルシステムの管
理情報とデータの記録される領域の様子の説明図であ
る。FIG. 17 is an explanatory diagram of a state of an area in which management information and data of a logical file system in the related art are recorded.

【図１８】従来技術における論理ファイルシステムの管
理情報とデータの記録される領域が別れているファイル
システムの様子の説明図である。FIG. 18 is an explanatory diagram of a state of a file system in which management information of a logical file system and an area where data is recorded are separated according to a conventional technique.

【符号の説明】[Explanation of symbols]

１ データ入出力部 ２ データ処理部 ３ メモリ ４ システム制御部 ５ ディスク制御部 ６ ディスク 1 data input / output unit 2 data processing unit 3 memory 4 system control unit 5 disk control unit 6 disk

───────────────────────────────────────────────────── フロントページの続き (72)発明者 西村 元秀 大阪府大阪市阿倍野区長池町22番22号 シ ャープ株式会社内 (72)発明者 木山 次郎 大阪府大阪市阿倍野区長池町22番22号 シ ャープ株式会社内 (72)発明者 山村 博幸 大阪府大阪市阿倍野区長池町22番22号 シ ャープ株式会社内 (72)発明者 山口 孝好 大阪府大阪市阿倍野区長池町22番22号 シ ャープ株式会社内 Ｆターム(参考） 5B082 DD00 EA01 EA07  ──────────────────────────────────────────────────続 き Continued on the front page (72) Inventor Motohide Nishimura 22-22 Nagaikecho, Abeno-ku, Osaka City, Osaka Inside Sharp Corporation (72) Inventor Jiro Kiyama 22-22 Nagaikecho, Abeno-ku, Osaka City, Osaka (72) Inventor Hiroyuki Yamamura 22-22 Nagaikecho, Abeno-ku, Osaka-shi, Osaka Inside Sharp Co., Ltd. (72) Inventor Takayoshi Yamaguchi 22-22 Nagaikecho, Abeno-ku, Osaka-shi, Osaka F term (reference) 5B082 DD00 EA01 EA07

Claims (9)

【特許請求の範囲】[Claims] 【請求項１】 入力されたデータをファイルとして記録
媒体に記録し、 各ファイルを少なくとも該ファイルの記録媒体上におけ
る記録位置情報を含む管理情報により管理する記録装置
におけるファイル管理方法であって、 前記記録媒体へのファイルの追加、変更、削除のアクシ
ョンが行われる毎に、当該ファイルのファイル識別子と
当該ファイルの記録媒体上の記録位置情報及びファイル
のアクション種別を対応づけた履歴情報を順次作成し、 当該履歴情報を前記ファイル及び管理情報の記録領域と
は異なる履歴テーブル領域に履歴情報の作成順に記録す
ることを特徴とするファイル管理方法。1. A file management method in a recording device for recording input data as files on a recording medium and managing each file by management information including at least recording position information of the file on the recording medium, Every time an action of adding, changing, or deleting a file to the recording medium is performed, history information in which the file identifier of the file, the recording position information of the file on the recording medium, and the action type of the file are sequentially created. A file management method, wherein the history information is recorded in a history table area different from a recording area of the file and the management information in the order of generation of the history information. 【請求項２】 前記記録媒体へのファイルの追加、変
更、削除のアクションが行われる毎に、前記履歴情報を
記録装置のメモリ上に順次作成し、 前記記録装置において、前記記録媒体の取り出し指示が
行われた場合、当該履歴情報を該記録媒体上の前記ファ
イル及び管理情報の記録領域とは異なる履歴テーブル領
域に記録することを特徴とする前記請求項１に記載のフ
ァイル管理方法。2. Every time an action of adding, changing, or deleting a file to or from the recording medium is performed, the history information is sequentially created in a memory of a recording apparatus, and the recording apparatus instructs the recording apparatus to take out the recording medium. 2. The file management method according to claim 1, wherein, when the step (a) is performed, the history information is recorded in a history table area different from a recording area of the file and the management information on the recording medium. 【請求項３】 前記記録媒体へのファイルの追加、変
更、削除のアクションが行われる毎に、前記履歴情報を
記録装置のメモリ上に順次作成し、 前記記録装置において、メモリへの電源供給切断指示が
行われた場合、当該履歴情報を該記録媒体上の前記ファ
イル及び管理情報の記録領域とは異なる履歴テーブル領
域に記録することを特徴とする前記請求項１に記載のフ
ァイル管理方法。3. Every time an action of adding, changing, or deleting a file to or from the recording medium is performed, the history information is sequentially created in a memory of a recording device, and the power supply to the memory is cut off in the recording device. 2. The file management method according to claim 1, wherein when the instruction is issued, the history information is recorded in a history table area different from a recording area of the file and management information on the recording medium. 【請求項４】 履歴テーブルの履歴確認指示に基づい
て、前記履歴テーブル領域に記録された履歴情報のう
ち、所定のファイル識別子を有する履歴情報のみを抽出
することを特徴とする前記請求項１乃至３いずれかに記
載のファイル管理方法。4. The method according to claim 1, wherein only history information having a predetermined file identifier is extracted from history information recorded in the history table area based on a history check instruction of a history table. 3. The file management method according to any one of 3. 【請求項５】 履歴テーブルの再構築指示に基づいて、
前記履歴テーブル領域に記録された履歴情報のうち、同
一のファイル識別子を有する履歴情報を、当該履歴情報
のアクション種別に応じて一つの履歴情報に統合し、履
歴テーブル領域を縮小することを特徴とする前記請求項
１乃至４のいずれかに記載のファイル管理方法。5. Based on a history table restructuring instruction,
Among the history information recorded in the history table area, history information having the same file identifier is integrated into one piece of history information according to the action type of the history information, and the history table area is reduced. The file management method according to any one of claims 1 to 4, which performs the file management. 【請求項６】 前記履歴情報は、ファイル識別子の変更
を示す履歴情報を含み、ファイル識別子の変更により変
更されたファイル識別子は、変更後のファイル識別子と
同一ファイルとして履歴確認或いは再構築を行うことを
特徴とする前記請求項４または５に記載のファイル管理
方法。6. The history information includes history information indicating a change in a file identifier, and the file identifier changed by the change in the file identifier is subjected to history confirmation or reconstruction as the same file as the file identifier after the change. The file management method according to claim 4 or 5, wherein: 【請求項７】 前記管理情報は、ディレクトリの管理情
報を含み、 前記記録媒体へのディレクトリ情報の追加、変更、削除
のアクションが行われる毎に、当該ディレクトリの識別
子と当該ディレクトリ情報の記録媒体上の記録位置情報
及びアクション種別を対応づけた履歴情報を順次作成
し、 当該履歴情報を前記ファイル及びディレクトリ情報及び
管理情報の記録領域とは異なる履歴テーブル領域に順次
追記記録することを特徴とする前記請求項１乃至６のい
ずれかに記載のファイル管理方法。7. The management information includes directory management information, and each time an action of adding, changing, or deleting directory information to the recording medium is performed, an identifier of the directory and the directory information are recorded on the recording medium. History information in which the recording position information and the action type are associated with each other, and the history information is sequentially added and recorded in a history table area different from the recording area of the file, directory information, and management information. The file management method according to claim 1. 【請求項８】 ファイルの読出し指示に基づいて、前記
管理情報を検索して、ファイルの読出しを行う際、当該
ファイルの管理情報が読み出せない場合、 前記履歴テーブル領域から、当該ファイルのファイル識
別子を有する最新の履歴情報を読出し、当該履歴情報に
基づいてファイルの読出しを行うことを特徴とする前記
請求項１乃至７に記載のファイル管理方法。8. When the management information is searched based on a file reading instruction and the file is read, if the management information of the file cannot be read, the file identifier of the file is read from the history table area. The file management method according to any one of claims 1 to 7, wherein the latest history information having the following is read out, and a file is read out based on the history information. 【請求項９】 管理情報の再構築指示に基づいて、前記
履歴テーブル領域から履歴情報を読みだし、当該履歴情
報に基づいて、管理情報を生成し、当該管理情報を記録
媒体に記録することを特徴とする前記請求項１乃至８の
いずれかに記載のファイル管理方法。9. A method of reading history information from the history table area based on a management information restructuring instruction, generating management information based on the history information, and recording the management information on a recording medium. The file management method according to any one of claims 1 to 8, wherein: