JP4076078B2 - ファイル管理方法 - Google Patents

Description

本発明は、記録媒体内に含まれるファイルを管理する方法に関するものである。

従来、光ディスク、磁気ディスク、光磁気ディスク等の記録媒体内に含まれる動画や静止画や音声等の情報を、画像表示ソフトや電子アルバムソフト等のアプリケーションで扱う場合は、図２(A)に示すようにUDFやFAT等のファイルシステムを通してディスク上の各情報にアクセスしていた。

また、印刷、一覧表示、スライドショー等で複数ファイルのグループ化が必要な場合は、プレイリストファイルやDPOFファイル等、それぞれのグループに応じて、属するファイルや必要な情報を記述する管理ファイルを作成し、グループ化ファイルの管理が行われていた。

しかしながら、図２(A)に示される従来のシステムのようにアプリケーションが直接ファイルシステムを利用して各ファイルにアクセスするような場合、ファイル数やグループ数が多くなると、それらを一括して管理することが困難になり、必要な情報を探すのに時間がかかるという問題があった。さらに、ファイルシステムを通してファイルを特定する場合は、ファイルの種類は拡張子で判断するしかなく、映像や音声ファイル等で同じ種類の拡張子が付けられている場合は見分けを付けづらく、迅速な検索の足かせとなっていた。

また、記録済みの複数のファイルを時系列に再生する場合は、すべてのファイルへアクセスして記録時間順に並べ替える必要があった。この場合、ディレクトリ構造やファイル名を工夫して時系列情報を保持することも可能だが、ディレクトリ構造やファイル名の自由度が減り、ファイル管理の面で不便であった。

また、上述した管理ファイルを用いる場合は、グループ毎に管理ファイルを作成する必要があった。そのため各管理ファイルに含まれているメンバー等の情報を知るためには各管理ファイルをいちいち開いて調べなければならず、ファイル管理の面で不便であった。さらに、あるファイルがいずれかの管理ファイルに含まれているかどうかを判断するにも、全ての管理ファイルを開いて調べる必要があり、ファイルを削除する場合等に管理ファイルに含まれているかどうかを判断することが困難であった。その他、上記管理ファイルは、その管理ファイルを利用するアプリケーション毎にフォーマットが異なるため他のアプリケーションで利用できないといった汎用性の問題もあった。

また、管理ファイルを用いる場合においても各ファイルへのアクセスはアプリケーションが直接ファイルシステムを利用して行っていたため、必要な情報を探すのに時間が掛かるという問題は解決されていなかった。

本発明は、上記問題に鑑みてなされたものであり、アプリケーション間での汎用性が高く、大量のファイル及びグループ情報の取り扱いを容易にするファイル管理方法の提供を目的とするものである。

以下に上記目的を達成するための一例を示す。

情報記録媒体上に記録された複数のファイルのそれぞれを管理するためのファイル情報と、前記ファイルを複数のグループにグループ化したグループ化情報とを含むコンテンツ管理ファイルを作成し、前記コンテンツ管理ファイルから読み出した前記各情報に基づいて前記ファイルのグループ管理を行なうファイルシステムにおけるファイル管理方法において、
前記ファイル情報には削除情報、ファイル名、親ディレクトリ情報、各ファイルが所属するグループの個数情報が含まれ、前記グループ化情報には各グループに属するファイル一覧が含まれ、ユーザにより指定されたグループ内に削除済みのファイルが存在する場合、その削除済みファイルに対応するファイル情報の前記個数情報を１減らした値に書き換えると共に、前記個数情報が０になった場合には当該ファイル情報を上書き可能に設定する。

本発明では、図２(B)に示すように、必要な全ファイルと全グループを一括管理するファイルであるCMF（Contents Management File）を設けることにより、アプリケーションはファイルシステムと直接やり取りせずに、CMFを通してディスク上の大量のファイルを扱ったり、グループ化等の必要な処理を汎用的に行うことが可能となる。

１．CMFの構造
まず、コンテンツ管理ファイルCMF(Contents Management File)の構造に関して説明する。以下に述べるディレクトリ構造やファイル名、およびCMFの具体的な数値等は一例であり、本実施例と異なる場合でも本発明は適用可能である。ディスク等にデータを記録する場合は、一般にFATやUDF等のファイルシステムによるディレクトリ構造があり、その中にファイルが記録されている。図26は今回CMFで管理するディレクトリ構造の例で、ROOTディレクトリ[80]の下に印刷等を管理するMISCディレクトリ[81]、静止画記録用のDCIMディレクトリ[82]、動画、音声、プレイリスト等を記録するVIDEOディレクトリ[83]が配置されている。DCIMディレクトリ[82]の下には3桁の数字で始まる静止画ディレクトリ[84]が存在し、VIDEOディレクトリ[83]の下には3桁の数字で始まる動画ディレクトリ[85]、音声ディレクトリ[86]、プレイリストディレクトリ[87]が存在する。それぞれのディレクトリ名の先頭に付く3桁の数字は、同じ種類のディレクトリで重なることはない。静止画、動画、音声、プレイリストディレクトリの下には、それぞれ静止画ファイル[92]、動画ファイル[93]、音声ファイル[94]、プレイリストファイル[95]が記録されており、先頭4文字の英数字に続いて4桁の数字を持つファイル名を持つ。ファイル名に付く4桁の数字は、同一ディレクトリの中で同じ種類のファイルの場合、重なることはない。これらのファイルや複数ファイルのグループ化等を管理するのがCMFであり、CMFは汎用性があるため、複数のアプリケーションから利用することが可能である（図2）。なお、CMF自身もファイルシステムで管理される一つのファイル[90]であるから、ディスク上のどこか（本実施例ではROOTディレクトリ[80]の下）に保存される。

図1はCMFの全体構造を示したものである。CMFは16Kバイトのサイズを持つ1つの管理情報(Management Information[1])と、8Kバイトのサイズを持つ数種類の情報を組み合わせた構造をしており、8Kバイト情報の一塊をInformation Blockと呼ぶ。通常のInformation BlockはParent Group Information[2]、Parent Group Member Information[3]、Child Group Information[4]、Child Group Member Information[5]、File Information[6]、Text Information[7]の6種類であり、グループは親グループ(Parent Group)と子グループ(Child Group)の2階層が作成可能である。後述するが、他にVendor Specific Information[8]とDummy Information [9]があり、Vendor Specific Information[8]はVendor独自の情報を記録するときに用い、Dummy Information[9]は前もって領域を確保しておく場合に使用する。各Information Blockの先頭にはBlock内の空き領域を管理するSpace Bitmapが配置されており、データの存在する領域は”1”、空き領域は”0”となる。最初は各Information Blockには空き領域が存在するが、情報を追加していくことにより、それぞれのInformation Blockが一杯になると、新たに8KBのInformation BlockをCMF末尾に追加していく。なお、Information Blockのサイズは8KB以外でもよく、各Information Blockでサイズが異なっても構わないが、記録媒体の誤り訂正単位（ECCブロック）を2の階乗（1,2,4,8,16,,）で割ったサイズを持つ。すなわち、ECCブロックが32KBの場合は、Information Blockのサイズは、32KB、16KB、8KB、4KB、、、の値を取り得る。こうすることにより、Information Blockの先頭は常にECCブロックの先頭と一致し、一つのInformation BlockがECCブロックをまたがって記録されることがない。

Management Information[1]はCMF全体を管理する部分で、一般的な情報を記録するGeneral Information[11]、ファイルの種類を一覧にしたFile Type Table [12]、CMFを作成／編集したVendorのIDを記録したVendor ID Table[13]、Information Blockの種類を一覧にしたBlock Type Table[14]、各Information Block内のオブジェクト数を管理するNumber Management Table[15]、各Information Blockを管理するInformation Block Table[16]から成る。Parent Group Information[2]は親グループの情報を記録するもので、空き領域管理のSpace Bitmap[21]と実際の情報を記したParent Group Descriptors [22]とから成る。Parent Group Member Information[3]には親グループに含まれる子グループの情報が記録されており、空き領域管理のSpace Bitmap[31]とメンバー一覧であるParent Group Member Descriptors[32]から成る。同様にChild Group Information[4]は子グループの情報を記録するもので、空き領域管理のSpace Bitmap[41]と実際の情報を記したChild Group Descriptors [42]とから成る。Child Group Member Information[5]には子グループに含まれるファイルの情報が記録されており、空き領域管理のSpace Bitmap[51]とメンバー一覧であるChild Group Member Descriptors[52]から成る。File Information[6]はファイルの情報が記録されており、空き領域管理のSpace Bitmap[61]とファイル情報File Descriptors[62]から成る。Text Information[7]はテキストの情報が記録されており、空き領域管理のSpace Bitmap[71]とテキスト情報Text Descriptors[72]から成る。

以下、各Information Blockの詳細な構造に関して述べる。図3はCMF全体を管理するManagement Information[1]の構造である。上述したように、General Information[11]、File Type Table[12]、Vendor ID Table[13]、Block Type Table [14]、Number Management Table[15]、Information Block Table[16]から成り、Information Block Table[16]は各Information Blockに対応したInformation Block Descriptor[17]から構成される。尚、Information Block Descriptor[17]の記録順序がInformation Blockの記録順序と一致しているので、Information Block Table[16]を見ると、必要とするInformation BlockのCMFファイル内での記録位置がわかる。データサイズはGeneral Information[11]が512バイト、File Type Table[12]が1024バイト、Vendor ID Table[13]が512バイト、Block Type Table[14]が512バイト、Number Management Table[15]が512バイト、Information Block Table[16]が各Information Block毎に8バイトである。Information BlockがB個の場合は合計3072＋8×Bバイトになり、16KバイトのManagement Information Block[1]にはInformation Blockが最大1664個格納可能である。

図4はManagement Information[1]内に含まれるGeneral Information[11]の構造である。ここには識別情報や日時といった一般的な情報や、CMF内に含まれるInformation Block数、コメント等が含まれる。CMF IdentifierはCMFの先頭にファイル識別情報として記録するもので、CMF Versionは将来CMFの構造が変更になった場合にどの構造で書かれているのかを識別するためのものである。File SizeはCMF全体のサイズでディスク初期化時は64Kバイトになる。Vendor IdentifierとProduct IdentifierはCMF作成者や作成機を識別するもので、各Vendorが自由に文字列を付与できる。Disk Identifierはディスク内容（コンテンツ）の識別情報でUUID（Universally Unique Identifier）が記録される。これはディスクを初期化すると変更されるので、各ディスクで不変ではない。また、ディスクがコピーされた場合はDisk Identifierもそのままコピーされるので、各ディスクに固有でもない。このDisk Identifierを用いて2つのディスクがコピーにより作成されたものかどうかを判断することができる。

Initial Time、Create Time、Modify Timeは、それぞれ初期化日時、CMF作成日時、CMF更新日時で、UDFファイルシステムの日時情報と同じ形式の12バイト情報である。通常はInitial TimeとCreate Timeは同一であるが、ディスクをコピーした場合にはInitial Timeはコピー元の情報をそのまま用いるが、Create Timeはコピーした日時を記録する。すなわち、Initial TimeとCreate Timeを比較することにより、ディスクがオリジナルかコピーかを判別することができる。また、ディスクの内容が変更された場合はCMFにも反映されてModify Timeが更新されるので、2つのディスクのDisk Identifierと Modify Timeを比較して、両者が同一の場合は2つのディスクの中身（コンテンツ）は一致していると判断できる。

Auto Start Type、Auto Start Attribute、Auto Start Object Identifierはディスク挿入時や電源投入時の自動起動情報で、Auto Start Typeは自動起動するデータの種類（グループかファイル）、Auto Start Attributeは自動起動するかどうかの設定、Auto Start Object Identifierは自動起動するグループやファイルの番号が入る。Number of Information BlocksはCMFに含まれるInformation Block数で、Comment Lengthにコメントの長さ、Comment欄に127バイトの文字列が記録される。なお文字列として、ファイルシステムで用いられているものと同じ文字コードが用いられる。最後にReserved領域が設けられ、General Information全体のサイズを512バイトにしている。

図5はManagement Information[1]内に含まれるFile Type Table[12]の構造例である。基本的にファイルの拡張子一覧であるが、同一の拡張子であっても種類の異なるファイル（動画や音声等）は区別している。たとえば、同じ拡張子”MPG”を持つファイルでも、動画と音声が含まれているもの（Movie）はType ID=3で、音声のみが含まれているもの（Audio）はType ID=4となる。一つの拡張子に付き4バイトまでの長さを格納でき、4バイトよりも短い拡張子は余った領域を0x00で埋める。全部で256個の種類の拡張子を登録でき、128から254の番号はVendor独自の拡張子を登録可能である。なお、番号0のNullは拡張子のないファイルを表し、番号255のNot SpecifiedはFile Type Table[12]に登録されていない拡張子を示す。

図6はManagement Information[1]内に含まれるVendor ID Table[13]の構造であり、Vendor Specific Information Blockを作成したVendorを示すのに用いられる。各Vendor IDは4バイトの領域を持つが、実際にはEthernet（富士ゼロックス株式会社の登録商標）のネットワークカード等でMACアドレス（の前半3バイト）として用いられる、IEEEで管理されるベンダー固有のID（カンパニーID）を使用し、残り1バイトは0x00で埋める。全部で128個のIDを登録できるが、ID=0は共通のInformation Typeを示すために用いるデフォルトIDであり、ID=127はIDなし（No Information）を示すので、Vendorは126個登録可能である。

図7はManagement Information[1]内に含まれるBlock Type Table[14]の構造であり、Information Blockの種類一覧が格納される。図8で示される2バイトのInformation Block Type Descriptorを256個格納することが可能で、Vendor ID（図6）とInformation Type（図9）をそれぞれ1バイトで組み合わせて指定する。Information Typeは図9に示されているように、256種類の分類が可能で、Type 0〜127はシステム用、Type 128〜255はユーザー（Vendor Specific）用である。システム用のうち、Type 0〜8（通常オブジェクトInformation）とType 127（Dummy Information）はすでに規定されており、Type 9〜126はReservedである。なお、理由は後述するがType 0,7,8は使用しない。Block Type Table（図7）のうち、Type 0〜8は予め定められており、Vendor IDが0（Default ID）で、Information Typeは0〜8が入る。なお、Block Type 0,7,8はInformation Type（図9）と同様に使用しない。

図10はManagement Information[1]内に含まれるNumber Management Table[15]の構造であり、Block Type Table[14]（図7）で示される各Information Block Typeに含まれる全オブジェクト数を表す。これは同一のInformation Block Typeを持つ全Information Blockに含まれるオブジェクト数の合計で、たとえばCMFにFile Information Block[6]が10個含まれていれば、その中に含まれるファイル数をすべて足し合わせたものとなる。Information Block Type（図7）に応じて256個のオブジェクト数を各2バイト（65536個以内）で格納できる。すなわち、Information Block Typeが1〜6の場合、それぞれ親グループ数、親グループメンバー数、子グループ数、子グループメンバー数、ファイル数、テキスト数となる。Information Block Type 0の場合は使わないが、Information Block Type 7,8に相当する部分が、それぞれ親グループと子グループのコメント数になっている。これは、Text InformationにはGroup Informationとそれ以外（Vendor Specific Information等）のコメントを格納できるため、グループとそれ以外に使われているコメント数を分離するためである。全テキスト数からグループに使われているコメント数を引くと、グループ以外に使われているText Descriptorの数がわかる。

図11はInformation Block Table[16]の要素であるInformation Block Descriptor [17]の構造である。これが複数集まってInformation Block Table[16]を構成する。Block TypeはInformation Blockの種類で、Block Type Table[14]で示される値が入る。Block AttributeはInformation Blockの属性情報で、Information Blockの種類により含まれる内容は異なる。File Information Blockの場合は、ファイル情報とディレクトリ情報がそれぞれ含まれるかどうかという情報が入り、Text Information Blockの場合は、親グループ、子グループ、その他のコメント情報がそれぞれ含まれているかどうかの情報が入る。なお、すべてのInformation Blockに共通して、Space Bitmapが含まれているかどうかの属性情報も持つ。

Block SizeはInformation Blockのサイズで、2KBの整数倍で表現し、本実施例ではInformation Blockはすべて8Kバイトなので4になる。Descriptor SizeはInformation Blockに含まれる一つのDescriptorのサイズで、これを用いてInformation Block内に含まれる最大Descriptor数(n)や先頭Descriptor位置(p)を計算することができる。（Block Size = bバイト、Descriptor Size = dバイト）
最大Descriptor数 ：n = int( (b×8)／(1+8×d) )
先頭Descriptor位置：p = b−d×n

Block Specified DataはInformation Blockに固有の情報であるが、System Information Block（Information Type 0〜127）の場合は、図12に示すようにData LengthとNumber of Objectsの情報が格納される。Data LengthはInformation Block内の有効データ長で、データの途中に空き領域があるかどうかに関わらず、最後のデータまでの長さである。Number of ObjectsはInformation Block内に含まれるデータ数であり、Descriptorの個数が入る。各Block内の空き領域は、それぞれのBlock内のSpace Bitmapで管理し、各Block内の空き領域数とデータ長は、上記CMF先頭の管理Blockで管理されるので、メモリ上に常駐しておくデータ量を減らすとともに、検索量を減らすことが可能となる。

各Information Block内に記録することのできるObject数は種類により固定なので、最大記録可能数からNumber of Objectsを引くことにより空き領域数を計算できる。さらにNumber of ObjectsにDescriptor Sizeを掛けることにより必要なデータ長が計算でき、これをData Lengthと比較することによりデータの途中に空き領域があるかどうかも判定できる。

図13は、親グループと子グループの一般情報を記録するParent Group Information Block[2]とChild Group Information Block[4]の構造を示したもので、両者の構造は同一である。これは8KバイトのInformation Block内に64バイト単位（セル）のグループ情報Parent/Child Group Descriptor[24,44]を一覧にしたものであり、グループ情報[24,44]の集合がParent/Child Group Descriptors [22,42]である。各64バイト単位のセルに有効なグループ情報が格納されているかどうかを示すのがParent/Child Group Descriptor Space Bitmap [21,41]である。一つのInformation Block内にグループ情報[24,44]は最大127個格納可能であり、各セルに有効なデータが存在するかどうかをSpace Bitmap [21,41]が1ビット／セルで16バイトを用いて管理する。すなわちSpace Bitmap [21,41]の中で”1”で表されるビットのセルには有効なグループ情報が格納されており、”0”の場合は有効な情報は何も書かれていないので上書き可能ということである。Reserved領域[23,43]は、Space Bitmap[21,41]の64バイト単位のセルに対する余剰領域である。なお、グループ情報Parent/Child Group Descriptor[24,44]数がG個の場合は、有効データサイズは64＋64×Gバイトになる。また、本実施例において親グループと子グループのGroup DescriptorはCMF全体で、それぞれ最大16K個まで記録できる。

図14は、Group Descriptor[24,44]の構造を示したもので、親グループと子グループで構造は同一である。Group Typeは、親グループか子グループかという情報と、ユーザーが作成したユーザーグループかシステムが自動的に作成したシステムグループかといった情報が含まれる。システムグループの場合はグループの種類が記録され、ユーザーグループの場合はユーザーがグループの種類を設定することができる。本実施例においては、システムが自動的に作成するグループとして、記録順序をもとにした日付グループとプレイリストに含まれるファイルを一覧にしたプレイリストグループがあり、日付子グループの一覧が日付親グループで、プレイリスト子グループの一覧がプレイリスト親グループである。日付子グループのメンバーには全ての種類のファイルを含めることができるので、日付グループを用いればファイルの種類に関わらず記録順序を再現することが可能となる。

Group Attributeはグループの属性情報で、削除されたグループかどうか、削除禁止属性の他に、代表サムネイル画像がグループメンバーのサムネイルかどうか、Group DescriptorにExtended Dataが含まれるかどうか等の情報が含まれる。Member Descriptor IDはグループに含まれるメンバーを記録したGroup Member Descriptorを特定するもので、Group Member Information Block内の記録位置で示される。これは、CMF全体に含まれるGroup Member Descriptorの記録順序に従った2バイトの通し番号で表され、番号がわかるとそのグループが含まれるInformation Blockと、その中の位置を特定できる。一つのGroup Member Information Blockには最大127個のグループメンバー情報が記録できるので、たとえばMember Descriptor IDが300の場合は、3つ目のGroup Member Information Block内で46番目のグループメンバー情報を指すことがわかる。Comment IDはそのグループに付加されたコメントを示すもので、グループ一覧の表示やグループの検索等に利用し、実体はText Informationの中にある。Group Member Descriptorの指定方法と同様にテキストの記録順序に従った2バイトの通し番号で表され、コメントがない場合は0xFFFFが入る。

Link Countは、子グループの場合は親グループから参照されている数で、Link Countが0なら、その子グループはどの親グループにも属していないことになる。子グループのLink Countが1よりも大きい場合はいずれかの親グループから参照されていることになるので、もし削除されても上書きしてはいけない。すなわち、削除される子グループの属するGroup Information Block[2,4]内のSpace Bitmap[21,41]で、該当の削除子グループ位置を使用領域（”1”）のままにしておく。こうすることにより、子グループが削除された場合に、該当する子グループの属する親グループの情報を変更する必要がなくなる（本来、親グループに属する子グループが削除されたら、親グループ情報を変更すべきであるが、変更するには親グループに属する子グループIDを検索する必要があり時間がかかる）。逆に、親グループが削除された場合は、親グループが含む子グループのLink Countを1づつ減少させるが、そのときにLink Countが0になった子グループが削除済みであれば、Space Bitmap[21,41]で該当の子グループ情報位置を空き領域（”0”）に設定し、上書き可能にしておく。なお、本実施例において、親グループは他のグループから参照されないので、Link Countの値は常に0である。

Group Nameはそのグループの名前で、システムが自動的に作成するグループ以外はユーザーが自由に名前を付けても良い。システムグループである日付グループの場合は日付（YYYY：MM：DD）を、プレイリストグループの場合はディレクトリ番号とファイル名（nnn：PLAYxxxx）を記録する。Group NameはUTF-8またはUTF-16（ファイルシステムと同じ文字コード）で表現され、先頭1バイトは文字コードの識別に使用し、余った領域は0x00で埋める。Create/Modify Date and Timeはグループ情報を作成／更新した日時であり、UDFの日時情報と同じ形式の12バイトで保存する。Thumbnail Member IDはグループ一覧等を表示するときに用いる代表サムネイルを持つ代表メンバーで、設定されていない場合（ID=0xFFFF）はGroup Member Descriptorの先頭メンバーを代表とする。グループが子グループの場合は、Thumbnail Member IDはFile Descriptorに記録されているファイル番号を指し、親グループの場合は子グループかファイルのどちらかを指す。どちらを指すかはGroup Attributeに情報が書かれており、もし子グループの場合はChild Group DescriptorのID、ファイルの場合はFile DescriptorのIDとなる。なお、親グループの代表メンバーが子グループの場合は、代表サムネイルは代表子グループの代表画像を用いる。Total Number of Membersは、このグループに属する全てのGroup Member Descriptorに含まれるメンバー数の合計である。

Extended Dataは上記以外のグループ情報を格納する場所であり、図15に示す構造を持つ。Extended Data内には複数のData Elementを格納でき、全Data Elementのサイズを合計した値（Data Length）を先頭1バイトに記録する。図16にData Elementの構造を示す。Data TypeはData Elementの種類を表し、Data Lengthは実際のデータのサイズ、Dataは実際のデータである。図17にData Typeを示すが、全部で256個登録でき、Type 0〜127がSystem Data、Type 128〜255がUser Dataである。System DataのうちType 0〜4は規定されており、以下各Data Typeの実際のデータ内容を示す。Null Data（Type 0）はExtended Dataの余った領域を埋めるためにExtended Dataの末尾に用いる。Date Information（Type 1）はグループの種類が日付グループの場合に作成日時を記録するもので、UDFのtimestampと同じ構造をもつ。Play List Information（Type 2）はグループの種類がプレイリストグループの場合にプレイリストファイルIDを格納するもので、File Information中に記録されたプレイリストファイルのFile Descriptor IDで表す。Link Information（Type 3）はこのグループが関係する他のObject Descriptorへのリンク情報を表し、複数個のObject Descriptorを格納可能である。このとき、各Object Descriptorは1バイトのInformation Block Type（図7）と2バイトのDescriptor IDで示される。Next Group Information（Type 4）は同じ日付やプレイリストのグループが複数個存在する場合に、次のGroup Descriptorを示すために用いられ、2バイトのDescriptor IDで示される。その他User Data（Type 128〜255）はユーザーが独自に情報を記録できるが、先頭1バイトにVendor ID（図6）を記録しておく。なお、Extended Dataは24＋64×nバイト（nは0以上）のサイズを持ち、一つのGroup Descriptorに収まらない場合（ｎが1以上の場合）は直後のGroup Descriptorに続けて記録する。このとき、Extended Dataのみが記録されたGroup DescriptorはGroup IDが欠番となる（図18にその例を示す）。

本実施例におけるGroup Descriptorのサイズは64バイトであるため、一つのInformation Block内に最大127個しか記録できないが、一部の情報をGroup Member Descriptorに移動することにより、一つのInformation Block内に格納できる最大Group数を増加させることができる。たとえば、Create/Modify Date and TimeとExtended DataをGroup Member Descriptorに移動してGroup Descritporのサイズを32KBにすると、一つのInformation Blockに255個格納できる。さらに、8バイト分の情報のみを残すと一つのInformation Blockに1008個格納できるので、メモリ上に記録できるグループ数を増やすことができる。もし、すべての情報をGroup Member Descritporに格納すると、Group DescriptorにはGroup Member Descriptor ID（2バイト）のみが残ることになり、これはグループに関する全情報を納めたGroup Member Descriptorの位置を指すポインタの役割をする。

図19は、親グループと子グループのメンバー情報を記録するParent Group Member Information Block[3]とChild Group Member Information Block[5]の構造を示したもので、両者の構造は同一である。これは8KバイトのInformation Block内に64バイト単位（セル）のグループメンバー情報Parent/Child Group Member Descriptor[34,54]を一覧にしたものであり、グループメンバー情報[34,54]の集合がParent/Child Group Member Descriptors[32,52]である。各64バイト単位のセルに有効なグループ情報が格納されているかどうかを示すのがParent/Child Group Member Descriptor Space Bitmap[31,51]である。一つのInformation Block内にグループメンバー情報[34,54]は最大127個格納可能であり、各セルに有効なデータが存在するかどうかをSpace Bitmap[31,51]が1ビット／セルで16バイトを用いて管理する。すなわちSpace Bitmap[31,51]の中で”1”で表されるビットのセルには有効なグループメンバー情報が格納されており、”0”の場合は有効な情報は何も書かれていないので上書き可能ということである。Reserved領域[33,53]は、Space Bitmap[31,51]の64バイト単位のセルに対する余剰領域である。なお、グループメンバー情報Parent/Child Group Member Descriptor[34,54]数がM個の場合は、有効データサイズは64＋64×Mバイトになる。また、本実施例において親グループメンバーと子グループメンバーのMember DescriptorはCMF全体で、それぞれ最大16K個まで記録できる。

Group Member Descriptor[34,54]にはグループに含まれるメンバー（子グループやファイル）の一覧が入るので、含まれるメンバーの数によりDescriptorのサイズは変化する。そこで、グループメンバー情報の編集が容易なように、記録単位を64バイトに固定して、メンバー数が多い場合は複数のGroup Member Descriptorに記録する。本実施例では一塊のグループメンバー情報は同一のGroup Member Information Blockに含まれるので、Group Member Descriptor [34,54]を連続して使用できるのは最大127個までということになる。また、本実施例においては、親グループには子グループのみが含まれ、子グループにはファイルのみが含まれるが、プレイリストや印刷を管理するDPOF等の複数ファイルを管理するファイル（グループ化ファイル）も子グループとして扱う。

図20は、Group Member Descriptor[34,54]の構造を示したもので、親グループと子グループで構造は同一である。Group Member TypeとGroup Member AttributeはこのGroup Member Descriptorが属するGroup Descriptorと同一の内容が入る。Next Member Descriptor IDはグループメンバーが一つのGroup Member Descriptorに入りきらなかった場合に次のGroup Member Descriptorを示すもので、Group Member Information Block内の記録位置で示される。これは、CMF全体に含まれるGroup Member Descriptorの記録順序に従った2バイトの通し番号で表される。なお、Next Member Descriptorがない場合（最後のGroup Member Descriptorの場合）は0xFFFFが入る。Number of Membersは、このGroup Member Descriptor[34,54]に含まれるメンバー数で、Member IDsにメンバー一覧が入る。一つのGroup Member Descriptor（64バイト）には最大29個のメンバーを格納でき、一塊のグループに含まれるメンバー数が多くなった場合は、Group Member Descriptor [34,54]を繋げて格納していく。同じグループに属するGroup Member Descriptorsが同一のGroup Member Information Block [3,5]内にすべて含まれなければならない場合は、一つのグループに含まれるメンバー数は最大3683個となる。Member IDの指定方法はNext Member Descriptor IDの指定方法と同様で、子グループIDはChild Group Information [4]に記録されているChild Group Descriptor [44]の順序に従った番号（2バイト）で指定され、ファイルIDは、File Information[6]に記録されているFile Descriptor[64]の順序に従った番号（2バイト）で指定される。

もし、Group Descriptorのサイズを小さくするために、グループ情報の一部をGroup Member Descriptorに記録する場合は、最初のGroup Member Descriptorに移動された情報は格納される。すなわち、最初のGroup Member DescriptorにはGroup Descriptorから移動された情報とGroup Member Descriptorに本来記録されるべき情報が両方含まれることになる。ただし、この場合もGroup Member Descriptorのサイズは64バイトなので、Member IDsに含まれるメンバー数(N)が小さくなる。グループメンバー一覧が最初のGroup Member Descriptorに入りきらない場合は、新たなGroup Member Descriptorに記録することになるが、2つ目以降のGroup Member Descriptorは通常の構造(図20)となる。

図21はファイルの情報を記録するFile Information[6]の構造を示したものである。これは8KバイトのInformation Block内に16バイト単位（セル）のファイル／ディレクトリ情報File Descriptor[64]を一覧にしたものであり、File Descriptor [64]の集合がFile Descriptors[62]で、各16バイト単位のセルに有効なファイル／ディレクトリ情報が格納されているかどうかを示すのがFile Descriptor Space Bitmap[61]である。一つのInformation Block内にFile Descriptor[64]は最大508個格納可能であり、各セルに有効なデータが存在するかどうかをSpace Bitmap[61]が1ビット／セルで64バイトを用いて管理する。すなわちSpace Bitmap[61]の中で”1”で表されるビットのセルには有効なFile Descriptorが格納されており、”0”の場合は有効な情報は何も書かれていないので上書き可能ということである。なお、File Descriptor[64]数がF個の場合は、有効データサイズは64＋16×Fバイトになる。また、ファイル／ディレクトリ情報はCMF全体で、最大64K個まで記録できる。

図22はファイルおよびディレクトリ情報であるFile Descriptor[64]の構造を示したものである。File Attributeはファイルやディレクトリの属性情報で、ファイルかディレクトリか、削除されたファイルかどうかや、削除禁止属性等の他に、アフレコ用音声や遷移用映像、説明用のテキストといった補助ファイル属性、File DescriptorにExtended Dataが含まれているかどうか等の情報も入る。File Typeは、動画、静止画、音声、プレイリストといったファイルの種類を示すもので、File Type Table[12]（図5）で示される一覧の番号を1バイトで表す。これによりファイルの拡張子も特定できる。なお、ディレクトリの場合はFile TypeはNull（”0”）となる。Link Countは、子グループの場合と同様に、ファイルが子グループから参照されている数で、Link Countが0なら、そのファイルはどの子グループにも属していないことになる。ファイルのLink Countが1よりも大きい場合はいずれかの子グループから参照されていることになるので、もし削除されても上書きしてはいけない。すなわち、削除されるファイルの属するFile Information Block[6]内のSpace Bitmap[61]で、該当の削除ファイル位置を使用領域（”1”）のままにしておく。こうすることにより、ファイルが削除された場合に、該当するファイルの属する子グループの情報を変更する必要がなくなる（本来、子グループに属するファイルが削除されたら、子グループ情報を変更すべきであるが、変更するには子グループに属するファイルIDを検索する必要があり時間がかかる）。逆に、子グループが削除された場合は、子グループが含むファイルのLink Countを1づつ減少させるが、そのときにLink Countが0になったファイルが削除済みであれば、Space Bitmap[61]で該当のファイル情報位置を空き領域（”0”）に設定し、上書き可能にしておく。なお、File Descriptorがディレクトリ情報の場合はLink Countは常に0である。

Parent Directory IDは親ディレクトリのFile IDで、File Information[6]に記録されているディレクトリ情報File Descriptor[64]の順序に従った番号（2バイト）で指定される。Name LengthとNameはそれぞれファイルあるいはディレクトリ名の長さと実際の名前で、NameはUTF-8またはUTF-16（ファイルシステムと同じ文字コード）で表される。Name領域の先頭1バイトは文字コードの識別子で、UTF-8は0x08、UTF-16は0x10が入る。なお、Name Lengthは文字コード識別子も含んだバイト長であり、Name欄には拡張子を取った名前が最大255バイトまで格納できる。Extended Dataはグループ情報のExtended Data（図15、図16、図17）と同じ構造を持つ。なお、NameとExtended Dataは可変長のため、File Descriptor[64]のサイズが16バイトよりも大きくなるときは（N+Eが10バイト以上のときは）、直後のFile Descriptorに続けて記録し、一つのFile Descriptorが16バイトの整数倍になるようにExtended Dataのサイズを調整する。このとき、File NameやExtended Dataを記録するために用いられたFile Descriptor領域はFile Information[6]のSpace Bitmap [61]で使用領域(“1”)となり、その場所で指定されるFile IDは欠番となる（図23にその例を示す）。

なお、本実施例ではファイル名に実際の文字列を格納しているが、ディレクトリ名やファイル名を2バイトの数値で表現して、File Descriptorのサイズを16バイトよりも小さくすることができる。すなわち、File Descriptor（図22）において、Name LengthとNameを2バイトの値（Name ID）で置き換え、File Descriptorのサイズを8バイトにするのである。図26のディレクトリ構造で示したように、本実施例においては、動画、静止画、音声、プレイリスト等を含むディレクトリ名は、先頭3文字が3桁の数字で表現され、同じ種類のファイルが含まれるディレクトリ名は数字が重なることはない。そのため、File Typeでファイルの種類を指定し、ディレクトリ名としてディレクトリ番号を指定すれば、ディレクトリは一意に求まる。ファイル名に関してもディレクトリ名と同様で、ファイル名に付加されている4桁の数字は、一つのディレクトリの中で同じ種類のファイルで重なることはない。すなわち、File Typeから拡張子がわかるので、ファイル名でファイルの番号を指定することによりファイルは一意に求まる。こうすることにより、一つのInformation Block内に含まれるFile Descriptor数は1008個になり、メモリ上により多くのファイル情報を格納できる。

図24はグループのコメントやベンダー独自のコメントで用いるテキスト情報を記録するText Information [7]の構造を示したものである。これは8KバイトのInformation Block内に128バイト単位（セル）のテキスト情報Text Descriptor[74]を一覧にしたものであり、テキスト情報[74]の集合がText Descriptors[72]で、各128バイト単位のセルに有効なテキスト情報が格納されているかどうかを示すのがText Descriptor Space Bitmap[71]である。一つのInformation Block内にテキスト情報[74]は最大63個格納可能であり、各セルに有効なデータが存在するかどうかをSpace Bitmap[71]が1ビット／セルで8バイトを用いて管理する。すなわちSpace Bitmap[71]の中で”1”で表されるビットのセルには有効なテキスト情報が格納されており、”0”の場合は有効な情報は何も書かれていないので上書き可能ということである。Reserved領域[73]は、Space Bitmap[71]の128バイト単位のセルに対する余剰領域である。なお、テキスト情報Text Descriptor[74]数がT個の場合は、有効データサイズは128＋128×Tバイトになる。

Management Information[1]には、Information Blockが最大1664個まで記録でき、Parent Group Information[2]、Parent Group Member Information[3]、Child Group Information[4]、Child Group Member Information[5]、File Information [6]がそれぞれ最大130個づつ使用する。また、親グループと子グループのコメント用にText Information[7]を521個確保しておく必要があるため、ユーザーが自由に使えるText Information[7]とVendor Specific Information[8]の合計は493個である。

図25はテキスト情報であるText Descriptor[64]の構造を示したものである。Text Attributeはテキストの属性情報で、削除されたテキストかどうかや、削除禁止属性等が入る。Object Typeは、テキストを参照している情報（Object）の種類を指し、Block Type Table[14]（図7）のType値で示される。Object IDはテキストを参照しているObject Information（Group Information等）に記録されているObject Descriptor（Group Descriptor等）の順序に従った番号が2バイトで指定される。Object TypeとObject IDにより、テキストを参照している情報（グループ等）の逆参照が可能になる。Text Lengthには文字列の長さを記録し、Text欄に実際の文字列をUTF-8またはUTF-16（ファイルシステムと同じ文字コード）で記録する。Text領域の先頭1バイトは文字コードの識別子で、UTF-8は0x08、UTF-16は0x10が入る。なお、Text Lengthは文字コード識別子も含んだバイト長であり、Text欄には最大123バイトまで格納できる。

２．CMFの操作手順
次に、CMFを用いたファイル管理の手順について図43を用いて説明する。図43では、電源投入時あるいはディスク挿入時から、電源切断時あるいはディスク取り出し時までの処理を示している。CMF全体のサイズは可変であるが、すべての情報は8Kバイト単位のInformation Blockに含まれており、それらのInformation BlockはCMFの先頭16KバイトのManagement Informationで管理されるので、Management Informationを読み込むことによりCMF全体の構造を知ることができる。そのため、電源投入時あるいはディスク挿入時には、まずManagement Informationをディスクから読み込む。その後、必要に応じてアプリケーションはManagement Information に基づいてInformation Blockをディスクから読み込むのであるが、ディスク初期化時に構成される、グループ情報、グループメンバー情報、ファイル情報、テキスト情報の48Kバイト分をManagement Informationと一緒に最初から読み込んでおいてもよい。

次に、グループやファイル一覧を表示する場合には、アプリケーションは読み込んだManagement Information に基づいて所望の表示を行う。表示形態はアプリケーション側の設定次第であり、詳しくは後述する。また、ディスク内容が変更された場合やグループ情報が追加・編集された場合にはCMFの内容を編集することになる。このとき、グループ化はユーザーが指定して行う場合の他に、システムが日付等で自動的に行うグループ化の2種類がある。いずれの場合においても、必要とするInformation Blockがメモリ上になければManagement Information内のInformation Block Tableを利用して、ディスクからInformation Blockを読み出す操作が必要となる。一連の処理が終了し、電源切断やディスクの取り出しを行う時、もし、CMFファイルの内容が変更されているならば、ディスクに更新されたCMFを書き戻す。なお、CMFをディスクに書き戻すタイミングは終了処理時以外でも構わない。

３．CMFの情報を用いた表示例
CMFを使ってグループやファイルを参照する手順の一例について説明する。図54はCMFの全体構造例である。まず、Information Block Descriptor[17]がCMFに含まれている各Information Blockを指し示し[B2〜B8]、位置や種類や内容等の情報を管理している。Parent Group Descriptor[24]は自分が含むメンバー一覧であるParent Group Member Descriptor[34]を示し[G2]、Parent Group Member Descriptor [34]はメンバーであるChild Group Descriptor[44]を示す[G3]。Child Group Descriptor[44]は自分が含むメンバー一覧であるChild Group Member Descriptor[54]を示し[G4]、Child Group Member Descriptor[54]はメンバーであるFile Descriptor[64]を示す[G5]。このとき、逆方向を示す情報はなく、親グループには子グループしか含まれず、子グループにはファイルしか含まれない。Text Descriptor[74]はParent Group Descriptor[24]、Child Group Descriptor[44]、Vendor Specific Information Block[8]から参照されるが[T2,T4,T8]、Text Descriptor[74]自身も参照元の情報を持っているので双方向にリンクされている。CMF末尾にあるDummy Information Block[9]は、CMFのサイズをECCブロック（たとえば32KB）の整数倍にそろえるために挿入する8KBのダミーBlockである。これはCMFが含まれるECCブロック内に他のデータが記録されることを防ぐもので、CMFの末尾にInformation Blockを追加する場合に置き換えられる。また、各Information Blockの先頭をECCブロックの先頭に一致させることにより、各Information Blockが複数のECCブロックにまたがって記録されることがなく、Information Blockの更新や追加が効率よく行える。

例えば、図55のようなグループ一覧を表示する場合には、先ず、アプリケーションは事前に読み込んであるManagement Informationに含まれるInformation Block Descriptor[17]を調べ、Block TypeがGroup Information であるInformation Block Descriptor[17]を抽出する。Information Block Descriptor [17]の記録順番は、そのまま該当ブロック[2,3,4,5,6,7,,,]の記録位置を示すものであるから、記録順番をアドレスに変換し、該当するGroup Information[2,4]にアクセスする。次に、Group Information[2,4]に含まれるGroup Descriptor [24,44]から名前やコメント等を抽出して必要な項目をディスプレイに表示するのである。ただし、コメントはText Information Block[7]に記録されており、Group Descriptor [24,44]内にはコメントを指すテキストIDしか含まれていない。そのため、Information Block Descriptor[17]を参照して、目的とするテキストIDのText Information Block[7]にアクセスし、Text Descriptor[74]を読み出す必要がある。Text Descriptor [74]には、自身を参照しているGroup Descriptor[24,44]への逆参照情報が含まれているので、この逆参照情報を利用すれば、コメントを検索して、そのコメントが含まれるグループ情報を取り出すことは容易である。

次に、他の表示形態について図56、図57を用いて説明する。図55では、ディスプレイ[100]上に画面のタイトル[101]と親グループのコメント[104]が並び、表示領域をスクロールバー[102]で表現している。ここで、枠[103]で囲まれている親グループを選択した場合、指定された親グループに所属する子グループの一覧が図56のように表示される。これは、選択された親グループに関連するParent Group Member Descriptor[34]から属する子グループのグループＩＤを取得し、そのグループＩＤからChild Group Descriptor[44]にアクセスし、選択した親グループに属する子グループ一覧を表示する。このとき、代表画像およびコメントの実体はChild Group Descriptor[44]内には含まれていないので、Thumbnail IDとComment IDから目的とするFile Descriptor[64]やText Descriptor [74]にアクセスして読み出す必要がある。この表示中に、削除されている子グループが見つかれば、その子グループのLink Countを1減らす。もしLink Countが 0になれば、その子グループの属するInformation Blockで、Space Bitmapの該当個所の値を”0”（上書き可能）にし、Information Block DescriptorのNumber of Objectsを1減らすとともに、必要ならData Lengthも減少させる。

図56の表示例では、ディスプレイ[100]上に画面のタイトル[101]と子グループのサムネイル画像[106]およびコメント[105]が並び、表示領域をスクロールバー[102]で表現している。子グループのサムネイルはThumbnail IDで表される代表ファイルのサムネイルであり、代表ファイルが指定されていなければ、子グループに含まれるファイル一覧の先頭ファイルが代表となる。また、選択されている子グループは枠[103]で囲まれており、この状態で決定すると指定された子グループに所属するファイルの一覧が表示されるか、ファイルが順次再生される。なお、ファイルが順次再生される場合に、補助属性を持つファイルは再生を飛ばしてもよい。もし、子グループがプレイリストの場合はプレイリストが実行される。ファイルの一覧表示や順次再生中に、削除されているファイルが見つかれば、そのファイルのLink Countを1減らす。もしLink Countが 0になれば、そのファイルの属するInformation Blockで、Space Bitmapの該当個所の値を”0”（上書き可能）にし、Information Block DescriptorのNumber of Objectsを1減らすとともに、必要ならData Lengthも減少させる。

図57には選択した子グループに属するファイル一覧の表示例が示されている。表示に必要な情報の取得は上述と同様な手順で行われ、この例ではサムネイル画像のみを表示している。ディスプレイ[100]上に画面のタイトル[101]とファイルのサムネイル画像[107]が並び、表示領域をスクロールバー[102]で表現している。また、選択されているファイルは枠[103]で囲まれており、この状態で決定すると指定されたファイルが実行される。もしファイルが静止画なら静止画が表示され、ファイルが動画なら動画の再生が開始される。なお、補助属性を持つファイルは一覧の中に表示しなくてもよい。

以上、3種類の表示例を示したが、親グループ、子グループ、ファイルで上記の表示例に決まっているわけではなく、たとえば親グループの表示に代表子グループのサムネイルとコメントを同時に表示してもよく、ファイル一覧の表示にコメントのみを用いてもよい。

４．CMFの更新手順
次にCMFの内容を更新する場合について説明する。先ず、更新によるCMFのデータ構造の変化を各状況に応じて説明する。

図27はディスク初期化時のディレクトリ構造で、図28はそのときのCMF構造である。初期化時は、ROOT[80]、MISC[81]、DCIM[82]、VIDEO[83]のディレクトリがあるだけで、ファイルは存在しない。CMFは16KバイトのManagement Information 1つと8KBのInformation Block 6個で構成されており、4つのディレクトリ情報と2つのグループ情報が含まれている。まず、本実施例においては、日付グループとプレイリストグループをデフォルトで持つので、これらの親グループ、すなわちParent Group Descriptor[22]と対応するParent Group Member Descriptor[32]が2つづつ作成される。このときParent Group Member Descriptor[32]は枠組みがあるだけで、メンバーは含まれていない。また、ディレクトリが4つあるので、ディレクトリ情報のFile Descriptor[62]が4つ作成される。これらのInformation Block内にあるSpace Bitmapは、データの入ったObject Descriptorの位置に該当するビットを”1”にしておく。子グループ情報[42,52]とテキスト情報[72]には何もデータが入っていない。Information Block Table[16]にはManagement Information[1]以外の6個分のBlockに関する情報が含まれる。なお、各Information Block内のReserved領域はSpace Bitmap領域に含めているので、図中には示していない。

図29は、初期化直後に動画ファイル（TAKE0001.MPG）[93]を一つだけ記録したときのディレクトリ構造であり、VIDEOディレクトリ[83]の下に動画ディレクトリ（100MOVIE）[85]が自動的に作成され、動画ファイルはこの下に記録される。図30はこのときのCMF構造である。図28と比較して、File Information[6]内のFile Descriptors[62]にディレクトリ情報とファイル情報が1つづつ追加される。ファイルが追加されると、自動的に日付グループに登録されるので、日付子グループのChild Group Descriptor[42]とそのメンバーであるChild Group Member Descriptor[52]が1つづつ自動生成される。新たに作成されたファイルはDate Child Group Member Descriptor[52]のメンバーとして登録され、今回作成されたDate Child Group Descriptor[42]も日付グループのDate Parent Group Member Descriptor[32]のメンバーとして登録される。このとき、Descriptorが追加されたInformation BlockはSpace Bitmapの記録位置に該当するビットを”0”から”1”に変更し、同時にInformation Block Table[16]の情報も更新する。

図31は、動画ディレクトリ[85]が2つと動画ファイル[93]が12個記録された状態から、新たにプレイリストファイル（PLAY0001.XML）[95]を追加したときのディレクトリ構造である。この例では、12個のファイルは2つのディレクトリに分割して記録されているので、動画ディレクトリ[85]は2つできている。プレイリストファイル[95]を新たに作成すると、VIDEOディレクトリ[83]の下にプレイリストディレクトリ（300PLIST）[87]が自動的に作成されて、プレイリストファイルはこの下に記録される。図32はこのときのCMF構造で、ディレクトリとファイルが一つづつ増えて合計20個になったので、File Descriptors[62]の数は20になっている。さらにプレイリストファイルが追加されると、自動的にプレイリストグループに登録されるので、プレイリスト子グループのChild Group Descriptor[42]とそのメンバーであるChild Group Member Descriptor[52]が1つづつ自動生成される。新たに作成されたプレイリストファイルはPlay List Child Group Member Descriptor[52]のメンバーとして登録され、今回作成されたPlay List Child Group Descriptor[42]もプレイリストグループのPlay List Parent Group Member Descriptor[32]のメンバーとして登録される。このとき、Descriptorが追加されたInformation BlockはSpace Bitmapの記録位置に該当するビットを”0”から”1”に変更し、同時にInformation Block Table[16]の情報も更新する。

図33は図32の状態から、30個以上のファイルを含むコメント付き子グループを1つだけ追加したときのCMF構造である。プレイリスト等のグループ化ファイル以外にグループ化を行った場合は、実際のファイルは作成されないので、ディレクトリ構造は図31のままである。まず、30個以上（58個以下）の子グループはChild Group Member Descriptor[52]を2つ必要とするので、Child Group Member Descriptors [52]の子グループ数が2つと、それを参照するChild Group Descriptor[42]が1つ増加する。一塊のグループが消費するGroup Member Descriptor[52]の数に関わらず、Group Descriptor[42]は1つのグループに対し1しか増加しない。コメントはText Information[7]に記録されるので、Text Descriptor[72]が1つ増加する。以上3箇所の変更に対して、対応するInformation BlockのSpace Bitmap[41,51,71]とInformation Block Table [16]の情報が更新される。

図34は図33の状態から、子グループにメンバーを追加してChild Group Member Descriptor[52]が新たに作成されたときのCMF構造である。グループにメンバーを追加する場合は、既存のGroup Member Descriptorに空きがあればそこに埋めることができるが、空きがなければ新たにGroup Member Descriptorを作成する必要がある。この例ではChild Group Member Descriptor[52]を1つ追加している。同時に、新規Child Group Member Descriptor[52]に繋がるChild Group Member Descriptor[52]のNext Member Descriptor IDも更新する必要がある。これに伴い、対応するInformation BlockのSpace Bitmap[51]とInformation Block Table [16]の情報が更新される。

図35は図34の状態から、コメント付き親グループを1つだけ追加したときのCMF構造である。この場合もディレクトリ構造は図31のままで変化しない。まず、新たに追加される親グループには29個以下の子グループしか含まれていないので、Parent Group Descriptor[22]とParent Group Member Descriptor[32]は1つづつ増加する。コメントはText Information[7]に記録されるので、Text Descriptor[72]が1つ増加する。以上3箇所の変更に対して、対応するInformation BlockのSpace Bitmap[21,31,71]とInformation Block Table [16]の情報が更新される。

図36は初期化時のCMF容量が一杯になるデータ数を示しており、親グループ数、親グループメンバー数、子グループ数、子グループメンバー数はそれぞれ127個、ファイル数は508個、テキスト数は63個である。なお、実際にはグループ数はグループメンバー数よりも多くなることはない。

図37は初期化時のCMFが一杯になった状態から、ファイルが一つ追加された場合のCMF構造である。まず、CMFが一杯になった状態として、親グループ数と子グループ数がそれぞれ127個、ファイル数が508個、テキスト数が63個の状態だとする。この例ではGroup Descriptor 1つにつき、Group Member Descriptorは1つしか存在しないことを意味している。ここにファイル情報を1つ追加する場合、すでに存在するFile Information Block 1 [61,62]には空き領域がないので、CMFの末尾に新たなFile Information Block 2 [65,66]を追加する必要がある。その後、新たに追加されたFile Information Block 2 [65,66]にFile Descriptor 2 [66]を記録するのである。同時に、新規ファイルは自動的に日付グループに登録されるので、対応するDate Child Group Member Descriptor [52]のメンバーとして登録される。これに伴い、対応するSpace Bitmap 2 [65]の情報が更新されるとともに、Information Block Table[16]にブロック数が1つ追加される。

図38は図37の状態から、子グループにファイルを追加してChild Group Member Information Blockが新たに追加されたときのCMF構造である。グループにメンバーを追加する場合は、既存のGroup Member Descriptorに空きがあればそこに埋めることができるが、空きがなければ新たにGroup Member Descriptorを作成する必要がある。さらにこの例では、既存のChild Group Member Information Block 1 [51,52]に空き領域がないために、新たにCMF末尾にChild Group Member Information Block 2 [55,56]を追加し、Child Group Member Descriptor 2 [56]を作成している。同時に、新規Child Group Member Descriptor 2 [56]に繋がるChild Group Member Descriptor 1 [52]のNext Member Descriptor IDも更新する必要がある。これに伴い、対応するSpace Bitmap 2 [55]の情報が更新されるとともに、Information Block Table[16]にブロック数が1つ追加される。

図39は図38に続いてコメント付き子グループを追加したもので、既に存在するInformation Blockが一杯なので、新たにChild Group Information BlockとText Information Blockが追加されている。まず新規子グループ用にChild Group Information Block 2 [45,46]がCMFに追加され、そのメンバーがChild Group Member Descriptors 2 [56]に追加される。さらに子グループから参照されるコメントを格納するために、Text Information Block 2 [75,76]がCMFに追加され、Text Descriptors 2 [76]にテキスト情報が1つ追加される。これに伴い、対応するSpace Bitmap[45,55,75]の情報が更新されるとともに、Information Block Table [16]にブロック数が2つ追加される。

図40も図38と同様に、既に存在する子グループにファイルを追加したものであるが、この場合は追加される子グループの入っているInformation Block 1 [51,52]が既に一杯で追加できないときに、関連するグループメンバー情報全体を別のInformation Block 2 [55,56]に移動させている。なお、ファイルを追加する前のChild Group Member Descriptorは1つのみであり、新たにChild Group Member Descriptorを1つ追加するものと考える。一塊のグループを同一のInformation Blockに含ませるために、まず元のChild Group Member Descriptor 1 [52]をChild Group Member Descriptors 1 [52]からChild Group Member Descriptors 2 [56]に移動して、そこに新たにChild Group Member Descriptor 2 [56]を追加する。結果として、移動先であるChild Group Member Descriptors 2 [56]の子グループ数は2つ増加し、移動元のChild Group Member Descriptors 1 [52]の子グループ数は1つ減少する。さらに、Child Group Member Descriptorを参照しているChild Group Descriptor 1 [42]のGroup Member Descriptor IDの値も更新する必要がある。最後に、対応するSpace Bitmap[51,55]とInformation Block Table[16]の情報も更新する。

次にファイルやグループを削除した場合に関して説明する。図41はFile Descriptors 1 [62]に含まれるファイルを1つ削除した場合で、削除されるFile Descriptorに削除属性を付与する。このとき、Space Bitmap 1 [61]の該当個所の値を”0”（削除済み）にするかどうかは、削除ファイルのLink Countの値に依存する。もし、Link Countが0ならば、Space Bitmap 1 [61]の値を”0”にしてもよく、Link Countが1より大きい場合は、そのファイルはいずれかの子グループから参照されているので、Space Bitmap 1 [61]の値は”1”のままにして、上書き禁止にしておく。もしSpace Bitmap 1 [61]の値を変更した場合は、Information Block Table[16]の情報も更新する。

図42は、メンバー情報として2つのChild Group Member Descriptorを持つコメント付き子グループ情報Child Group Descriptorを1つ削除した場合のCMF構造である。まず、Child Group Descriptors 1 [42]で、削除する Group Descriptorに削除属性を付与する。このとき、Space Bitmap 1 [41]の該当個所の値を”0”（削除済み）にするかどうかは、削除グループのLink Countの値に依存する。もし、Link Countが0なら、Space Bitmap 1 [41]の値を”0”にしてもよく、Link Countが1より大きい場合は、そのグループはいずれかの親グループから参照されているので、Space Bitmap 1 [41]の値は”1”のままにして、上書き禁止にしておく。なお、親グループのLink Countは常に0なので、親グループを削除する場合は、Space Bitmapの該当個所を”0”（削除済み）に設定しても構わない。つぎに削除した子グループのメンバー情報を示すChild Group Member Descriptor 1 [52]を2つ削除する。これは削除する位置情報に対応したSpace Bitmap 1 [51]の該当個所を”0”（削除済み）に設定すればよい。続いて、削除グループが参照していたText Descriptors 1 [72]のテキスト情報を削除する。これも削除するテキストに対応したSpace Bitmap 1 [71]の該当個所を”0”（削除済み）に設定すればよい。以上、変更した3つのInformation BlockでSpace Bitmap [41,51,71]の値を変更した場合は、Information Block Table[16]の情報も更新する。

図44はInformation Blockの新規追加手順を示したものである。Information BlockはObject Descriptorの情報を追加する空き領域がなくなった場合に新たに追加される。まず、CMFの末尾に8Kバイトの領域を確保し、追加すべきDescriptor等の情報があれば、Space BitmapとReserved領域に続くDescriptor記録領域の先頭から必要な情報を記録するとともに、記録位置に該当するSpace Bitmapの個所を”1”に設定する。その後、Management Information内のInformation Block TableにInformation Block Descriptorを1つ追加し必要事項を記録する。Information Block Tableを変更したら、General Information内のオブジェクト数等の該当項目を更新する。

図45はDescriptorサイズが固定長である、グループ、ファイル、テキスト情報（オブジェクト）の新規追加手順を示したものである。これらの情報は記録サイズが固定長なので、空き領域が1つでもあれば記録可能である。まず、既存のInformation Blockに空きがあるかどうかを判定するには、目的のオブジェクトに対するInformation BlockのNumber of Objectsが最大記録可能数よりも小さければよい。もし、既存のInformation Blockに空きがあればそこに記録すればいいし、なければ新たにInformation Blockを作成して目的のオブジェクトを記録する。既存のInformation Block内に記録する場合に、もしNumber of Objectsから計算されるデータサイズ（Space Bitmap領域サイズ＋Reserved領域サイズ＋Number of Objects×セルサイズ）とData Lengthの値が等しい場合は、Data Lengthまでの領域に空きがないので、新規オブジェクト情報はData Lengthの直後から記録すればよい。もし、Number of Objectsから計算されるデータサイズよりもData Lengthの値が大きい場合は、途中に空き領域が存在するので、Space Bitmapを利用して空き領域を検索し、新規オブジェクト情報を記録する。なお、途中に空き領域があってもData Length以降に十分な領域が存在すれば、Space Bitmapを検索せずにData Lengthの直後から記録を開始してもよい。記録したら、同じInformation Block内のSpace Bitmapで該当個所の値を”1”にし、Information Block DescriptorのNumber of Objectsを1増やすとともに、必要ならData Lengthも増加させる。Data Lengthは新規作成したオブジェクトが有効データ長の末尾に付加された場合のみ増加し、途中の削除された領域に記録された場合には増加しない。

図46はDescriptorサイズが可変長である、グループメンバー情報（オブジェクト）の新規追加手順を示したものである。これらの情報は記録サイズが可変長なので、空き領域が足りるかどうかを判定しなければならない。まず、既存のInformation Blockに十分な空きがあるかどうかを判定するには、目的のオブジェクトに対するInformation BlockのNumber of Objectsを最大記録可能数から引いて比較すればよい。もし、既存のInformation Blockに十分な空きがあればそこに記録すればいいし、なければ新たにInformation Blockを作成して目的のオブジェクトを記録する。既存のInformation Block内に記録する場合に、もしNumber of Objectsから計算されるデータサイズ（Space Bitmap領域サイズ＋Reserved領域サイズ＋Number of Objects×セルサイズ）とData Lengthの値が等しい場合は、Data Lengthまでの領域に空きがないので、新規オブジェクト情報はData Lengthの直後から記録すればよい。もし、Number of Objectsから計算されるデータサイズよりもData Lengthの値が大きい場合は、途中に空き領域が存在するので、Space Bitmapを利用して空き領域を検索し、新規オブジェクト情報を記録する。なお、途中に空き領域があってもData Length以降に十分な領域が存在すれば、Space Bitmapを検索せずにData Lengthの直後から記録を開始してもよい。記録したら、同じInformation Block内のSpace Bitmapで該当個所の値を”1”にし、Information Block DescriptorのNumber of Objectsを追加オブジェクト数だけ増やすとともに、必要ならData Lengthも増加させる。Data Lengthは新規作成したオブジェクトが有効データ長の末尾に付加された場合のみ増加し、途中の削除された領域に記録された場合には増加しない。なお、グループメンバー情報を追加した場合は、そのGroup Member Descriptorを参照するGroup Descriptor のGroup Member ID、または直前のGroup Member DescriptorのNext Member IDを新規Member Descriptor IDに更新する必要がある。

次に、オブジェクトを削除する手順に関して説明する。図47はファイル情報の削除手順を示したものである。まず、File Descriptor内のFile Attributeで削除属性を付加し、Link Countが0の場合は同じInformation Block内のSpace Bitmapで該当個所の値を”0”にし、Information Block DescriptorのNumber of Objectsを1減らすとともに、必要ならData Lengthも減少させる。Link Countが0でない場合は上書きしてはいけないので、Space BitmapもInformation Block Descriptorも変更しない。このとき、Data Lengthは削除したオブジェクトが有効データ長の最後だった場合のみ減少し、途中の領域が削除された場合には減少しない。

図48はテキスト情報の削除手順を示したものである。テキストの場合はそのテキストを参照しているグループから切り離す必要があるので、そのグループのComment IDの値を0xFFFFにして、コメントなしにしておく。その後、同じInformation Block内のSpace Bitmapで該当個所の値を”0”にし、Information Block DescriptorのNumber of Objectsを1減らすとともに、必要ならData Lengthも減少させる。このとき、Data Lengthは削除したオブジェクトが有効データ長の最後だった場合のみ減少し、途中の領域が削除された場合には減少しない。

図49は子グループ情報の削除手順を示したものである。まず削除する子グループのGroup Descriptorに削除属性を付与する。このとき、Link Countが0の場合は上書きしてもよいので、Space Bitmapで該当個所の値を”0”にし、Information Block DescriptorのNumber of Objectsを1減らすとともに、必要ならData Lengthも減少させる。次に、コメントがある場合は、Text Informationの中の対応するテキストを削除する。続いてGroup Member IDをたどり、子グループに含まれるGroup Member Descriptorをすべて削除する。最後に子グループに含まれるファイルのLink Countをすべて1づつ減少させる。このとき、もしファイルが削除済みで、かつLink Countが0ならば、そのファイルの属するInformation Blockで、Space Bitmapの該当個所の値を”0”にして上書き可能にし、Information Block DescriptorのNumber of Objectsを1減らすとともに、必要ならData Lengthも減少させる。なお、Data Lengthは削除したオブジェクトが有効データ長の最後だった場合のみ減少し、途中の領域が削除された場合には減少しない。

図50は親グループ情報の削除手順を示したものである。親グループの場合は必ずLink Countが0なのでGroup Descriptorを完全に削除してもよく、Space Bitmapで該当個所の値を”0”にし、Information Block DescriptorのNumber of Objectsを1減らすとともに、必要ならData Lengthも減少させる。このとき、完全に削除されてしまうので、子グループの削除と違い、削除属性を付与する必要はない。次に、コメントがある場合は、Text Informationの中の対応するテキストを削除する。続いてGroup Member IDをたどり、親グループに含まれるGroup Member Descriptorをすべて削除する。最後に親グループに含まれる子グループのLink Countをすべて1づつ減少させる。このとき、もし子グループが削除済みで、かつLink Countが0ならば、その子グループの属するInformation Blockで、Space Bitmapの該当個所の値を”0”にして上書き可能にし、Information Block DescriptorのNumber of Objectsを1減らすとともに、必要ならData Lengthも減少させる。なお、Data Lengthは削除したオブジェクトが有効データ長の最後だった場合のみ減少し、途中の領域が削除された場合には減少しない。

図51はグループメンバー情報（オブジェクト）の移動手順を示したものである。これらの情報は記録サイズが可変長なので、空き領域が足りるかどうかを判定しなければならない。まず、既存のInformation Blockに十分な空きがあるかどうかを判定するには、目的のオブジェクトに対するInformation BlockのNumber of Objectsを最大記録可能数から引いて比較すればよい。もし、既存のInformation Blockに十分な空きがあればそこに移動すればいいし、なければ新たにInformation Blockを作成して目的のオブジェクトを移動する。既存のInformation Block内に移動する場合に、もしNumber of Objectsから計算されるデータサイズ（Space Bitmap領域サイズ＋Reserved領域サイズ＋Number of Objects×セルサイズ）とData Lengthの値が等しい場合は、Data Lengthまでの領域に空きがないので、移動するオブジェクト情報はData Lengthの直後から記録すればよい。もし、Number of Objectsから計算されるデータサイズよりもData Lengthの値が大きい場合は、途中に空き領域が存在するので、Space Bitmapを利用して空き領域を検索し、移動するオブジェクト情報を記録する。なお、途中に空き領域があってもData Length以降に十分な領域が存在すれば、Space Bitmapを検索せずにData Lengthの直後から記録を開始してもよい。移動したら、移動先のInformation Block内でSpace Bitmapの該当個所の値を”1”にし、Information Block DescriptorのNumber of Objectsを1増やすとともに、必要ならData Lengthも増加させる。また、移動したグループメンバーの属するGroup DescriptorのMember ID、または直前のGroup Member DescriptorのNext Member IDの値を新規Member Descriptor IDに書き換える。最後に移動元Group Member Information Block内のSpace Bitmapで該当個所の値を”0”にし、Information Block DescriptorのNumber of Objectsを1減らすとともに、必要ならData Lengthも減少させる。

続いて、親グループや子グループに含まれるメンバー（子グループやファイル等のオブジェクト）の追加／削除手順に関して説明する。図52はグループへのメンバー追加手順を示したものである。まず、追加したいグループのGroup Member Descriptorにメンバーを追加できる空き領域があれば、単に目的のGroup Member Descriptor内でオブジェクトIDを追加し、Total Number of Members情報を更新した後に、追加されたオブジェクトのLink Countを1づつ増加させればよい。もし領域が足らなければ、同じGroup Member Information Block内でGroup Member Descriptorを必要な数だけ追加する。このとき、オブジェクトを追加したいGroup Member Descriptorが含まれるGroup Member Information Block内にGroup Member Descriptorを追加する空き領域がなければ、別のGroup Member Information Blockに、1つのグループに属するすべてのGroup Member Descriptorを移動させてもよい。なお、既存のGroup Member Information Blockで空き領域が見つからなければ、新たにGroup Member Information Blockを作成する。

図53は親グループや子グループに含まれるメンバー（子グループやファイル等のオブジェクト）をグループのメンバーから削除する手順を示したものである。まず、削除したいメンバーをGroup Member Descriptorからとり除き、Total Number of Members情報を更新した後に、削除したオブジェクトのLink Countを1づつ減少させる。このとき、もしオブジェクトが削除済みで、かつLink Countが0ならば、そのオブジェクトの属するInformation Blockで、Space Bitmapの該当個所の値を”0”にし、Information Block DescriptorのNumber of Objectsを1減らすとともに、必要ならData Lengthも減少させる。さらに、グループからメンバーを削除することにより、何もメンバーを含まないGroup Member Descriptorが発生した場合は、そのグループ全体に渡ってNext Member Descriptor IDを付け直し、不要になったGroup Member Descriptorを削除する。

以上述べてきたように、必要な全ファイルと全グループを一括管理するファイルであるCMF（Contents Management File）を設けることにより、アプリケーションはファイルシステムを使わずに、CMFを通して大量のファイルを扱ったり、グループ化等の必要な処理を汎用的に行うことが可能になる。たとえば、複数のファイルを時系列に表示するには、日付順のグループ化を行うか、ファイル情報を時系列にCMFに記録し順番に再生するだけでよい。また、グループ情報を親グループと子グループに階層化することで、グループの管理も容易になる。

また、CMF内で各グループが含んでいるメンバー（子グループやファイル等のオブジェクト）の一覧を持ち、オブジェクトが自身の含まれるグループの数であるリンクカウンタを持つことで、あるグループに含まれるメンバー一覧をすぐに取り出すことができるとともに、あるオブジェクトがいずれかのグループに含まれているかどうかを簡単に判断できるようになる。これにより、いずれかのグループに含まれているオブジェクトを削除する場合に、警告等を出すことが容易になる。

CMFで拡張子をテーブルを用いて1バイトで表すことにより、ファイル名の情報量を減らすことができる。さらに、拡張子テーブルは、同じ拡張子でも種類により別の物として扱うことで、ファイルの種類を拡張子には関係なく分類できる。また、ファイル自身にも補助ファイル属性を設けることにより、一般の映像や音声等と区別することができる。

グループメンバー情報は、含まれるメンバー数によりサイズが変化するが、固定長サイズ（64バイト）の領域（セル）を連結して使うことにより、追加や削除等の処理を効率よく行うことが可能になる。また、グループ情報やメンバー情報は固定長（8Kバイト）の領域（Block）に分割記録され、同じグループに属する一連のメンバー情報は同一Blockに記録されるので、読み出し効率が高くなる。さらに、グループのコメントは別Blockに記録されるので、コメントのないグループ等を記録する場合に、格納効率が上がる。

各Block内の空き領域は、それぞれのBlock内のSpace Bitmapで管理し、各Block内の空き領域数やデータ長は、CMF先頭の管理Blockで管理することにより、メモリ上に常駐しておくデータ量を減らすとともに、検索量を減らすことが可能となる。さらに、ファイルやグループを指定するときに、記録されている位置の順番で指定することにより、ファイル情報やグループ情報の中に自身のID番号をもたなくてもよく、サイズの節減になるとともに、ファイル情報やグループ情報の指定において検索処理が不要となる。

Contents Management Fileの全体構造を示す図である。 Contents Management Fileの役割を示す図である。 Management Informationの構造を示す図である。 General Informationの構造を示す図である。 File Type Tableの構造を示す図である。 Vendor ID Tableの構造を示す図である。 Block Type Tableの構造を示す図である。 Information Block Type Descriptorの構造を示す図である。 Information Type一覧を示す図である。 Number Management Tableの構造を示す図である。 Information Block Descriptorの構造を示す図である。 Block Specified Dataの構造を示す図である。 Parent/Child Group Information Blockの構造を示す図である。 Group Descriptorの構造を示す図である。 Extended Dataの構造を示す図である。 Data Elementの構造を示す図である。 Data Type一覧を示す図である。 存在しないGroup IDの例を示す図である。 Parent/Child Group Member Information Blockの構造を示す図である。 Parent/Child Group Member Descriptorの構造を示す図である。 File Informationの構造を示す図である。 File Descriptorの構造を示す図である。 存在しないFile IDの例を示す図である。 Text Informationの構造を示す図である。 Text Descriptorの構造を示す図である。 ディスク内のディレクトリ構造を示す図である。 ディスク初期化時のディレクトリ構造を示す図である。 ディスク初期化時のＣＭＦ構造を示す図である。 ファイル(TAKE0001.MPG)追加時のディレクトリ構造を示す図である。 ファイル(TAKE0001.MPG)追加時のＣＭＦ構造を示す図である。 プレイリスト(PLAY0001.XML)追加時のディレクトリ構造を示す図である。 プレイリスト(PLAY0001.XML)追加時のＣＭＦ構造を示す図である。 多数ファイルを含むコメント付き子グループを１つ追加した時のＣＭＦ構造を示す図である。 子グループのメンバー追加時にMember Descriptorを新たに追加した時のCMF構造を示す図である。 コメント付き親グループを１つ追加した時のＣＭＦ構造を示す図である。 初期化時のＣＭＦ容量が一杯になるデータ数を示す図である。 ＣＭＦにFile Information Blockを新規追加した場合を示す図である。 CMFにChild Group Member Information Blockを新規追加した場合を示す図である。 CMFにChild-Group/Text Information Blockを新規追加した場合を示す図である。 空き領域のないInformation BlockにGroup Member Descriptorを追加した場合を示す図である。 ファイルを1つ削除した場合を示す図である。 2つのMember Descriptorsから成るコメント付き子グループを1つ削除した場合を示す図である。 CMFファイルの処理手順を示す図である。 Information Blockの新規追加手順を示す図である。 グループ情報／ファイル情報／テキスト情報の新規追加手順を示す図である。 グループメンバー情報の新規追加手順を示す図である。 ファイル情報の削除手順を示す図である。 テキスト情報の削除手順を示す図である。 子グループ情報の削除手順を示す図である。 親グループ情報の削除手順を示す図である。 グループメンバー情報の移動手順を示す図である。 グループへのメンバー追加手順を示す図である。 グループからのメンバー削除手順を示す図である。 CMFの各Descriptor間の関係を示す図である。 親グループ一覧表示例を示す図である。 子グループ一覧表示例を示す図である。 ファイル一覧表示例を示す図である。

符号の説明

１ Management Information
２ Parent Group Information
３ Parent Group Member Information
４ Child Group Information
５ Child Group Member Information
６ File Information
７ Text Information
１１ General Information
１２ File Type Table
１３ Vendor ID Table
１４ Block Type Table
１５ Number Management Table
１６ Information Block Table
２１ Space Bitmap
２２ Parent Group Descriptors
３１ Space Bitmap
３２ Parent Group Member Descriptors
４１ Space Bitmap
４２ Child Group Descriptors
５１ Space Bitmap
５２ Child Group Member Descriptors
６１ Space Bitmap
６２ File Descriptors
７１ Space Bitmap
７２ Text Descriptors

Claims (1)

1. 情報記録媒体上に記録された複数のファイルのそれぞれを管理するためのファイル情報と、前記ファイルを複数のグループにグループ化したグループ化情報とを含むコンテンツ管理ファイルを作成し、前記コンテンツ管理ファイルから読み出した前記各情報に基づいて前記ファイルのグループ管理を行なうファイルシステムにおけるファイル管理方法において、
   前記ファイル情報には削除情報、ファイル名、親ディレクトリ情報、各ファイルが所属するグループの個数情報が含まれ、前記グループ化情報には各グループに属するファイル一覧が含まれ、ユーザにより指定されたグループ内に削除済みのファイルが存在する場合、その削除済みファイルに対応するファイル情報の前記個数情報を１減らした値に書き換えると共に、前記個数情報が０になった場合には当該ファイル情報を上書き可能に設定することを特徴とするファイル管理方法。