ユニバーサルディスクフォーマット(UDF) 2.00

序文

この標準情報(TR)は, 1998年4月にOSTA(Optical Storage Technology Association)から発行されたUniversal Disk Format Specification Revision 2.00を翻訳して, 技術的内容を変更することなく作成した標準情報(TR)(タイプ�U)である。

1. 一般

1.0 適用範囲

この標準情報(TR)は，JIS X 0607及びJIS X 0607 追補1の部分集合を規定する。データ交換を最大限にすること，並びにJIS X 0607を実施するためのコスト及び複雑性を最小限にすることを, その主な目的とする。

この課題を達成するために，規定範囲を定義する。規定範囲は，JIS X 0607の使用上の規則及び制限を定義する。ここで定義する規定範囲を，UDFの適用範囲(UDF Compliant domain)とする。

この標準情報(TR)は，オペレーティングシステムごとにJIS X 0607の構造に関する次の課題に応える。

JIS X 0607の構造Xが与えられたとき，その構造Xの各欄について，指定されたオペレーティングシステムに関する次の課題に回答する。

• a) その欄の読出しオペレーティングシステムが，その欄中のデータを利用可能である場合，そのオペレーティングシステムにおける何に対して，その欄は対応しなければならないか。
• b) その欄の読出しオペレーティングシステムが，その欄中のデータを制約付きで利用可能である場合，そのオペレーティングシステムにおいて，その欄をどのように解釈しなければならないか。
• c) その欄の読出しオペレーティングシステムが，その欄中のデータを利用可能でない場合，そのオペレーティングシステムにおいて，その欄をどのように解釈しなければならないか。
• d) その欄の書込みオペレーティングシステムが，その欄中のデータを利用可能である場合，そのオペレーティングシステムにおける何から，その欄は対応しなければならないか。
• e) その欄の書込みオペレーティングシステムが，その欄中のデータを利用可能でない場合，オペレーティングシステムにおいて，その欄をどのように解釈しなければならないか。

JIS X 0607の構造のいくつかに関しては，これらの課題への回答は自明であるため，その構造は，ここには含めない。

JIS X 0607を明確にするための補足として，各構造に関する付加情報を提供することがある。

この標準情報(TR)は，JIS X 0607を実装する作業を容易にする支援をする。

1.1 構成

この標準情報(TR)は，JIS X 0607が規定する構造の扱いについての情報を与える。

この標準情報(TR)は，次に示す四つの基本的な節から成る。

• a) 基本制約及び基本要件 オペレーティングシステムに依存しない制約及び要件を定義。
• b) システム依存要件 オペレーティングシステムに依存する制約及び要件を定義。
• c) 利用者インタフェース要件 利用者インタフェースに関連する制約及び要件を定義。
• d) 附属書 追加の有用な情報。

この標準情報(TR)は，JIS X 0607で定義する構造の扱いに関する情報を提供し，次に示す分野をカバーしている。

• a) 媒体から読み出す場合の構造及び欄の解釈 これを"意味"として示す。
• b) 媒体に書き込む場合の構造及び欄の内容 これを"規定値"として示す。特記しない限り，書込みは，媒体中に新しい構造を作成することだけを意味する。媒体中に存在する構造の更新に適用する場合は，その旨を特記する。

各構造の欄がまず示され，次いで前述の分類に関して各欄の記述がある。各欄の記述情報で補足する。欄に関する意味が明白な場合には，構造の1個以上の欄を，記述しない場合がある。

用語遣い この標準情報(TR)では, "でなければならない(shall)"は必須の行為又は要件を示し, "してよい(may)"はオプションの行為又は要件を示し, "であることが望ましい(should)"は推奨するがオプションである行為又は要件を示す。

欄及び/又は構造に関連する特別な注釈は，"備考"と前置きして示す。

1.2 適合性

この標準情報(TR)は，JIS X 0607の第1部,第2部,第3部及び第4部への適合性を必要とする。この標準情報(TR)は，JIS X 0607の第5部への適合性はサポートしない。

ある処理システムがこの標準情報(TR)への適合性を主張するためには，その処理システムは，この標準情報(TR)で規定するすべての(必須の)要件を満たさなければならない。

適合性に関していくつかの要点を次に確認する。

• a) 複数ボリュームを利用可能にすることは，オプションとする。処理システムは，単一ボリュームだけを利用可能にして，適合性を主張できる。
• b) 複数区画を利用可能にすることは，オプションとする。処理システムは，この標準情報(TR)で定義する単一ボリューム中の特別な複数区画を利用可能にすることなく，適合性を主張できる。
• c) 利用可能な媒体。処理システムは，1種類の形の媒体又は2種類以上の形の媒体が利用可能であれば，適合性を主張できる。すべての処理システムは，物理的にアクセス可能ならば，どのような媒体でも読み出せることが望ましい。
• d) 複セションのサポート。CD-R媒体の読出しができる処理システムでは，6.10.3に規定するとおり，複セションで記録したCD-Rの読み出しができなければならない。
• e) ファイル名の翻訳。処理システムは，オペレーティングシステムの制約に適合するために，ファイル名を翻訳する必要がある場合，必ずこの標準情報(TR)で定義するアルゴリズムを使用しなければならない。
• f) 拡張属性。すべての適合処理システムでは，媒体中に存在する既存の拡張属性を保存しなければならない。処理システムは，利用可能なオペレーティングシステムに関する拡張属性の作成及び保守をしなければならない。
   参考 例えば，Macintoshの処理システムは，媒体中に存在するOS/2の拡張属性を保存しなければならない。Macintoshの処理システムは，この標準情報(TR)が規定するすべてのMacintosh拡張属性の作成及び保守をもしなければならない。
• g) 読出しの下位互換性。 UDF2.00に適合する処理システムは，UDF1.50及びUDF1.02に従って書込まれたすべての媒体の読出しができるなければならない。
• h) 書込みの下位互換性。UDF2.00の構造は，UDF1.50及びUDF1.02構造を含む媒体に書き込んではならない。UDF1.50及びUDF1.02構造は，UDF2.00の構造を含む媒体に書き込んではならない。これら二つの要件は，媒体が，異なる版のUDF構造を含むことを防止する。

1.3 参照

1.3.1 引用規定

JIS X 0606:1998, 情報交換用CD-ROMのボリューム構造及びファイル構造
 備考 ISO 9660:1988, Volume and file structure of CD-ROM for Information Interchange が, この規格の前の版(1990年版)に対応している。

JIS S 8605-1993, コンパクトディスクディジタルオーディオシステム
 備考1 IEC 908:1987, Compact disc digital audio systems が, この規格に一致している。IEC 908:1987は, 既に改訂されて, IEC 60908:1999として発行されている。
 備考2 Red Book: Compact Disc Digital Audio System Description は, IEC 60908:1999に一致している。

JIS X 6281-1992, 120mm再生専用形光ディスク(CD-ROM)
 備考1 ISO/IEC 10149:1995, Data interchange on read-only 120mm optical data disc (CD-ROM) の前の版(1989年版)が, この規格に一致している。
 備考2 Yellow Book: Compact Disc Read Only Memory System Description が, この規格に対応している。

TR X 0025:2000, 追記形コンパクトディスク(CD-R)システム
 備考 Orange Book, Recordable Compact Disc System, part-II が, この規定に一致している。

Orange Book, Recordable Compact Disc System, part-III

JIS X 0607-1996, 非逐次記録を用いる追記形及び書換形の情報交換用媒体のボリューム及びファイルの構造
 備考 ISO/IEC 13346:1995, Volume and file structure of write-once and rewritable media using non-sequential recording for information interchange が, この規格に一致している。

JIS X 0607 追補1:2001
 備考1 ISO/IEC 13346:1999 のISO/IEC 13346:1995 に対する改訂部分が, この追補に一致している。
 備考2 ISO/IEC 13346:1999 には, 複数のデータストリームファイルのサポートが追加されている。 この標準情報(TR)において[ ]で括られた参照は, ISO/IEC 13346:1999 を[x/a.b.c]の様式で参照し, ここで，xは節番号，a.b.c.は項又は図の番号とする。

1.3.2 定義

1.3.2.1 オーディオセション (Audio session) 一つ又は複数のオーディオトラックを含み，データトラックを含まない。

1.3.2.2 オーディオトラック (Audio track) JIS S 8605が規定するオーディオセクタを含む設計がなされたトラック。

1.3.2.3 CD-R (CD-Recordable) 追記形CD。TR X 0025が規定する追記形コンパクトディスク。

1.3.2.4 CD-RW (CD-Rewritable) 書換形CD。Orange Book，part-IIIが規定する重ね書き可能なコンパクトディスク。

1.3.2.5 クリーンファイルシステム (Clean File System) この標準情報(TR)に適合する媒体のファイルシステム。

1.3.2.6 データトラック (Data track) JIS X 6281が規定するデータセクタを含む設計がなされたトラック。

1.3.2.7 ダーティファイルシステム (Dirty File System) クリーンファイルシステムではないファイルシステム。

1.3.2.8 固定パケット (Fixed Packet) 与えられたトラックに含まれるパケットすべてが，トラック記述子ブロックに指定された長さをもつ，インクリメンタル記録方式。CDドライブに提示される番地は，TR X 0025及びOrange Book, part-IIIが規定する，番地付け方式の方式2に従って翻訳される。

1.3.2.9 ICB (Information Control Block) JIS X 0607における制御ノード。

1.3.2.10 論理ブロック番地 (Logical Block Address) 論理ブロック番号[3/8.8.1]。
 備考1 これを，[4/7.1]で規定する論理ブロック番地と混同してはならない。[4/7.1]で規定する論理ブロック番地は，論理ブロック番号[3/8.8.1]と，区画照合数[3/8.8]を含むlb_addr構造で示され，区画照合数は，指し示された論理ブロック[3/8.8.1]を含む区画[3/8.7]を識別する。
 備考2 [3/8.8.1]で定義する論理ブロック番号は，指し示す論理ブロック[3/8.8.1]を含む区画[3/8.7]の，区画マップ[3/10.7]が示す方法に従って，論理セクタ番号[3/8.1.2]変換される。

1.3.2.11 媒体ブロック番地 (Media Block Address) 記録のための関連規格[1/5.10]で示される，一意のセクタ番地から派生するセクタ番号[3/8.1.1]とする。この規定では，セクタ番号[3/8.1.1]は論理セクタ番号[3/8.1.2]に等しい。

1.3.2.12 パケット (Packet) 隣接するセクタ[1/5.9]の整数倍である記録可能単位のことで，利用者データセクタから構成される。パケットライト動作のオーバヘッドとして記録される追加セクタ[1/5.9]を含むことがあり，記録のための関連規格[1/5.10]に従って指し示すことができる。

1.3.2.13 物理番地 (Physical Address) 記録のための関連規格[1/5.10]で示される，特有のセクタ番地から派生するセクタ番号[3/8.1.1]。この規定では，セクタ番号[3/8.1.1]は，論理セクタ番号[3/8.1.2]に等しい。

1.3.2.14 物理ブロック (Physical Block Address) 記録のための関連規格で示される特有のセクタ番地[1/5.10]から派生するセクタ番号[3/8.1.1]。この規定では，セクタ番号[3/8.1.1]は，論理セクタ番号[3/8.1.2]に等しい。

1.3.2.15 物理セクタ (Physical Sector) 記録のための関連規格[1/5.10]で示されるセクタ[1/5.9]。この規定では，セクタ[1/5.9]は，論理セクタ[3/8.1.2]に等しい。

1.3.2.16 ランダムアクセスファイルシステム (Random Access File System) 任意に書込みができる媒体のためのファイルシステムであり，追記形又は書換形。

1.3.2.17 順次ファイルシステム (Sequential File System) 順次に書き込まれた媒体のためのファイルシステム。例えばCD-R。

1.3.2.18 セション (Session) ボリュームのトラックは，Orange Book第2部が規定とおり，一つ又は複数のセションに編成しなければならない。一つのセションは，一つ又は複数のトラックの列とし，そのトラック番号は連続した昇順の列を形成しなければならない。

1.3.2.19 トラック (Track) ボリュームのセクタは，一つ又は複数のトラックに編成されなければならない。一つのトラックはセクタの列とし，そのセクタ番号は，連続する昇順の列でなければならない。セクタは複数のトラックに属してはならない。  備考 トラック間に間隙がある場合もある。つまり，トラックの最後のセクタが，次のトラックの，最初のセクタの直後にくる必要はない。

1.3.2.20 UDF (Iniversal Disk Format) ユニバーサルディスクフォーマット

1.3.2.21 利用者データブロック (user data block) パケットのセクタ[1/5.9] (この規定では論理セクタ[3/8.1.2]と同じ)に記録された論理ブロック[3/8.8.1]のことで，ドライブの利用者が意図的に記録したデータが含まれる。仮に，その構成セクタ[1/5.9]が，記録のための関連規格[1/5.10]に従って番地付け可能であっても，構成セクタがパケット記録のオーバヘッドに使用された論理ブロック[3/8.8.1]は，特にこれには含まれない。利用者データブロックは，論理ブロック[3/8.8.1]のとおりに，論理ブロック番号[3/8.8.1]で識別される。

1.3.2.22 利用者データセクタ (user data sector) ドライブの利用者が意図的に記録したデータを含む，パケットのセクタ[1/5.9]とする。パケットを記録するオーバヘッドに使用されるセクタ[1/5.9]は，記録のための関連規格[1/5.10]に従って番地付けできても[1/5.9]，特にこれには含まれない。いずれのセクタ[1/5.9]とも同じく，利用者データセクタはセクタ番号[3/8.1.1]で識別される。本規定では，セクタ番号[3/8.1.1]は，論理セクタ番号[3/8.1.2]に等しい。

1.3.2.23 可変パケット (Variable Packet) 与えられたトラックにおける各パケットが，ホストが決定した長さをもつ，増加記録方式。CDドライブに提示される番地は，TR X 0025及びOrange Book, part-IIIにおける，方式1の番地付けで規定するとおりとする。

1.3.2.24 仮想番地 (Virtual Address) 仮想区画における論理ブロック[3/8.8.1]の論理ブロック番号[3/8.8.1]｡ このような論理ブロック[3/8.8.1]は，対応する非仮想区画の論理ブロック[3/8.8.1]の空間を使って記録される。VATのNth Uint32は，対応する仮想区画の論理ブロック番号Nを記録するために使われる，非仮想区画の論理ブロック番号[3/8.8.1]を表す。最初の仮想番地は, 0とする。

1.3.2.25 仮想区画 (virtual partion) この規定の2.2.8に従って記録される種別2の区画マップ[3/10.7.3]によって，論理ボリューム記述子[3/10.6]で識別される論理ボリューム[3/8.8]の区画。仮想区画マップには，区画番号が含まれるが，これは，同一の論理ボリューム記述子[3/10.6]における種別1の区画マップ[3/10.7.2]の区画番号[3/10.7.2.4]と同じとする。仮想区画の各論理ブロック[3/8.8.1]は，その対応する非仮想区画の論理ブロック[3/8.8.1]の空間を使って記録される。VATには，その対応する仮想区画の論理ブロック[3/8.8.1]を記録するために使われている，非仮想区画の論理ブロック[3/8.8.1]が列挙される。

1.3.2.26 仮想セクタ (virtual sector) 仮想区画の論理ブロック[3/8.8.1]。このような論理ブロック[3/8.8.1]は，対応する非仮想区画の論理ブロック[3/8.8.1]の空間を使って記録される。仮想セクタを，セクタ[1/5.9]又は論理セクタ[3/8.1.2]と混同しないほうがよい。

1.3.2.27 VAT (Virtual Allocation Table) 非仮想区画の空間に記録されるファイル[4/8.8]のことで，対応する仮想区画をもち，そのデータ空間[4/8.8.2]は本規定の2.2.10に従って構成される。このファイルではUint32sの配列リストを備えているが，Nth Uint32は，対応する仮想区画の論理ブロック番号Nを記録するのに使う，非仮想区画の論理ブロック番号[3/8.8.1]を表す。このファイル[4/8.8]は，論理ボリューム[3/8.8]のファイル集合 [4/8.5]におけるディレクトリ[4/8.6]のファイル識別記述子[4/14.4]で，必ずしも参照されるわけではない。

1.3.2.28 VAT ICB (Virtual Allocation Table ICB) VATを含むファイルを記述する，ファイルエントリICB。

1.3.3 用語遣い

1.3.3.1 してよい (May) オプションの行為又は機能を示す。

1.3.3.2 オプションの (Optional) 実装しても，しなくてもよい機能を示す。実装する場合，その機能は規定どおりに実装しなければならない。

1.3.3.3 でなければならない (Shall) 必須であってこの標準情報(TR)に適合していることを主張するために実装しなければならない行為又は機能を示す。

1.3.3.4 望ましい (Should) オプションではあるが，その実装が強く推奨される行為又は機能を示す。

1.3.3.5 予備の (Reserved) 予備欄は，将来の使用のために確保され，ZEROに設定しなければならない。予備の値は, 将来の使用のために確保され，使用してはならない。

2. 基本制約及び基本要件

次の表2.1は，この標準情報(TR)が定義する基本制約及び基本要件のいくつかを要約している。これらの制約及び要件は，追加の制約及び要件とともに，この標準情報(TR)の以降の節で詳細に記述する。

表2.1 基本制約及び基本要件

項目	制約及び要件
論理セクタ長	特定のボリュームに関する論理セクタ長は，この特定のボリュームの物理セクタ長と同じとする。
論理ブロック長	論理ボリュームに関する論理ブロック長は，この特定の論理ボリュームが存在するボリューム又はボリューム集合の論理セクタ長に設定しなければならない。
ボリューム集合	同一ボリューム集合中のすべての媒体は，同じ物理セクタ長をもつものとする。書換形/上書き可能形の媒体及び追記形の媒体は，同一ボリューム集合に混在してはならない｡
ボリューム空間の最初の32Kバイト	ボリューム空間の最初の32768バイトは，JIS X 0607の構造の記録に使用してはならない。この領域は，未割付け空間記述子又は他のいかなるJIS X 0607の記述子も参照してはならない。この領域は，元のオペレーティングシステムでの自由使用に任されている。
ボリューム認識列	JIS X 0607の第2部の規定に従ってボリューム認識列を記録しなければならない。
日時表示	すべての日時表示は，現地時で記録しなければならない。時間帯は，時間帯の概念をサポートするオペレーティングシステムに従って記録しなければならない。
実体識別子	実体識別子は，この標準情報(TR)に従って記録しなければならない。この規定で特記しない限り，実体識別子は，処理システムを一意に識別する値を含まなければならない。
記述子CRC	CRCは，空間ビットマップ記述子を除くすべての記述子に関して, 利用可能で，計算されなければならない。
ファイル名の長さ	最大255バイトとする。
パス長	最大1023バイトとする。
エクステント長	最大エクステント長は，[230-(論理ブロック長)]バイトとする。仮想区画における最大エクステント長は論理ブロックサイズとする。
基本ボリューム記述子	ボリュームごとにただ一つの最新の基本ボリューム記述子を記録しなければならない。
開始ボリューム記述子ポインタ	ボリュームの最大セクタ番号をNとするとき，256, N-256又はNの3位置の少なくとも2箇所に記録しなければならない。
区画記述子	再生専用形，書換形/上書き可能形及び追記形の区画アクセス種別を利用可能とする。次に示す一つの例外を除き，ボリュームごとにただ一つの種別1の最新の区画記述子を記録しなければならない。単一ボリュームで構成するボリューム集合において，一つの区画が再生専用のアクセス種別をもち，他区画が書換形/上書き可能形のアクセス種別をもつ場合だけ，ボリュームは二つの最新の区画記述子とともに，二つの区画を含んでもよい。このボリュームの論理ボリュームは，両方の区画の内容で構成する。
論理ボリューム記述子	ボリューム集合ごとにただ一つの最新のボリューム記述子を記録する。 論理ボリューム識別子欄は，空にしてはならず，論理ボリュームの識別のための識別子を含むことが望ましい。特に，この規定に適合するボリュームを作成するソフトウェアは，この欄に固定の値又は無意味な値を設定してはならない。同一であることを意図する重複ディスクは，この欄が同一の値でもよい。この欄は，ジュークボックス中に複数の媒体が存在するときの，論理ボリュームの識別のために，特に重要となる。この名前は，典型的には，利用者に表示するものとする。
論理ボリューム保全記述子	記録しなければならない。LVIDのエクステントは，エクステント長で終了してもよい。
未割付け空間記述子	ボリュームごとに一つだけの最新の未割付け空間記述子を記録する。
ファイル集合記述子	書換形/上書き可能形の媒体中の論理ボリュームごとに一つだけのファイル集合記述子を記録する。追記形の媒体においては，この標準情報(TR)で定義する制約に従って複数のファイル集合記述子を記録してもよい。ファイル集合記述子のファイル集合識別子欄は，利用者に対して論理ボリュームを識別するために，別名として使用できる名前を使用してもよい。詳細は，2.3.2.7を参照。FSDエクステントは，エクステント長で終了してもよい。
ICBタグ	方策種別4又は方策種別4096だけを記録しなければならない｡
ファイル識別記述子	ファイル識別記述子の長さの合計は，一つの論理ブロック長を超えてはならない。
ファイルエントリ	ファイルエントリの長さの合計は，一つの論理ブロック長を超えてはならない。
割付け記述子	短割付け記述子及び長割付け記述子だけを記録できる。
割付けエクステント記述子	一つの割付けエクステントの長さは，論理ブロック長を超えてはならない。
未割付け空間エントリ	未割付け空間エントリの長さの合計は，論理ブロック長を超えてはならない。
空間ビットマップ記述子	CRCは必要でない。
区画保全エントリ	記録してはならない。
ボリューム記述列エクステント	主ボリューム記述子列エクステント及び予備ボリューム記述子列エクステントの両方とも，最小長16個の論理セクタで構成しなければならない。VDSエクステントはエクステント長で終了してもよい。
レコード構造	JIS X 0607の第5部で定義するレコード構造ファイルは, 作成してはならない。

2.1 第1部 一般

 参考 この規定における第n部(n=1〜5)の表記は, JIS X 0607の第n部の規定内容への対応を示す。

2.1.1 文字集合

この標準情報(TR)で定義する構造に関して，UDFで使用する文字集合は，CS0文字集合とする。OSTAのCS0文字集合は，表2.2に定義する。

OSTAのCS0は，#FEFF及びFFFEを除く, Unicode Standard Version 2.0 (Addison-Wesley Publishing Company, http://www.aw.com/devpressのISBN 0-201-48345-9，http://www.unicode.orgも参照されたい。)が規定するd文字から成り，次に定義するOSTA圧縮Unicodeフォーマットで記録される。

表2.2 OSTA圧縮Unicodeフォーマット

備考 ??は可変長欄を示す。

RBP	長さ	名前	内容
0	1	圧縮識別子	Uint8
1	??	圧縮ビット列	バイト

圧縮識別子は，圧縮ビット列欄の圧縮に使用する圧縮アルゴリズムを識別する。表2.3に示すアルゴリズムが, 現在利用できる。

表2.3 圧縮アルゴリズム

値	意味
0〜7	予備
8	圧縮ビット列中の1文字が8ビットであることを示す。
9〜15	予備
16	圧縮ビット列中の1文字が16ビットであることを示す。
17〜253	予備
254	一意の4バイト2進数が続くことを示す。
255	一意の8バイト2進数が続くことを示す。

圧縮識別子の値が8又は16のとき，その値は，圧縮ビット列欄で定義するd文字のビット数を規定しなければならない。圧縮ビット列欄中の圧縮識別子のビット数の各列は，OSTA圧縮Unicodeのd文字を表さなければならない。符号化される文字のビットは，最上位ビットから最下位ビットまで，圧縮ビット列に加える。符号化される文字のビットは，符号化先の着目しているバイトの最上位ビットの位置から圧縮ビット列に加えていかなければならない。

 備考 この符号化によって，16の圧縮識別子で書込まれた文字は，ビッグエンディアンフォーマットで効率的に書き込まれる。

Uint16として解釈されるOSTA圧縮Unicodeのd文字の値は，Unicode 2.0の規定の対応するd文字の値を定義する。OSTA圧縮Unicode及びUnicode 2.0を変換するCのソースコードの例については，OSTA圧縮Unicodeに関する附属書を参照されたい。

Unicodeのバイト順マーク#FEFF及び#FFFEは，使用してはならない。

254又は255の圧縮識別子は，後に続く4又は8バイトがそれぞれ，状況に対して一意の2進数値を含むことを示さなければならない。例えば，ファイル識別子は，削除ビットが設定される場合，一意のディレクトリエントリを作成するため，ディレクトリ内の254又は255の圧縮識別子と，ファイル識別子のバイトのオフセットを使ってもよい。

2.1.2 OSTA CS0文字集合

  struct Charspec{  /*ECMA 167 1/7.2.1*/
         Uint8 CharacterSetType;
         byte  CharacterSetInfo[63];
  }

文字集合の種別(CharacterSetType)欄は，CS0符号化文字集合を示す値0を指定する。

文字集合情報(CharacterSetInf)欄は，次に示すバイト値を設定し，欄の残りバイトは0に設定する。

#4F,#53,#54,#41,#20,#43,#6F,#6D,#70,#72,#65,#73,#73,#65,#64,#20,#55,#6E,#69,#63,#6F,#64,#65

このバイト値は，次に示すASCII列を表す。

"OSTA Compressed Unicode"

2.1.3 Dストリング(dstring)

この標準情報(TR)と同様に，JIS X 0607は，通常は相対バイト位置を0から定義する。JIS X 0607の7.2.12では，dstringは相対位置を1から定義している。これは混乱を招くことがあるので，次に相対位置を0から定義する場合を示す。

7.2.12 固定長文字欄

長さnのdstringは，d文字(1/7.2参照)を記録するnバイトの欄とする。文字の記録に使用するバイトの数は，バイトn-1にUint8(1/7.1.1参照)で記録する。ここで，nはこの欄の長さとする。文字は欄の先頭バイトから記録し，記録した文字の後からバイトn-2までのバイト位置に，すべて#00を設定する。

符号化するd文字の数が0の場合，dstringの長さは0とする。

 備考 長さ0の列の場合を除いて，dstringの長さは圧縮識別子(2.1.1)を含む。長さ0の列は，dstring欄にすべて0を設定することによって記録する。

2.1.4 日時表示(Timestamp)

  struct timestamp{  /*ECMA 1671/7.3*/
         Uint16     TypeAndTimezone;
         Uint16     Year;
         Uint8      Month;
         Uint8      Day;
         Uint8      Hour;
         Uint8      Minute;
         Uint8      Second;
         Uint8      Centiseconds;
         Uint8      HundredsofMicroseconds;
         Uint8      Microseconds;
  }

2.1.4.1 種別及び時間帯(Uint16 TypeAndTimezone)

次の記述において，種別は，この欄の最上位4ビットを示し，時間帯は，この欄の最下位12ビットを示す。

• a) 意味 この構造の時刻は，現地時として解釈する。OSTA UDF適合媒体では，種別は1とする。
• b) 設定値 種別は，現地時を示す1を設定する。

• a) 意味 この欄を最後に更新したときの現地の時間帯を指定していると解釈する。この欄が値(-2047)の場合には，時間帯を指定していない。
• b) 設定値 時間帯の概念が利用可能なオペレーティングシステムは，協定世界時からの時間帯の差(1分ごと)をこの欄に指定する。それ以外は，この欄の時間帯部分には，値(-2047)を設定する。

 備考 協定世界時の時間帯西は, 負の時間差をもつ。例えば，東標準時は-300分であり，東の夏時間は-240分とする。

2.1.5 実体識別子(Entity Identifier)

  struct EntityID{ /*　ECMA 167 1/7.4 */
         Uint8     Flags;
         char      Identifier[23];
         char      IdentifierSuffix[8];
  }

UDFは，実体識別子を次に示す三つの種別に分類する。

• a) 範囲(実体)識別子
• b) UDF(実体)識別子
• c) 処理システム(実体)識別子

以降の節で，これらの異なる種別に基づいて実体識別子のフォーマット及び使用方法を示す。

2.1.5.1 フラグ(Uint18 Flags)

• a) 意味 定義済み。
• b) 設定値 ZEROを設定する。

2.1.5.2 識別子(char Identifier)

この標準情報(TR)では，特記しない限り，この欄には，処理システムを一意に識別する識別子を設定しなければならない。この方法は，異なる処理システム間で交換する媒体中に記録した構造が，どの処理システムによるものかの識別を可能にする。

処理システムが，他の処理システムで書き込んだ媒体中に存在する構造を更新する場合，現状の処理システムは，現状の処理システムを一意に識別する値を識別子欄に設定しなければならない。

表2.4は，JIS X 0607及びこの標準情報(TR)で定義する実体識別子欄を要約したものであり，設定しなければならない値を示す。

表2.4 実体識別子

備考1 N/Aは, "規定しない"ことを示す。

備考2 実体識別子欄の値は，バイトの列として解釈し，CS0で規定するd文字列としては解釈しない。UDFで容易に使用するために，この欄で使用する値は，ASCII文字列で規定する。UDFで定義する実体識別子で使用するバイト列は，附属書で規定する。

記述子	欄	識別子値	添字種別
基本ボリューム記述子	処理システム識別子	"*Developer ID"	処理システム識別子添字
処理システム用 ボリューム記述子	処理システム識別子	"*Developer ID"	処理システム識別子添字
処理システム用 ボリューム記述子	UDF識別子	*UDF LV Info	UDF識別子添字
区画記述子	処理システム識別子	"*Developer ID"	処理システム識別子添字
論理ボリューム記述子	処理システム識別子	"*Developer ID"	処理システム識別子添字
論理ボリューム記述子	範囲識別子	"*OSTA UDF Compliant"	範囲識別子添字
ファイル集合記述子	範囲識別子	"*OSTA UDF Compliant"	範囲識別子添字
ファイル識別記述子	処理システム識別子	"*Developer ID"	処理システム識別子添字 (オプション)
ファイルエントリ	処理システム識別子	"*Developer ID"	処理システム識別子添字
UDF拡張属性	UDF識別子	附属書参照	UDF識別子添字
非UDF拡張属性	処理システム識別子	"*Developer ID"	処理システム識別子添字
装置仕様拡張属性	処理システム識別子	"*Developer ID"	処理システム識別子添字
論理ボリューム保全記述子	処理システム識別子	"*Developer ID"	処理システム識別子添字
区画保全エントリ	処理システム識別子	N/A	N/A
仮想区画マップ	区画種別識別子	*UDF Virtual Partition	UDF識別子添字
予備区画マップ	区画種別識別子	*UDF Sparable Partition	UDF識別子添字
仮想割付け表	実体識別子	*UDF Virtual Alloc Tbl	UDF識別子添字
予備表	予備識別子	*UDF Sparing Table	UDF識別子添字

実体識別子の表の識別子値欄で示した"*Developer ID"は，現状の処理システムを一意に識別する実体識別子を示す。規定した値は，新しい記述子を作成するときに使用しなければならない。規定した値は，規定した実体識別子欄の適用範囲内で何かを更新するときに，存在する記述子にも使用しなければならない。

 備考 "*Developer ID"のために選択された値は，処理システムに関する社名及び製品名を識別できるだけの情報を含むことが望ましい。例えば，DataOneというUDF製品をもつXYZという会社は，Developer IDとして"*XYZ Data One"を選択してよい。Developer IDの添字においても，DataOne製品の現在の版数を記録することを選択してよい。この情報は，異なる会社の複数の製品がメディアに記録していた場合，どの処理システムがメディアの一部に不適切な構造を書き込んだのかを決定する際，非常に助けになる。

実体識別子の表の添字種別欄は，相当する実体識別子で使用する添字のフォーマットを定義する。これらの異なる添字種別は，次の節で定義する。

 備考 この標準情報(TR)(附属書6.1)で定義するすべての識別子は，UDF識別子としてOSTAが登録しなければならない。

2.1.5.3 識別子添字(IdentifierSuffix)

識別子欄のフォーマットは，識別子の種別に依存する。

この標準情報(TR)(附属書6.1)で規定するOSTA範囲実体識別子に関しては，識別子添字欄を次に示す構成とする。

表2.5 範囲識別子添字欄フォーマット

RBP	長さ	名前	内容
0	2	UDF版数	Uint16(=#0200)
2	1	範囲フラグ	Uint8
3	5	予備	バイト(=#00)

UDF版数欄は，この標準情報(TR)の版数2.00を示す値#0200を設定する。この欄は，この標準情報(TR)の改訂版に加えられた変更を，処理システムが検出することを可能にする。OSTA範囲識別子は，論理ボリューム記述子及びファイル集合記述子だけに使用する。範囲フラグ欄は，次に示すビットフラグを定義する。

表2.6 範囲フラグ

RBP	意味
0	ハード書込み保護
1	ソフト書込み保護
2〜7	予備

ソフト書込み保護フラグは，利用者が設定可能なフラグであり，このフラグが存在する記述子の適用範囲で，ボリューム構造又はファイルシステム構造が書込み保護されていることを示す。ソフト書込み保護フラグの値がONEの場合，利用者の書込み保護を示さなければならない。このフラグは，利用者が設定及び解除してもよい。ハード書込み保護フラグは，処理システムが設定可能なフラグであり，このフラグが存在する記述子の適用範囲で永久的な書込み保護を示さなければならない。ハード書込み保護フラグの値がONEの場合，永久的な書込み保護を示さなければならない。このフラグは，一度設定した場合解除してはならない。ハード書込み保護フラグは，ソフト書込み保護フラグに優先する。

書込み保護フラグは，論理ボリューム記述子及びファイル集合記述子の中に現れる。それらは次のとおりに解釈しなければならない。

is_fileset_write_protected=LVD.HardWriteProtect||LVD.SoftWriteProtect||
     FSD.HardWriteProtect||FSD.SoftWriteProtect
is_fileset_hard_protected=LVD.HardWriteProtect||FSD.HardWriteProtect
is_fileset_soft_protected=(LVD.SoftWriteProtect||FSD.SoftWriteProtect)&&
     (!is_vol_hard_protected)
is_vol_write_protected=LVD.HardWriteProtect||LVD.SoftWriteProtect
is_vol_hard_protected=LVD.HardWriteProtect
is_vol_soft_protected=LVD.SoftWriteProtect&&!LVD.HardWriteProtect

UDF(附属書6.1)で定義する処理システム用実体識別子に対しては，識別子添字欄は，次にに示す構成とする。

表2.7 UDF識別子添字

RBP	長さ	名前	内容
0	2	UDF版数	Uint16(=#0200)
2	1	オペレーティングシステムクラス	Uint8
3	1	オペレーティングシステム識別子	Uint8
4	4	予備	バイト(=#00)

オペレーティングシステムクラス及びオペレーティングシステム識別子欄の内容は，オペレーティングシステム識別子に関する附属書に記述する。

UDFで定義しない実体識別子を使用する処理システムに関して，識別子添字欄は，表2.8に示す構成とする。

表2.8 処理システム識別子添字

RBP	長さ	名前	内容
0	1	オペレーティングシステムクラス	Uint8
1	1	オペレーティングシステム識別子	Uint8
2	6	処理システム用領域	バイト

 備考 オペレーティングシステムクラス欄及びオペレーティングシステム識別子欄の意図した使用並びに重要性を理解することが重要になる。これらの欄の主な目的は，UDFボリューム中で問題を検出したときに，誤りを取り除く支援をすることとする。この欄は，利用者に提供可能な有効な情報も提供する。これらの二つの欄を正しく設定した場合，処理システムに次の情報を提供する。

• a) 最後に特定の構造を更新したオペレーティングシステムを識別する。
• b) 最後に特定のファイル又はディレクトリを更新したオペレーティングシステムを識別する。
• c) 開発者が処理システムとともに複数オペレーティングシステムを提供する場合，問題が発生したオペレーティングシステムを決定する支援をする。

2.2 第3部 ボリューム構造

2.2.1 記述子タグ(Descriptor Tag)

  struct tag{        /* ECMA 167 3/7.2 */
  　     Uint16      TagIdentifier;
    　   Uint16      DescriptorVersion;
         Uint8       TagChecksum;
         byte        Reserved;
         Uint16      TagSerialNumber;
         Uint16      DescriptorCRC;
         Uint16      DescriptorCRCLength;
         Uint32      TagLocation;
  }

2.2.1.1 タグ通し番号(Uint16 TagSerialNumber)

• a) 意味 無視する。障害回復を意図する。
• b) 設定値 ボリュームの初期化時に，一意の値に再設定する。

タグ通し番号は，ボリュームの再初期化時には，以前に記録した値と異なる値を設定しなければならない。タグ通し番号=((基本ボリューム記述子のタグ通し番号)+1)であることを推奨する。

2.2.1.2 記述子CRC長(Uint16 DescriptorCRCLength)

CRCは，各記述子で利用可能であり，計算されなければならない。この欄の値は，(記述子の大きさ)−(記述子タグの長さ)を設定しなければならない。記述子を読み出すときは，CRCを検証するのが望ましい。

2.2.1.3 タグの位置(Uint32 TagLocation)

仮想番地でアクセスする(即ちVATでアクセスする)構造では，この値は，仮想番地であり，物理番地又は論理番地ではない。

2.2.2 基本ボリューム記述子(Primary Volume Descriptor)

  struct PrimaryVolumeDescriptor{/* ECMA 167 3/10.1 */
         struct tag       DescriptorTag;
         Uint32           VolumeDescriptorSequenceNumber;
         Uint32           PrimaryVolumeDescriptorNumber;
         dstring          VolumeIdentfier[32];
         Uint16           VolumeSequenceNumber;
         Uint16           MaximumVolumeSequenceNumber;
         Uint16           InterchangeLevel;
         Uint16           MaximumInterchangeLevel;
         Uint32           CharacterSetList;
         Uint32           MaximumCharacterSetList;
         dstring          VolumeSetIdentifier[128];
         struct charspec  DescriptorCharacterSet;
         struct charspec  ExplanatoryCharacterSet;
         struct extent_ad VolumeAbstract;
         struct extent_ad VolumeCopyrightNotice;
         struct EntityID  ApplicationIdentifier;
         struct timestamp RecordingDateandTime;
         struct EntityID  ImplementationIdentifier;
         byte             ImplementationUse[64];
         Uint32           PredecessorVolumeDescriptorSequenceLocation;
         Uint16           Flags;
         byte             Reserved[22];
  }

2.2.2.1 交換水準(Uint16 InterchangeLevel)

• a) 意味 関連するボリュームの内容の現状の交換水準(JIS X 0607の3/11で規定)及び規定水準が意味する制限についての指定と解釈する。
• b) 設定値 このボリュームが複数ボリュームから成るボリューム集合に属する場合，この水準は値3を設定し，それ以外の場合は，値2を設定しなければならない。

JIS X 0607は，規定する現状の交換水準に関連する制限の実施を処理システムに要求する。処理システムは，交換最大水準欄の値を超えない限り，この欄の値を変更してもよい。

2.2.2.2 最大交換水準(Uint16 MaximumInterchangeLevel)

• a) 意味 関連するボリュームの内容についての交換最大水準(JIS X 0607の3/11で規定)の指定と解釈する。
• b) 設定値 利用者が特別に異なる値を与えない限り，この欄は水準3(制限なし)を設定しなければならない。

 備考 この欄は，ボリューム作成者の意図の指定に使用する。この欄が値2の場合，作成者の意図は, このボリュームが複数ボリュームから成るボリューム集合(交換水準3)に属さないこととする。受領者は，この欄を無視して値3を設定してもよいが，その場合には，処理システムはボリューム作成者の意図を示す警告を受領者に与えることが望ましい。

2.2.2.3 文字集合リスト(Uint32 CharacterSetList)

• a) 意味 JIS X 0607(3/10.1.9)の第3部で定義する構造で使用する文字集合の指定と解釈する。
• b) 設定値 2.1.2で定義するCS0だけを利用可能とする設定をしなければならない。

2.2.2.4 文字最大集合リスト(Uint32 MaximumCharacterSetList)

• a) 意味 文字集合リスト欄で指定してもよい利用可能な文字集合(JIS X 0607で規定)の最大値の指定と解釈する。
• b) 設定値 2.1.2で定義するCS0だけを利用可能とする設定をしなければならない。

2.2.2.5 ボリューム集合識別子(dstring VolumeSetIdentifier)

• a) 意味 ボリューム集合の識別子の指定と解釈する。
• b) 設定値 この欄の最初の16文字は，一意の値に設定するのが望ましい。この欄の残りは，使用可能な任意の値を設定してもよい。特に，この規定に従ってボリューム構造を生成するソフトウエアは，この欄に，固定値又は無意味な値を設定してはならない。同一であることを意図された複製ディスクは，この欄に同じ値を入れてもよい。

   備考 ここで意図する目的は，一意の識別子をもつボリューム集合の保証にある。この欄の最初の16文字において，最初の8文字は，32ビットの日時の値のCS0による16進表示とするのが望ましく，残りの8文字は，処理システム用に任されている。

2.2.2.6 記述子文字集合(struct charspec DescriptorCharacterSet)

• a) 意味 ボリューム識別子欄及びボリューム集合識別子欄で使用可能な文字集合の指定と解釈する。
• b) 設定値 2.1.2で定義するCS0を利用可能とする設定をしなければならない。

2.2.2.7 説明用文字集合(struct charspec ExplantoryCharacterSet)

• a) 意味 ボリューム抄録及びボリューム著作権通知エクステントの内容の解釈に使用する文字集合の指定と解釈する。
• b) 設定値 2.1.2で定義するCS0を利用可能とする設定をしなければならない。

2.2.2.8 処理システム識別子(struct EntityID ImplementationIdentifier)

この欄の適切な扱いに関する詳細情報は，2.1.5を参照のこと。

2.2.3 開始ボリューム記述子ポインタ(Anchor Volume Descriptor Pointer)

  struct AnchorVolumeDescriptorPointer{ /* ECMA 1673/10.2 */
         struct tag            DescriptorTag;
         struct extent_ad      MainVolumeDescriptorSequenceExtent;
         struct extent_ad      ReserveVolumeDescriptorSequenceExtent;
         byte                  Reserved[480];
  }

 備考1 開始ボリューム記述子ポインタ構造は，媒体中の次に示す三つの位置のうち，最低2箇所に記録する。

• 論理セクタ 256
• 論理セクタ (N-256)
• 論理セクタ N

 備考2 閉じていないCD-R媒体では，セクタ512だけに開始ボリューム記述子ポインタが記録されてもよい。閉じる際，CD-R媒体はこれらの規則に従う。

2.2.3.1 主ボリューム記述子列エクステント(struct MainVolumeDescriptorSequenceExtent)

主ボリューム記述子列エクステントは，最小長16論理セクタとする。

2.2.3.2 予備ボリューム記述子列エクステント(struct ReserveVolumeDescriptorSequenceExtent)

予備ボリューム記述子列エクステントは，最小長16論理セクタとする。

2.2.4 論理ボリューム記述子(Logical Volume Descriptor)

  struct LogicalVolumeDescriptor{ /* ECMA 167 3/10.6 */
         struct tag            DescriptorTag;
         Uint32                VolumeDescriptorSequenceNumber;
         struct charspec       DescriptorCharacterSet;
         dstring               LogicalVolumeIdentifier[128];
         Uint32                LogicalBlockSize;
         struct EntityID       DomainIdentifier;
         byte                  LogicalVolumeContentsUse[16];
         Uint32                MapTableLength;
         Uint32                NumberofPartitionMaps;
         struct EntityID       ImplementationIdentifier;
         byte                  ImplementationUse[128];
         extent_ad             IntegritySequenceExtent;
         byte                  PartitionMaps[];
  }

2.2.4.1 記述子用文字集合(struct charspec DescriptorCharacterSet)

• a) 意味 論理ボリューム識別子欄で使用可能な文字集合の指定と解釈する。
• b) 設定値 2.1.2で定義するCS0を利用可能とする設定をする。

2.2.4.2 論理ブロック長(Uint32 LogicalBlockSize)

• a) 意味 この論理ボリューム記述子で識別する論理ボリュームの論理ブロック長の指定と解釈する。
• b) 設定値 この欄は，論理ボリューム記述子で識別する論理ボリュームを構成する媒体中のすべての区画のうち，最大の論理セクタ長を設定しなければならない。UDFでは，ボリューム集合中のすべてのボリュームが同一論理セクタ長であることを要求するため，論理ブロック長は，ボリュームの論理セクタ長に等しい。

2.2.4.3 範囲識別子(struct EntityID DomainIdentifier)

• a) 意味 記述子中の欄の使用規則及び制限を規定する範囲の指定と解釈する。この欄のすべてが0の場合，無視する。それ以外の場合は，実体識別子規則に従う。

   備考 この欄の内容が"*OSTA UDF Compliant"でない場合，処理システムは論理ボリュームに対する利用者からのアクセスを拒否してもよい。

• b) 設定値 この欄は，この標準情報(TR)で定義する範囲に適合する論理ボリュームの内容であることを示す。したがって，この範囲識別子は，

  "*OSTA UDF Compliant"

  に指定しなければならない。

  実体識別子の節で記述したとおり，実体識別子の識別子添字欄には，論理ボリュームの内容が互換性をもつこの標準情報(TR)の版数を含む。この欄の適切な扱いに関する詳細情報は，2.1.5を参照のこと。

   備考 実体識別子の識別子添字欄は，ソフト書込み保護フラグ及びハード書込み保護フラグを含む。2.1.4.3を参照のこと。

2.2.4.4 論理ボリューム内容用[16](byte LogicalVolumeContentUse[16])

この欄には，ファイル集合記述子のエクステント位置が含まれる。これは，JIS X 0607の4/3.1に次のとおりに規定される。

ボリュームが"エラー！参照元見つからず"に従って記録される場合，論理ボリュームの最初のファイル集合記述子列が記録されるエクステントは，long_ad(エラー！参照元見つからず｡/エラー！参照元見つからず｡)で識別される。このlong_adは，ファイル集合記述子を記録する論理ボリュームを記述する論理ボリューム記述子の論理ボリューム内容用欄(エラー！参照元見つからず｡/エラー！参照元見つからず，を参照)に記録されている。

この欄は，ファイル集合記述子を見つけるのに使用でき，ファイル集合記述からルートボリュームを見つけることができる。

2.2.4.5 処理システム識別子(struct EntityID ImplementationIdentifier)

この欄の適切な扱いに関する詳細情報は，実体識別子の節を参照のこと。

2.2.4.6 保全列エクステント(struct extent_ad IntegritySequenceExtent)

この欄の値は，論理ボリューム保全記述子のために必要となる。書換形/上書き可能形媒体に関しては，最小値8Kバイトを設定しなければならない。

 備考 追記形媒体に対しては，この欄は，十分な長さのエクステントを設定するのが望ましい。論理ボリューム保全記述子は，最新論理ボリューム記述子と同一のボリュームに存在しなければならないため，論理ボリューム保全記述子が存在する追記形媒体が一杯になった場合は，ボリューム集合に新しいボリュームを追加しなければならない。

2.2.4.7 区画マップ(byte PartitionMaps)

交換の目的として，区画マップは，この標準情報(TR)(2.2.8及び2.2.9)に記述されているとおり, 種別2を除き，区画マップ種別1に限定しなければならない。

2.2.5 未割付け空間記述子(Unallocated Space Descriptor)

  struct UnallocatedSpaceDesc{ /* ECMA 167 3/10.8 */
         struct tag      DescriptorTag;
         Uint32          VolumeDescriptorSequenceNumber;
         Uint32          NumberofAllocationDescriptors;
         exted_ad        AllocationDescriptors[];
  }

使用可能なボリューム空間がない場合でも，この記述子を記録しなければならない。

2.2.6 論理ボリューム保全記述子(Logical Volume Integrity Descriptor)

  struct LogicalVolumeIntegrityDesc{ /* ECMA 167 3/10.10 */
         struct tag        DescriptorTag;
         Timestamp         RecordingDateAndTime;
         Uint32            IntegrityType;
         struct extend_ad  NextIntegrityExtent;
         byte              LogicalVolumeContentsUse[32];
         Uint32            NumberOfPartitions;
         Uint32            LengthOfImplementationUse;
         Uint32            FreeSpaceTable[];
         Uint32            SizeTable[];
         byte              ImplementationUse[];
  }

論理ボリューム保全記述子は，関連する論理ボリュームの内容を更新したときに書き込む構造とする。論理ボリューム保全記述子の内容によって，処理システムは次に示す有用な問いに対し容易に回答できる。

• a) 論理ボリュームの内容は，一貫性のある状態か否か
• b) 論理ボリュームを更新した最終日時
• c) 論理ボリューム中の使用可能空間の論理ブロック総数
• d) 論理ボリューム中の論理ブロック総数
• e) 論理ボリューム中で次に使用可能な一意ID
• f) 論理ボリュームを作成した作成処理システムが最後にアクセスした日時以降に論理ボリューム中の内容を更新したほかの処理システムの有無。

2.2.6.1 論理ボリューム内容用(byte LogicalVolumeContensUse)

この欄の内容の情報に関しては，論理ボリュームヘッダ記述子の節を参照のこと。

2.2.6.2 利用可能空間表(Uint32 FreeSpaceTable)

ほとんどのオペレーティングシステムは，媒体のマウント時に，処理システムが論理ボリューム中の利用可能空間の大きさを提供することを要求するため，これらの値をすべての非仮想区画のために保守することは重要となる。有効な利用可能空間の量が不明なことを示す#FFFFFFFFのオプション値は，非仮想区画に使用してはならない。仮想区画については，利用可能空間表を#FFFFFFFFに設定しなければならない。

 備考 論理ボリューム保全記述子をクローズ状態にしたときだけ，正しい利用可能空間表を保証する。

2.2.6.3 サイズ表(Uint32 SizeTable)

ほとんどのオペレーティングシステムは，媒体のマウント時に，処理システムが論理ボリュームの大きさを提供することを要求するため，これらの値をすべての非仮想区画に保守することは重要となる。区画長が不明なことを示す#FFFFFFFFのオプション値は仮想区画に使用してはならない。仮想区画については，サイズ表を#FFFFFFFFに設定しなければならない。

2.2.6.4 処理システム用(byte ImplementationUse)

論理ボリューム保全記述子の処理システム用領域は，表2.9に示す構成とする。

表2.9 処理システム用フォーマット

RBP	長さ	名前	内容
0	32	処理システム識別子	EntityID
32	4	ファイル数	Uint32
36	4	ディレクトリ数	Uint32
40	2	UDF読出し最小版数	Uint16
42	2	UDF書込み最小版数	Uint16
44	2	UDF書込み最大版数	Uint16
46	??	処理システム用	バイト

a) 処理システム識別子 処理システム識別子は，実体識別子の範囲内のどれかを最後に更新した処理システムの実体識別子。実体識別子の適用範囲は，論理ボリューム識別子及び関連する論理ボリュームの内容とする。この欄は，論理ボリュームの内容を最後に更新した処理システムの識別を処理システムに許可する。

b) ファイル数 関連する論理ボリューム中の現状のファイルの個数。この情報は，Macintoshオペレーティングシステムで必要となる。すべての処理システムは，この情報を保守する。

 備考 この値は，拡張属性をファイル数に含まない。

c) ディレクトリ数 関連する論理ボリューム中の現状のディレクトリの個数。この情報は，Macintoshオペレーティングシステムで必要となる。すべての処理システムは，この情報を保守する。

 備考 ルートディレクトリは，ディレクトリ数に含まれるとする。ディレクトリ数には，ストリームディレクトリが含まれない。

d) UDF読出し最小版数 この媒体中のすべての構造を読み出すために，処理システムが利用可能とする必要があるUDF版数の最小値を示すものとする。この番号は，10進数の2進表示で記録しなければならない。例えば，#0150はUDF 1.50を示す。

e) UDF書込み最小版数 この媒体中のすべての構造を更新するために，処理システムが利用可能とする必要があるUDF版数の最小値を示すものとする。この番号は，10進数の2進表示で記録しなければならない。例えば，#0150はUDF 1.50を示す。

f) UDF書込み最大版数 媒体中を更新した処理システムが利用可能とするUDF版数の最大値を示すものとする。処理システムは，媒体の更新により，媒体がこの欄の現状の値より大きいUDF版数を必要とするようになった場合だけ，この欄を更新しなければならない。この番号は，10進数の2進表示で記録しなければならない。例えば，#0150はUDF 1.50を示す。

g) 処理システム用 処理システム識別子で識別する処理システムだけの固有情報を含む。

2.2.7 処理システム用ボリューム記述子(Implementation Use Volume Descriptor)

  struct ImpUseVolumeDescriptor{ /*ECMA 167 3/10.4*/
         struct tag            DescriptorTag;
         Uint32                VolumeDescriptorSequenceNumber;
         struct EntityID       ImplementationIdentifier;
         byte                  ImplementationUse[460];
  }

この節は，UDF処理システム用ボリューム記述子を定義する。この記述子はボリューム集合のすべてのボリュームに記録しなければならない。ボリュームは，処理システム固有の追加の処理システム用ボリューム記述子を含んでもよい。この記述子の意図する目的は，特定の論理ボリュームに属するボリューム集合中のボリュームの識別を支援することとする。

 備考 処理システムは，媒体中にそれ自体のフォーマットにおける追加の処理システム用ボリューム記述子を記録してもよい。UDF処理システム用ボリューム記述子は，追加の記述子を除外しない。

2.2.7.1 処理システム識別子(EntityID ImplementationIdentifier)

この欄は"*UDF LV Info"を指定するものとする。

2.2.7.2 処理システム用(byte ImplementationUse)

処理システム用領域は，次に示す構造とする。

  struct LVInformation{
         struct charspec     LVICharset;
         dstring             LogicalVolumeIdentifier[128];
         dstring             LVInfo1[36];
         dstring             LVInfo2[36];
         dstring             LVInfo3[36];
         struct EntityID     ImplementationID;
         byte                ImplementationUse[128];
  }

2.2.7.2.1 論理ボリューム情報用文字集合(charspec LVICharset)

• a) 意味 論理ボリューム識別子欄及び論理ボリューム情報欄で使用可能な文字集合の指定と解釈する。
• b) 設定値 2.1.2で定義するCS0だけを利用可能とする設定をしなければならない。

2.2.7.2.2 論理ボリューム識別子(dstring LogicalVolumeIdentifier)

この記述子で参照する論理ボリュームの識別子。

2.2.7.2.3 論理ボリューム情報(dstring LVInfo)

論理ボリューム情報欄(LVInfo1，LVInfo2，LVInfo3)は，媒体の識別を支援する追加情報を含むのが望ましい。例えば，論理ボリューム情報欄は，所有者名，組織名及び連絡先の情報を含むことができる。

2.2.7.2.4 処理システム識別子(struct EntityID ImplementionID)

実体識別子の節を参照のこと。

2.2.7.2.5 処理システム用(byte ImplementationUse[128])

この領域は，追加の処理システム固有の情報を記録するために処理システムで使用してもよい。

2.2.8 仮想区画マップ

これは，JIS X 0607の範囲を拡大し，連続書込み媒体(例えばCD-R)を含んだものとする。これを拡大したのは，区画マップエントリが仮想空間を記述するためとする。

論理ボリューム記述子には，与えられたボリュームを構成する区画の一覧が含まれる。仮想区画は，物理区画と同じ方法で記述することはできないので，次に指定する種別2区画マップを使うものとする。

仮想区画マップが記録されると，論理ボリューム記述子は，最低二つの区画マップを含まなければならない。一つの区画マップは種別1の区画マップとして記録しなければならない。もう一つの区画マップは種別2区画マップとして記録しなければならない。この種別2の区画マップのフォーマットは，次の表に指定された通りとする。

表2.10 仮想区画に関する種別2区画マップの配置

RBP	長さ	名前	内容
0	1	区画マップ種別	Uint8=2
1	1	区画マップ長	Uint8=64
2	2	予備	#00バイト
4	32	区画種別識別子	EntityID
36	2	ボリューム列数	Uint16
38	2	区画数	Uint16
40	24	予備	#00バイト

• 区画種別識別子:
  • フラグ=0
  • 識別子=*UDF仮想区画
  • 識別子添字は, 2.1.5.3のとおり記録する。
• ボリューム列番号=VAT及び区画を記録するボリューム
• 区画番号=ボリューム列番号で識別される，ボリューム内での区画の識別

2.2.9 予備区画マップ

特定のディスク/ドライブシステムは欠陥管理を行わない(例えばCD-RW)。これらのシステムに明らかに欠陥のない空間を与えるために，種別2の区画が使われる。区画マップは区画番号，パケットサイズ(1.3.2を参照)，予備テーブルの大きさと位置を定義する。この種別2のマップは，通常の媒体にある種別1のマップと置き換えるためのものとする。このマップは，区画番号とボリューム列番号を識別するだけでなく，パケット長及び予備表を識別する。予備区画マップは，欠陥管理を行うディスクク/ドライブシステムに記録してはならない。

表2.11 予備区画に関する種別2区画マップの配置

RBP	長さ	名前	内容
0	1	区画マップ種別	Uint8=2
1	1	区画マップ長	Uint8=64
2	2	予備	#00バイト
4	32	区画種別識別子	EntityID
36	2	ボリューム列番号	Uint16
38	2	区画番号	Uint16
40	2	パケット長	Uint16=32
42	1	予備表数(N_ST)	Uint8
43	1	予備	#00バイト
44	4	各予備表の大きさ	Uint32
48	4*N_ST	予備表の位置	Uint32
48+4*N_ST	16-4*N_ST	パッド	#00バイト

• 区画種別識別子:
  • フラグ=0
  • 識別子=*UDF 予備区画
  • 識別子添字は, 2.1.5.3のとおりに記録される。
• 区画番号=この区画の番号。この区画に関連する区画記述子を識別しなければならない。
• パケット長=固定パケットごとの利用者データブロック数。32に設定しなければならない。
• 予備表数=記録された冗長な表の数。これは1から4の範囲の値とする。
• 各予備表数=バイトの長さがバイトで各予備表に割り付けられる。
• 予備表の位置=媒体ブロック番地として指定される各予備表のスタート位置。処理システムでは，各予備表のスタートをパケットの始めに合わせることが望ましい。処理システムでは，最小二つの予備表を物理的に離れている位置に記録するのが望ましい。

2.2.10 仮想割付け表

仮想割付け表(VAT)は，連続書込みメディア(例えばCD-R)に使われ，システムに任意書込みメディアの様相を与える。VATは連続書込み媒体(例えばCD-R)にだけ記録しなければならない。

VATは仮想番地を論理番地に変換するマップとする。これは，ファイルエントリICB(VAT ICB)で識別されるファイルとして記録しなければならないが，表を構築する際，大幅な柔軟性を認める。VAT ICBはいかなる処理でも，最後に記録されるセクタとする。VAT自体は，どの位置に記録してもよい。

VATは，ファイル種別248のファイルエントリICBによって識別しなければならない。このICBは，記録された最後の有効データセクタとする。エラー修復計画はファイル種別248をもつICBを見つけることで，最後の有効なVATを見つけることができる。

このファイルは，小さいときは，記述するICBに埋め込むことができる。大きくなると，ICBに先行するセクタに記録できる。セクタは，隣接する必要はないが，必要に応じて表の新しい部分にだけ書込みができる。これによって，多くのディレクトリをもつディスクでも，僅かな増加分の更新が可能になる。

VATが小さいとき(ディスク上の少数ディレクトリ)，VATは，埋め込みVATで新しいファイルICBを書込むことにより更新される。VATが大きくなりすぎてICBに合わなくなると，VATで一つのセクタを書込み，ICBでほかのセクタを書込むことが必要になる。この点を越えると，VATのために複数のセクタが必要になる。しかし，複数のエクステントが利用可能になるため，VATの更新は，すべてのVATを示すポインタでICBを更新し書込む必要のあるセクタだけを，書込むだけでよい。

仮想割付け表は，特定の情報を求める要求を，適切な論理位置に導き直すのに使う。この表による遠回しな方法は，直接的な上書き能力の体裁を与える。例えば，ルートディレクトリを記述するICBは仮想セクタ1として参照できる。仮想セクタは，仮想区画マップエントリによって識別する区画に含まれる。ディスクを更新する過程でルートディレクトリが変わるかもしれない。変わる場合，ルートディレクトリを記述する新しいセクタが書込まれ，論理ブロック番地は，仮想セクタ1に対応する論理ブロック番地として記録される。仮想セクタ1を参照するものは，たとえ，新しい論理ブロック番地に存在していても，現存するうちで最新の仮想セクタ１を示すため，変わる必要はない。

仮想番地付けの使用によって，要求された構造が効果的な上書きを実行可能になる。この構造は，参照するすべてのポインタが，仮想番地だけでできるとき，書換え可能になる。書換え構造が書き込まれると，仮想の参照は変わる必要がなくなる。VATへの適切なエントリは，対応する仮想番地の新しい論理ブロック番地を反映するように変えられ，その後あらゆる仮想の参照は間接的に新しい構造を示す。ディレクトリICBのとおりに，更新が必要なすべての構造は，仮想番地で参照しなければならない。各構造が更新されると，VAT ICB内の対応するエントリが更新されるものとする。

VATは，Uint32エントリの連続としてファイルに記録するものとする。各エントリは，VATが位置する物理区画にセクタでオフセットにならなければならない。最初のエントリは，仮想区画セクタ0であり，2番目のエントリは仮想区画セクタ1とし，以降同様とする。Uint32エントリはVATヘッダに続くものとする。事前のVAT ICBの入力により，前の状態のようなファイルシステムを一覧できる。この欄が#FFFFFFFFである場合，そうしたICBは指定されない。

表2.12 仮想割付け表構造

オフセット	長さ	名前	内容
0	2	ヘッダの長さ(=L_HD)	Uint16
2	2	処理システム用の長さ(=L_IU)	Uint16
4	128	論理ボリューム記述子	dstring
132	4	VAT ICB前位置	Uint32
136	4	FID識別ファイル数	Uint32
140	4	ディレクトリ識別の非親FID数	Uint32
144	2	UDF最小書込み版	Uint16
146	2	UDF最小読取り版	Uint16
148	2	UDF最大書込み版	Uint16
150	2	予備	#00バイト
152	L_IU	処理システム用	バイト
152+L_IU	4	VATエントリ0	Uint32
156+L_IU	4	VATエントリ1	Uint32
情報 長さ-4	4	VATエントリn	Uint32

a) ヘッダの長さ VATエントリに先行するデータの量を識別する。この値は，152+L_IUとする。

b) 処理システム用長さ 処理システム用欄のバイト数を指定しなければならない。この欄が0でない場合，この値は，最低32で４の整数倍とする。

c) 論理ボリューム識別子 論理ボリュームを識別しなければならない。この欄は，論理ボリューム記述子で対応する欄の代わりに，処理システムで使用しなければならない。この欄の値は，利用者が変更するまで，LVDの欄と同じであることが望ましい。

d) VAT ICB前位置 区画マップエントリで識別される区画において，前のVAT ICBの論理ブロック番号を指定しなければならない。この欄が#FFFFFFFFならば，ICBは指定されない。

e) ファイルを識別するFIDの数 ボリュームでファイル数を識別し，ハードリンクを含む。ファイル数には，ディレクトリビットが設定されない階層のあらゆるFIDが含まれる。１に設定された削除ビットをもつFIDは数に入れない。この欄の内容は，LVIDにおいて対応する欄に代わって，処理システムで使用しなければならない。

f) ディレクトリ識別の非親FIDの数 ボリュームのディレクトリとルートディレクトリ数を識別する。1に設定された削除ビットをもつFIDは数に入れない。この欄の内容は，LVIDで対応する欄の代わりに処理システムで使用しなければならない。

g) UDF最小読取り版 2.2.6に定義されている。この欄の内容は，論理ボリューム保全記述子(LVID)で対応する欄の代わりに，処理システムで使用しなければならない。

h) UDF最小書込み版 2.2.6に定義されている。この欄の内容は，LVIDにおいて対応する欄の代わりに処理システムで使用しなければならない。

i) UDF最大書込み版 2.2.6に定義されている。この欄の内容は，LVIDにおいて対応する欄の代わりに処理システムで使用しなければならない。 処理システム用−長さが０でない場合，処理システム用領域の残りの使用を識別する実体識別子から始める。

j) VATエントリ VATエントリnは，仮想ブロックnの論理ブロック番号を識別するものとする。#FFFFFFFFのエントリは，仮想セクタが現在使用されていないことを示している。LBN指定は区画マップエントリで識別される区画に位置する。表のエントリの数は，ICBのVATファイルサイズから決定できる。

エントリ数(N)=(情報の長さ-L_HD)/4

2.2.11 予備表

特定のディスク/ドライブシステムは欠陥管理を行わない(例えばCD-RW)。これらのシステムに明らかに欠陥のない空間を作ること。特定のメディアでは，セクタのまとまり(パケット)にだけ書込みができ，再配置をさらに複雑にする。これは, セクタだけが書込まれるのではなく，パケット全体を再配置しなければならないことによる。この問題に取り組むため，区画マップで予備区画を識別するが，これはさらに，予備表の位置を識別する。予備表は媒体上で再配置された領域を識別する。予備表は，予備表区画マップで識別される。予備表は，欠陥管理を行うディスク/ドライブシステムに記録してはならない。

予備表は予備用に割り付けられた空間を示し，取替え部分に対する欠陥セクタの配置リストを含む。予備表の分離コピーは分離パケットに記録しなければならない。予備表は最新のものを維持しなければならない。

区画マップの論理空間を物理空間へ。通常，これは，オフセットと長さが指定される直線配置とする。予備区画ではこの配置に基くが，物理空間内の区画のオフセットと長さは区画記述子で指定される。予備表はさらに，論理配置から物理配置への例外リストを指定する。あらゆる配置の長さは，パケット一つ分とする。パケットサイズは予備区画マップで指定される。

予備領域は，メディアのどの部分でも，つまり区画の内外いずれでもよい。区画の内側の場合，予備空間は割付けられたとして表示され，割付け不可能空間リストに含まれるものとする。マップされた位置は，フォーマット時に埋めるものとする。元の位置は，エラーが起こると，自在に割り当てられる。各予備表は次のような構造とする。

表2.13 予備表配置

BP	長さ	名前	内容
0	16	記述子タグ	タグ=0
16	32	予備識別子	EntityID
48	2	再割付け表長(=RT_L)	Uint16
50	2	予備	#00バイト
52	4	列番号	Uint32
56	8*RT_L	マップエントリ	マップエントリ

この構造は必要ならば一つのセクタより大きくてもよい。

• 記述子タグ
  タグ識別子0を含むが，これは，記述子タグのフォーマットが，JIS X 0607で指定されていないことを示す。記述子タグの他の欄はすべて，タグ識別子は，JIS X 0607で定義された値であるかのように，有効でなければならない。
• 予備識別子:
  • フラグ=０
  • 識別子=*UDF 予備表
  • 識別子添字は, 2.1.5.3のとおりに記録される。
• 再割付け表長
  マップエントリ表のエントリの数を示す。
• 連続番号
  予備表更新の都度，増加する数を含む。
• マップエントリ
  マップエントリは次の表に記述される。マップは元の位置の欄によって昇順に分類しなければならない。

表2.14 マップエントリ記述

RBP	長さ	名前	内容
0	4	元の位置	Uint32
4	4	マップ位置	Uint32

• 元の位置
  パケットの論理ブロック番地を予備とする。パケットの番地は，パケットの，最初の利用者データブロックの番地とする。この欄が#FFFFFFFFであれば，このエントリは，予備のために可能となる。この欄が#FFFFFFF0であれば，対応するマップ位置は欠陥と表示され，マッピングには使わないことが望ましい。#FFFFFFFFから#FFFFFFF1の元の位置は予備として確保しておく。
• マップ位置
  動作中のデータの物理ブロック番地。元のパケット位置への要求は，ここで識別されるパケット位置に再度導かれる。マップ位置のエントリはすべて有効で，元の位置が#FFFFFFF0，#FFFFFFFF，又は予備であるエントリを含むものとする。マップ位置が区画と重なる場合，その区画は，割付け済みと表示された空間をもつものとし，その空間は，割付け不可能空間リストの一部に入れなければならない。

2.3 第4部 ファイルシステム

2.3.1 記述子タグ(Descriptor Tag)

  struct tag{    /* ECMA 167 4/7.2 */
         Uint16  TagIdentifier;
         Uint16  DescriptorVersion;
         Uint8   TagChecksum;
         byte    Reserved;
         Uint16  TagSerialNumber;
         Uint16  DescriptorCRC;
         Uint16  DescriptorCRCLength;
         Uint32  TagLocation;
  }

2.3.1.1 タグ通し番号(Uint16 TagSerialNumber)

• a) 意味 無視する。
• b) 設定値 ボリュームの初期化時に，値を再設定する。

タグ通し番号は，ボリュームの再初期化時には，以前に記録した値と異なる値を設定しなければならない。この欄の意図する使用方法は，障害回復とする。第4部のすべての記述子のタグ通し番号は，関連するファイル集合記述子に使用した通し番号と同一であるのが望ましい。

2.3.1.2 記述子CRC長(Uint16 DescriptorCRCLength)

特記しない限り，CRCは，各記述子で利用可能であり，計算されなければならない。この欄の値は，(記述子の大きさ)-(記述子タグの長さ) に設定するものとする。記述子を読み出すときは，CRCを検証するのが望ましい。

2.3.2 ファイル集合記述子(File Set Descriptor)

  struct FileSetDescriptor{  /* ECMA 167 4/14.1 */
         struct tag          DescriptorTag;
         struct timestamp    RecordingDateandTime;
         Uint16              InterchangeLevel;
         Uint16              MaximumInterchangeLevel;
         Uint32              CharacterSetList;
         Uint32              MaximumCharacterSetList;
         Uint32              FileSetNumber;
         Uint32              FileSetDescriptorNumber;
         struct charspec     LogicalVolumeIdentifierCharacterSet;
         dstring             LogicalVolumeIdentifier[128];
         struct charspec     FileSetCharacterSet;
         dstring             FileSetIdentifier[32];
         dstring             CopyrightFileIdentifier[32];
         dstring             AbstractFileIdentifier[32];
         struct long_ad      RootDirectoryICB;
         struct EntityID     DomainIdentifier;
         struct long_ad      NextExtent;
         struct long_ad      StreamDirectoryICB
         byte                Reserved[32];
  }

書換形/上書き可能形媒体中には，一つだけファイル集合記述子を記録しなければならない。追記形媒体中には，複数のファイル集合記述子を記録してもよい。

複数のファイル集合に関するUDF規定を，次に示す。

• 複数のファイル集合は，追記形媒体中だけに許可する。
• デフォルトのファイル集合は，最大のファイル集合番号をもたなければならない。
• デフォルトのファイル集合だけを，書込み可能としてよい。その列における他のすべてのファイル集合は，ハード書込み保護(実体識別子の定義参照)を設定しなければならない。
• 書込み不可のファイル集合は，その他のファイル集合で参照(直接又は間接的に)するメタデータ構造を参照しなければならない。書込み可能のファイル集合は，実ファイルデータエクステントを参照してもよい。

追記形媒体のファイル集合中では，すべてのファイル及びディレクトリをICB方策種別4で記録する場合，そのファイル集合記述子の範囲識別子にはハード書込み保護を設定しなければならない。

追記形媒体中の複数のファイル集合の意図する目的は，媒体中に複数のアーカイブをサポートする機能を利用可能にすることとする。例えば，一つのファイル集合は，特定の時点で作成した情報集合のバックアップを表現する。

後続のファイル集合は，その後作成した同一情報集合の他のバックアップとして表現する。

2.3.2.1 交換水準(Uint16 InterchangeLevel)

• a) 意味 関連するファイル集合の内容の現状の交換水準(JIS X 0607の4/15で規定)及び規定水準が意味する制限の指定と解釈する。
• b) 設定値 水準3を設定しなければならない。

処理システムは，規定する現状の交換水準に関連する制限を実施する。

2.3.2.2 最大交換水準(Uint16 MaximumInterchangeLevel)

• a) 意味 関連するファイル集合の内容についての交換最大水準の指定と解釈する。この値は，現状の交換水準欄で設定してよい値を制限する。
• b) 設定値 水準3を設定しなければならない。

2.3.2.3 文字集合リスト(Uint32 CharacterSetList)

• a) 意味 JIS X 0607の第4部において定義され，この記述子によって記述するファイル集合に記録されるすべての記述子において，内容をcharspecと規定するすべての欄で指定される文字集合の指定と解釈する。
• b) 設定値 2.1.2で定義するCS0だけを利用可能とする設定をしなければならない。

2.3.2.4 文字最大集合リスト(Uint32 MaximumCharacterSetList)

• a) 意味 関連するファイル集合で利用可能な文字集合の最大値及び規定水準が意味する制限の指定と解釈する。
• b) 設定値 2.1.2で定義するCS0だけを利用可能とする設定をしなければならない。

2.3.2.5 論理ボリューム識別子用文字集合(struct charspec LogicalVolumeIdentifierCharacterSet)

• a) 意味 論理ボリューム識別子欄で使用可能なd文字の指定と解釈する。
• b) 設定値 2.1.2で定義するCS0を利用可能とする設定をしなければならない。

2.3.2.6 ファイル集合用文字集合(struct charspec FileSetCharacterSet)

• a) 意味 JIS X 0607の第4部で定義された，ファイル集合記述子の適用範囲内の内容がdstringである欄で使用可能なd文字の指定と解釈する。
• b) 設定値 2.1.2で定義するCS0を利用可能とする設定をしなければならない。

2.3.2.7 範囲識別子(struct EntityID DomainIdentifier)

• a) 意味 記述子中の欄の使用規則及び制限を規定する範囲の指定と解釈する。この欄がNULLの場合，無視する。それ以外の場合は，実体識別子の規則に従う。
• b) 設定値 この欄は，この標準情報(TR)で定義する範囲に適合するファイル集合記述子の適用範囲を示すものとする。したがって，範囲識別子は，

  "*OSTA UDF Compliant"

  に設定しなければならない。

  実体識別子の節で記述したとおり，実体識別子の識別子添字欄には，論理ボリュームの内容が互換性をもつ本規定の版数を含む。この欄の適切な扱いに関する詳細情報は，実体識別子の節を参照のこと。

   備考 実体識別子の識別子添字欄は，ソフト書込み保護フラグ及びハード書込み保護フラグを含む。

2.3.3 区画ヘッダ記述子(Partition Header Descriptor)

  struct PartitionHeaderDescriptor{{ /* ECMA 167 4/14.3 */
         struct short_ad    UnallocatedSpaceTable;
         struct short_ad    UnallocatedSpaceBitmap;
         struct short_ad    PartitionIntegrityTable;
         struct short_ad    FreedSpaceTable;
         struct short_ad    FreedSpaceBitmap;
         byte               Reserved[88];
  }

要するに，未割付けとした論理ブロックは，前処理なしに書込み可能なブロックとする。書換形媒体の場合，消去処理なしに書き込める。未初期化とした論理ブロックは，書込み準備が必要なブロックであり，何らかの前処理をする必要がある。書換形媒体の場合，消去処理後に書き込む。

 備考 空間表又は空間ビットマップの使用は，論理ボリューム中で一貫していなければならない。空間表及び空間ビットマップの両方を一つの論理ボリューム中で同時に使用してはならない。

2.3.3.1 区画保全表(struct short_ad PartitionIntegrityTable)

区画保全エントリは使用しないため，すべて0を指定しなければならない。

2.3.4 ファイル識別記述子(File Identifier Descriptor)

  struct FileIdentifierDescriptor{  /* ECMA 167 4/14.4 */
         struct tag              DescriptorTag;
         Uint16                  FileVersionNumber;
         Uint8                   FileCharacteristics;
         Uint8                   LengthofFileIdentifier;
         struct long_ad          ICB;
         Uint16                  LengthofImplementationUse;
         byte                    ImplementationUse[];
         char                    FileIdentifier[];
         byte                    Padding[];
  }

ファイル識別記述子は，一つの論理ブロックの長さに制限しなければならない。

2.3.4.1 ファイル版数(Uint16 FileVersionNumber)

• a) 意味 ファイルには，次の値をもつただ一つの版数が存在するものとする。
• b) 設定値 値1を設定しなければならない。

2.3.4.2 ファイル特性(File Characteristics)

削除ビットは，ディレクトリからFIDを除去せずに，ファイル又はディレクトリが削除されていることを表示するために使用してもよい。この場合，その地点から最後まで，ディレクトリを書き換えることが必要になる。ファイル又はディレクトリの空間の割付けが解除されているとき，処理システムでは，ICB欄を0に設定しなければならない。これは, 削除ビットが設定されても，FIDの欄がすべて有効でなければならないことによる。[4/14.4.3]，備考21，及び[4/14.4.5]を参照。

そのようなFIDの，ファイル識別子の削除ビットの状態に関係なく，ディレクトリのFIDは，同一のファイル識別子(及び1のファイル版数)をもってはならない。[4/8.6]を参照。

 備考 処理システムでは，ディレクトリが大きくなるのを避けるため，1に設定されたビット及び0に設定されたICBをもつFIDを再使用するのが望ましい。

ファイル識別記述子を削除するとき，処理システムでは，Uint32又はUint64の値として，圧縮IDを0xFEに変更し，次の4バイトを設定するか，圧縮IDを0XFFに変更し，識別子の次の8バイトをディレクトリ内のFIDのオフセットのバイトに設定してもよい。L_FIは，5又は9に設定するものとする。ディレクトリの走査中，0XFE及び0XFFの圧縮IDをもつFIDは無視してもよい。

2.3.4.3 structlong_ad ICB

あらゆるファイル識別記述子のlong_adの処理システム用バイトは，ファイル及びディレクトリ名前空間のUDF一意IDを記録するのために使用するものとする。

表2.15 UDF一意ID

RBP	長さ	名前	内容
0	2	予備	バイト(=#00)
2	4	UDF一意ID	Uint32

3.2.1の論理ボリュームヘッダ記述子は，ファイル識別記述子のlong_adの処理システム用バイトにおけるUDF一意ID欄，並びに，ファイルエントリ及び拡張ファイルエントリの一意ID欄の設定方法を記述している。

2.3.4.4 処理システム用の長さ(Uint16 LengthofImplementationUse)

• a) 意味 処理システム用欄の長さを指定するものとする。
• b) 設定値 この欄には，処理システム用欄の長さを指定するものとするが，処理システム用欄が未使用であることを示す0を設定してもよい。

ファイル識別記述子を追記形媒体に書き込むとき，次のFIDの記述子タグ欄がブロック境界に及ばないことを保証するため，FIDの後の現在のブロックに16未満のバイトが残っていれば，FIDの長さは，これを避けるのに十分なだけ増加する｡(この場合処理システム用欄を使用する｡)CRC長は，FID−16未満の大きさに設定してもよい。(処理システム用領域を含めないため。)

2.3.4.5 処理システム用(byte ImplementationUse)

• a) 意味 処理システム用の長さ欄が0でない場合，この欄の最初の32バイトは，ファイル識別記述子を最後に更新した処理システムの処理システム実体識別子の指定と解釈する。
• b) 設定値 処理システム用の長さ欄が0でない場合，この欄の最初の32バイトに，現状の処理システムの処理システム実体識別子を指定するものとする。

 備考 この欄の適切な扱いに関する詳細情報は，実体識別子の節を参照のこと。

この欄は，特定のファイル識別記述子を最後に作成又は更新した処理システムを識別することを処理システムに許可する。

2.3.5 ICBタグ(ICB Tag)

  struct icbtag{       /* ECMA 167 4/14.6 */
         Uint32       PriorRecordedNumberofDirectEntries;
         Uint16       StrategyType;
         byte         StrategyParameter[2];
         Uint16       NumberofEntries;
         byte         Reserved;
         Uint8        FileType;
         Lb_addr      ParentICBLocation;
         Uint16       Flags;
  }

2.3.5.1 方策種別(Uint16 StrategyType)

• a) 意味 この欄の内容には，使用するICB方策種別を指定する。読み出しアクセスの目的の処理システムは，方策種別4及び4096を利用可能とする。
• b) 設定値 値4又は4096を設定するものとする。

 備考 附属書で定義する方策種別4096は，追記形媒体中で主に使用する予定であるが，書換形/上書き形媒体で使用してもよい。

2.3.5.2 ファイル種別(Uint8 FileType)

標準のバイトで番地付け可能なファイルのために値5を使用し，0は使用しない。

2.3.5.3 親ICB位置(ParentICBLocation)

この欄の使用は，オプションとする。

 備考 JIS X 0607の4/14.6.7では，この欄が0の場合，そのようなICBを指定していないことを意味する，と規定している。これは，処理システムがICBを論理ブロック番地0に記録できることから，規定の誤りとする。したがって，この欄を使用する場合，ICBを論理ブロック0に記録してはならない。

2.3.5.4 フラグ(Uint16 Flags)

a) ビット0〜2

これらのビットは，使用する割付け記述子の種別を指定する。使用する割付け記述子種別の選択のガイドラインについては，割付け記述子の節を参照のこと。

b) ビット3(分類)

• 1) 意味 OSTA UDF適合媒体に関して，このビットは，ディレクトリが未分類でもよい(ZERO)ことを示すものとする。
• 2) 設定値 ZEROを設定するものとする。

c) ビット4(再配置不可)

• 1) 意味 OSTA UDF適合媒体に関して，このビットは，ファイルが再配置不可である(ONE)ことを示してもよい。ファイルを再配置しないことを処理システムが保証できない場合に，ファイルが再配置可能であることを示すために，処理システムはこのビットをZEROにリセットしてもよい。
• 2) 設定値 ZEROを設定することが望ましい。

d) ビット9(連続性)

• 1) 意味 OSTA UDF適合媒体に関して，このビットは，ファイルが連続である(ONE)ことを示してもよい。ファイルが連続であることを処理システムが保証できない場合に，ファイルが不連続でもよいことを示すために，処理システムはこのビットをZEROに設定してもよい。
• 2) 設定値 ZEROを設定することが望ましい。

e) ビット11(変換)

• 1) 意味 OSTA UDF適合媒体に関して，このビットは，変換がない(ZERO)ことを示すものとする。
• 2) 設定値 ZEROを設定するものとする。

データ圧縮法及びその他のデータ変換形式は，将来のOSTAの規定で示す。

f) ビット12(複数版数)

• 1) 意味 OSTA UDF適合媒体に関して，このビットは，複数版数ファイルが存在しない(ZERO)ことを示すものとする。
• 2) 設定値 ZEROを設定するものとする。

2.3.6 ファイルエントリ(File Entry)

  struct FileEntry{  /* ECMA 167 4/14.9 */
         struct tag            DescriptorTag;
         struct icbtag         ICBTag;
         Uint32                Uid;
         Uint32                Gid;
         Uint32                Permissions;
         Uint16                FileLinkCount;
         Uint8                 RecordFormat;
         Uint8                 RecordDisplayAttributes;
         Uint32                RecordLength;
         Uint64                InformationLength;
         Uint64                LogicalBlocksRecorded;
         struct timestamp      AccessTime;
         struct timestamp      ModificationTime;
         struct timestamp      AttributeTime;
         Uint32                Checkpoint;
         struct long_ad        ExtendedAttributeICB;
         struct EntityID       ImplementationIdentifier;
         Uint64                UniqueID;
         Uint32                LengthofExtendedAttributors;
         Uint32                LengthofAllocationDescriptes;
         byte                  ExtendedAttributes[];
         byte                  AllocationDescriptors[];
  }

 備考 ファイルエントリの全総長は，一つの論理ブロック長を超えてはならない。

2.3.6.1 レコードフォーマット(Uint8 RecordFormat)

• a) 意味 OSTA UDF適合媒体に関して，ファイルに記録する情報の構造はこの欄で規定しない(0)ことを示すものとする。
• b) 設定値 0を設定するものとする。

2.3.6.2 レコード表示属性(Uint8 RecordDisplayAttributes)

• a) 意味 OSTA UDF適合媒体に関して，ファイルに記録する情報の構造はこの欄で規定しない(0)ことを示すものとする。
• b) 設定値 0を設定するものとする。

2.3.6.3 レコード長(Uint32 RecordLength)

• a) 意味 OSTA UDF適合媒体に関して，ファイルに記録する情報の構造はこの欄で規定しない(0)ことを示すものとする。
• b) 設定値 0を設定するものとする。

2.3.6.4 情報長(Uint64 InformationLength)

大抵の場合，情報長は，各割当記述子の合計の長さを見つけることにより，回復操作中に再構築できる。しかし，空間はファイルの最後尾("ファイル後尾"として識別される)の後に割り付けてもよい。割付け空間と未記録空間はファイルの合法的な部分なので，ファイルの，最後の割付け記述子の次の部分が2^30-ブロックサイズバイトを識別する場合，また，最後の割付け記述子の次の部分がブロックサイズの整数倍で，最後の割付け記述子の次の部分に連続していない場合，情報長を確定するために割付け記述子を使うと失敗するだろう。

2.3.6.5 記録済み論理ブロック(Uint64 LogicalBlocksRecorded)

データを埋め込んだファイル又はディレクトリについて，この欄の値は０とする。

2.3.6.6 処理システム識別子(struct EntityID ImplementationIdentifier)

実体識別子の節を参照のこと。

2.3.6.7 一意ID(Uint64 UniqueID)

ファイル集合のルートディレクトリに関して，この値は0を指定するものとする。

3.2.1の論理ボリュームヘッダ記述子は，ファイル識別記述子におけるlong_adの処理システム用バイトのUDF一意ID欄並びに，ファイルエントリ及び拡張ファイルエントリの一意IDファイルの設定方法を記述している。

2.3.7 未割付け空間エントリ(Unallocated Space Entry)

  struct UnallocatedSpaceEntry{  /* ECMA 167 4/14.11 */
         struct tag           DescriptorTag;
         struct icbtag        ICBTag;
         Uint32               LengthofAllocationDescriptors;
         byte                 AllocationDescriptors[];
  }

 備考 未割付け空間エントリの最大長は，一つの論理ブロック長とする。

2.3.7.1 未割付け記述子(byte AllocationDescriptors)

短割付け記述子だけを使用する。

 備考 割付け記述子中のエクステント長欄の上位2ビットは，エクステント種別(JIS X 0607 4/14.14.1.1)を指定する。未割付け空間エントリで規定する割付け記述子に関して，この種別は，割り付けてはいるが未記録であるエクステントを示す値1に設定し，又はエクステントが割付け記述子の後続エクステントであることを示す値3に指定しなければならない。割付け記述子の後続エクステントは，一つの論理ブロックの長さに制限しなければならない。

割付け記述子は，位置の昇順に連続的に並べるものとする。表中の割付け記述子は重複してはならない。例えば，位置=2,長さ=2048(論理ブロック長=1024)の割付け記述子の次が，位置=3の割付け記述子であることは許されない。隣接する割付け記述子が続いてはならない。例えば，位置=2,長さ=1024(論理ブロック長=1024)の割付け記述子の次が，位置=3の割付け記述子であってはならず，位置=2,長さ=2048の一つの割付け記述子でなければならない。隣接する割付け記述子が続いてもよい唯一の場合は，どちらか一方の隣接する割付け記述子の長さが，割付け記述子で記述可能な最大値のときとする。

2.3.8 空間ビットマップ記述子(Space Bitmap Descriptor)

  struct SpaceBitmap{   /* ECMA 167 4/14.11 */
         struct Tag   DescriptorTag;
         Uint32       NumberOfBits;
         Uint32       NumberOfBytes;
         byte         Bitmap[];
  }

2.3.8.1 記述子タグ(struct Tag DescriptorTag)

空間ビットマップ記述子に関する記述子タグの記述子CRC欄の計算及び保守は，オプションとする。CRCをメンテナンスできない場合，記述子CRC欄及び記述子CRC長欄の両方を0に設定する。

2.3.9 区画保全エントリ(Partition Integrity Entry)

  struct PartitionIntegrityEntry{  /* ECMA 167 4/14.13 */
           struct tag             DescriptorTag;
           struct icbtag          ICBTag;
           struct timestamp       RecordingTime;
           Uint8                  IntegrityType;
           byte                   Reserved[175];
           struct EntityID        ImplementationIdentifier;
           byte                   ImplementationUse[256];
  }

論理ボリューム保全記述子の機能により，この記述子は必要でないため，この記述子は記録してはならない。

2.3.10 割付け記述子(Allocation Descriptor)

ファイルのデータ領域を構成するとき，処理システムは，選択対象のいくつかの種別の割付け記述子をもつ。次に示すガイドラインは，使用する適切な割付け記述子の選択時に従うものとする。

a) 短割付け記述子 単一ボリュームを超えて論理ボリュームを拡張する予定のない単一ボリューム中に存在する論理ボリュームに関して，短割付け記述子を使用するのが望ましい。例えば，独立した装置で作成した論理ボリューム。

   備考 交換最大水準の2.2.2.2を参照のこと。

b) 長割付け記述子 単一ボリュームを超えて論理ボリュームを後で拡張する予定の単一ボリュームが存在する論理ボリューム又は複数ボリュームに存在する論理ボリュームに関して，長割付け記述子を使用するものとする。例えば，集合形装置で使うために作成した論理ボリューム。

   備考 単一ボリューム中でも長割付け記述子を使用する利点はある。この利点は，書換形媒体中の消去したエクステントの追跡を利用可能とすることとする。付加情報については，2.3.10.1を参照のこと。

短割付け記述子及び長割付け記述子の両方に関して，エクステント長欄の下位30ビットが0であれば，上位2ビットは0でなければならない。

仮想空間を識別する割付け記述子は，1個又はそれ以下の，ブロックの拡張長をもつものとする。ファイルデータ，ディレクトリ，又はストリームデータを識別する割付け記述子は物理空間を識別するものとする。仮想空間に記録されたICBは，物理空間を識別するために，long_ad割付け記述子を使用するものとする。short_ad割付け記述子を使用することにより，ICBが仮想空間にあれば，仮想空間のファイルデータを識別するだろう。

仮想空間に記録された記述子は，タグ位置欄に記録された仮想論理ブロック番号をもつものとする。

2.3.10.1 長割付け記述子(Long Allocation Descriptor)

  struct long_ad{   /* ECMA 167 4/14.14.2 */
         Uint32     ExtentLength;
         Lb_addr    ExtentLocation;
         byte       ImplementationUse[6];
  }

UDFと処理システムの両方に処理システム用欄の使用を許可するために，6バイトの処理システム用欄の中に次の構造を記録するものとする。

  struct ADImpUse
  {
         Uint16   flags;
         byte     impUse[4];
  }
  /*
    *ADImpUse Flags (NOTE:bits 1-15 reserved for future use by UDF)
  */
  #define EXTENTErased    (0x01)

前処理の利点である書換形媒体の効率のために，このエクステント消去(EXTENTErasd)フラグは，消去したエクステントを示すONEを設定するものとする。これは，割り付けたが未記録であるエクステントだけに使用する。

2.3.11 割付けエクステント記述子(Allocation Extent Descriptor)

  struct AllocationExtentDescriptor{   /* ECMA 167 4/14.5 */
         struct tag    DescriptorTag;
         Uint32        PreviousAllocationExtentLocation;
         Uint32        LengthOfAllocationDescriptors;
  }

 備考 割付け記述子エクステントは，最大長1論理ブロックとする。

2.3.11.1 先行割付けエクステント位置(PreviousAllocationExtentLocation)

• a) 意味 この欄は使用してはならない。
• b) 設定値 値0を設定するものとする。

2.3.12 パス名(Pathname)

2.3.12.1 パス要素(Path Component)

  struct PathComponent{  /* ECMA 167 4/14.16.1 */
         Uint8        ComponentType;
         Uint8        LengthofComponentIdentifier;
         Uint16       ComponentFileVersionNumber;
         char         ComponentIdentifier[];
  }

2.3.12.1.1 要素ファイル版数(Uint16 ComponentFileVersionNumber)

• a) 意味 設定値0を用いて，ファイルにはただ一つの版数が存在するものとする。
• b) 設定値 値0を設定するものとする。

2.4 第5部 レコード構造

レコード構造ファイルは，作成してはならない。これらが媒体中に存在し，処理システムが利用可能でない場合は，内容を解釈しないバイト列として扱うものとする。

3. システム依存要件

3.1 第1部 一般

3.1.1 日時表示 (Timestamp)

  struct timestamp{  /*ECMA 167 1/7.3*/
         Uint16     TypeAndTimezone;
         Uint16     Year;
         Uint8      Month;
         Uint8      Day;
         Uint8      Hour;
         Uint8      Minute;
         Uint8      Second;
         Uint8      Centiseconds;
         Uint8      HundredsofMicroseconds;
         Uint8      Microsecond;
  }

3.1.1.1 1/100秒(Uint8 Centisecond)

• a) 意味 1/100秒の概念をサポートしないオペレーティングシステムでは，処理システムはこの欄を無視するものとする。
• b) 設定値 1/100秒の概念をサポートしないオペレーティングシステムでは，処理システムはこの欄に0を設定するものとする。

3.1.1.2 100マイクロ秒(Uint8 HundredsofMicrosecond)

• a) 意味 100マイクロ秒の概念をサポートしないオペレーティングシステムでは，処理システムはこの欄を無視するものとする。
• b) 設定値 100マイクロ秒の概念をサポートしないオペレーティングシステムでは，処理システムはこの欄に0を設定するものとする。

3.1.1.3 マイクロ秒(Uint8 Microceconds)

• a) 意味 マイクロ秒の概念をサポートしないオペレーティングシステムでは，処理システムはこの欄を無視するものとする。
• b) 設定値 マイクロ秒の概念をサポートしないオペレーティングシステムでは，処理システムはこの欄に0を設定するものとする。

3.2 第3部 ボリューム構造

3.2.1 論理ボリュームヘッダ記述子(Logical Volume Header Descriptor)

  struct LogicalVolumeHeaderDesc{  /*ECMA 167 4/14.15*/
        Uint64     UniqeID,
        bytes      reserved[24]
  }

3.2.1.1 一意ID(Uint64 UniquID)

この欄は，次の段階で使用するのが望ましい，一意IDの値を含む。この欄は16に初期設定し，次に記述する各割付けと共に単調に増加する。この値の下位32ビットが#FFFFFFFFに達すると，上位32ビットは，64ビット値に期待されるとおり，1ずつ増加するが，下位32ビットは，16(初期設定値)に折り返す。この動作は，16から2^32-1全体を含むID数の空間を使用しているMacTM OSで可能であり，他のプラットフォームには問題を生じない。

一意IDは，新しいファイル又はディレクトリが生成されるか，他の名前を現存のファイル又はディレクトリにリンクするときに使用する。ファイル識別記述子及びファイルエントリ/拡張ファイルエントリは，ファイル又はディレクトリに関連する，ストリームディレクトリ又は名前付きストリームに使われるが，一意IDは使用しない。むしろ，これらの構造の一意ID欄は，ストリームが関連するファイル/ディレクトリの，ファイルエントリ/拡張ファイルエントリの一意IDから，そうした値を取る。

ファイル又はディレクトリが生成されると，この一意IDはファイルエントリ/拡張ファイルエントリの一意ID欄に割り付けられ，一意IDの下位32ビットは，ファイル識別記述子(2.3.4.2を参照)のlong_adの処理システム用バイトのUDF一意記述子に割り付けられ，一意IDは，前に記述された方法で増加する。

名前が現存のファイル又はディレクトリにリンクすると，次の一意IDの下位32ビットが，ファイル識別記述子(2.3.4.2を参照)のlong_adの処理システム用バイトのUDF一意IDに割り付けられ，一意IDは先に記述された方法で増加する。

下位32ビットは，ファイルエントリ/拡張ファイルエントリ及び最初のファイル識別記述子において同じとするが，後続のFIDでは異なるものとする。

UDF処理システムはすべて，この節に記述されているとおりに，FIDでUDF一意IDを維持するものとし，FE/EFEでは一意IDを維持するものとする。閉じた論理ボリューム保全記述子のLVHDは有効な一意IDをもつものとする。

3.3 第4部 ファイルシステム

3.3.1 ファイル識別記述子(File Identifier Descriptor)

  struct FileIdentifierDescriptor{    /*ECMA 167 4/14.4*/ 
           struct tag      DescriptorTag;
           Uint16          FileVersionNumber;
           Uint8           FileCharacteristics;
           Uint8           LengthofFileIdentifier;
           struct long_ad  ICB;
           Uint16          LengthofImplementationUse;
           byte            ImplementationUse[];
           char            FileIdentifier[];
           byte            Padding[];
  }

 備考 すべてのUDFディレクトリは，親ディレクトリの位置を示すファイル識別記述子を含むものとする。親ディレクトリを記述するファイル識別記述子は，ディレクトリ中の先頭のファイル識別記述子とする。JIS X 0607の8.6で規定するとおりに，ルートディレクトリの親ディレクトリは，ルートディレクトリとする。

3.3.1.1 ファイル特性(Uint8 FileChacteristics)

いろいろなオペレーティングシステムでのファイル特性の使用法を次節で記述する。

3.3.1.1.1 MS-DOS, OS/2, Windows 95, Windows NT, Macintosh

• a) 意味
  • ビット0がONEの場合，隠しファイルと解釈するものとする。
  • ビット1がONEの場合，ディレクトリファイルと解釈するものとする。
  • ビット2がONEの場合，削除ファイルと解釈するものとする。
  • ビット3がONEの場合，関連するファイル識別子構造中のICB欄は，この記述子に記録するディレクトリの親ディレクトリを識別していると解釈するものとする。
• b) 設定値
  • 隠しファイルを示す場合，ビット0にONEを指定するものとする。
  • ディレクトリファイルを示す場合，ビット1にONEを指定するものとする。
  • 削除ファイルを示す場合，ビット2にONEを指定するものとする。

3.3.1.1.2 UNIX

UNIXで，隠しファイルを普通の隠しファイルでないものとして処理することを除けば，これらのビットは3.3.1.1.1の規定と同様に処理するものとする。

3.3.2 ICBタグ

  struct icbtag{   /*ECMA 167 4/14.6*/
         Uint32    PriorRecordedNumberofDirectEntries;
         Uiny16    StrategyType;
         byte      StrateryParameter[2];
         Uint16    NumberofEntries;
         byte      Reserved;
         Uint8     FileType;
         Lb_addr   ParentICBLocation;
         Uint16    Flags;
  }

3.3.2.1 フラグ(Uint16 Flags)

3.3.2.1.1 MS-DOS, OS/2, Windows 95, Windows NT

a) ビット6及び7(Setuid & Setgid)

• 1) 意味 無視する。
• 2) 設定値 これらのビットを利用可能とする環境の下でのセキュリティ情報のメンテナンスのために，次に示す状態のいずれかの一つが真の場合，ビット6及び7をZEROに設定するものとする。
  • 一つのファイルを作成する。
  • ファイルに関連付けた属性/許可条件を修正する。
  • ファイルを書き込む(ファイルに関係するデータの内容を更新して)。
  • ファイルに関連する拡張属性を修正する。
  • ファイルに関連するストリームを修正する。

b) ビット8(Sticky)

• 1) 意味 無視する。
• 2) 設定値 ZEROを設定するものとする。

c) ビット10(System)

• 1) 意味 MS-DOS及びOS/2システムビットに配置する。
• 2) 設定値 MS-DOS及びOS/2システムビットを配置する。

3.3.2.1.2 Macintosh

a) ビット6及び7(Setuid & Setgid)

• 1) 意味 無視する。
• 2) 設定値 これらのビットを利用可能とする環境の下でのセキュリティ情報の保メンテナンスのために，次に示す状態のいずれかの一つが真の場合，ビット6及び7にZEROを設定するものとする。
  • 一つのファイルを作成する。
  • ファイルと関連付けた属性/許可条件を修正する。
  • ファイルを書き込む(ファイルに関係するデータの内容を更新して)。
  • ファイルに関連する拡張属性を修正する。
  • ファイルに関連するストリームを修正する。

b) ビット8(Sticky)

• 1) 意味 無視する。
• 2) 設定値 ZEROを設定するものとする。

c) ビット10(System)

• 1) 意味 無視する。
• 2) 設定値 ZEROを設定するものとする。

3.3.2.1.3 UNIX

a) ビット6, 7及び8(Setuid, Setgid, Sticky)

これらのビットは，これに相当するUNIXファイルシステムに相当するビットに配置する。

b) ビット10(System)

• a) 意味 無視する。
• b) 設定値 ファイル作成時だけZEROを設定し，他は保守するものとする。

3.3.3 ファイルエントリ(File Entry)

  struct FileEntry{  /*ECMA 167 4/14.9*/
         struct tag            DescriptorTag;
         struct icbtag         ICBTag;
         Uint32                Uid;
         Uint32                Gid;
         Uint32                Permissions;
         Uint16                FileLinkCount;
         Uint8                 RecordFormat;
         Uint8                 RecordDisplayAttributes;
         Uint32                RecordLength;
         Uint64                InformationLength;
         Uint64                LogicalBlocksRecorded;
         struct timestamp      AccessTime;
         struct timestamp      ModificationTime;
         struct timestamp      AttributeTime;
         Uint32                checkpoint;
         struct long_ad        ExtendedAtrributeICB;
         struct EntityID       ImplementationIdentifier;
         Uint64                UniqueID;
         Uint32                LengthofExtendedAtrributors;
         Uint32                LengthofAllocationDescriptors;
         byte                  ExtendedAtrributes[];
         byte                  AllocationDescriptors[];
  }

 備考 ファイルエントリの全長は，一つの論理ブロック長を超えてはならない。

3.3.3.1 利用者ID(Uint32 Uid)

• a) 意味 利用者識別子の概念をサポートしないオペレーティングシステムでは，処理システムは，この欄を無視するものとする。この欄をサポートするオペレーティングシステムでは，(2³²-1)の値は無効な利用者IDと解釈し，他の場合，この欄は有効な利用者IDを含む。
• b) 設定値 利用者が規定しない限り，利用者IDの概念をサポートしないオペレーティングシステムでは，処理システムは，無効な利用者IDと解釈するための値(2³²-1)をこの欄に設定するものとする。

3.3.3.2 グループID(Uint32 Gid)

• a) 意味 グループIDの概念をサポートしないオペレーティングシステムでは，処理システムは，この欄を無視するものとする。この欄をサポートするオペレーティングシステムでは，(2³²-1)の値は無効なグループIDと解釈し，他の場合，この欄は有効なグループIDを含むものとする。
• b) 設定値 利用者が規定しない限り，グループIDの概念をサポートしないオペレーティングシステムでは，処理システムは無効なグループIDと解釈するための値(2³²-1)をこの欄に設定するものとする。

3.3.3.3 許可条件(Uint32 Permissions)

   /* Definition: */
   /*   Bit     for  a  file              for a Directory                               */
   /* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
   /*  Exeute May excute file             May search directory                          */
   /*  write  May change file contents    May create and delete files                   */
   /*  Read   May examine fil contents    May list  files in directory                  */
   /*  ChAttr May change file attributes  May change dir attributes                     */
   /*  Delete May delete file             May delete direcory                           */
   #define OTHER_Execute 0x00000001
   #define OTHER_Write   0x00000002
   #define OTHER_Read    0x00000004
   #define OTHER_ChAttr  0x00000008
   #define OTHER_Delete  0x00000010
　 #define GROUP_Execute 0x00000020
   #define GROUP_Write   0x00000040
   #define GROUP_Read    0x00000080
   #define GROUP_ChAttr  0x00000100
   #define GROUP_Delete  0x00000200
   #define OWNER_Execute 0x00000400
   #define OWNER_Write   0x00000800
   #define OWNER_Read    0x00001000
   #define OWNER_ChAttr  0x00002000
   #define OWNER_Delete  0x00004000

セキュリティ情報を扱う許可条件の概念は，オペレーティングシステム間で完全には移植可能でない。この標準情報(TR)では，次に示す基本的な課題に言及することによって，許可条件ビットを処理する処理システム間で一貫性を保持する。

• 1) オペレーティングシステムが利用者ID及びグループIDの概念をもたない場合，所有者, グループ及びその他の許可条件をどのように処理システムが扱うのが望ましいのか？
• 2) オペレーティングシステムが利用可能にする許可条件ビットに直接配置していない特定の許可条件ビットがある場合，処理システムはどのように許可条件ビットを処理するのが望ましいのか？
• 3) 新しいファイルを作成するときに，オペレーティングシステムが利用可能にする許可条件ビットに直接配置 していない許可条件に関してはどのようなデフォルト値を用いるのが望ましいのか？

a) 利用者，グループ及びその他

一般に，利用者ID及びグループIDを利用可能にしないオペレーティングシステムでは，許可条件ビットを処理するとき，次に示すアルゴリズムを使用する。

• 1) 特定の許可条件を読み出す場合，すべての三つ(所有者，グループ及びその他)の許可条件の論理和で値を検査するのが望ましい。例えば，OWNER_Write, GROUP_Write及びOTHER_Writeの論理和がONEに等しかった場合，ファイルは書込み可能を示す。
• 2) 特定の許可条件を設定する場合，処理システムは許可条件ビットの三つ(所有者，グループ及びその他)の集合を設定するのが望ましい。例えば，書込み可能なファイルを示す場合，OWNER_Write,GROUP_Write及びOTHER_Writeをすべて値ONEに設定するのが望ましい。

b) デフォルト許可値(Default Permission Values)

次の表では，この標準情報(TR)で扱うオペレーティングシステムに関して，新しいファイルを作成するとき，オペレーティングシステムが利用可能な許可条件ビットに直接配置しない許可条件ビットに，どのようなデフォルト値を使用するのが望ましいかを記述している。

表3.1 許可条件

U - 利用者指定，1 - 設定，0 - 除去

許可	ファイル/ディレクトリ	記述	DOS	OS/2	Win95	WinNT	MacOS	UNIX
読出し	ファイル	ファイルを読み出してもよい。	1	1	1	1	1	U
読出し	ディレクトリ	ディレクトリが実行の表示がある場合だけ，読み出してもよい。	1	1	1	1	1	U
書込み	ファイル	ファイルの内容を修正してもよい。	U	U	U	U	U	U
書込み	ディレクトリ	ディレクトリが実行の表示がある場合だけ，ファイル又は，サブディレクトリは，名前を変更したり，加えたり，削除してもよい。	U	U	U	U	U	U
実行	ファイル	ファイルは実行してもよい。	0	0	0	0	0	U
実行	ディレクトリ	ディレクトリの許可条件は，変更してもよい。	1	1	1	1	1	U
属性	ファイル	ファイルの許可条件は変更してもよい。	1	1	1	1	1	備考1
属性	ディレクトリ	ディレクトリの許可条件は変更してもよい。	1	1	1	1	1	備考1
削除	ファイル	ファイルは削除してもよい。	備考2	備考2	備考2	備考2	備考2	備考2
削除	ディレクトリ	ディレクトリは削除してもよい。	備考2	備考2	備考2	備考2	備考2	備考2

 備考1 UNIXでは，ファイル/ディレクトリの所有者だけが，その属性を変更してもよい。

 備考2 削除許可条件ビットは，書込み許可条件ビットの状態を基に設定するのが望ましい。DOS，OS/2及びMacintoshでは，ファイル又はディレクトリに書込みの表示が出たら(書込み許可条件設定)，ファイルは削除可能と考えられ，削除許可条件ビットを設定するのが望ましい。ファイルが再生専用の場合，削除許可条件ビットを設定するのは望ましくない。これは，ファイル作成とファイルの属性変更にも適用する。

c) 許可条件処理(Processing Permisstions)

この標準情報(TR)で扱うオペレーティングシステムにおいて，許可条件ビットの処理法を記述する表3.2に従って，処理システムは許可条件ビットを処理する。この表は，オペレーティングシステムが利用可能な許可条件ビットに直接配置していない許可条件ビットに関連する項目を示す。

表3.2 各OSの許可条件ビット処理

E - 実施する, I - 無視する

許可	ファイル/ディレクトリ	記述	DOS	OS/2	Win95	WinNT	MacOS	UNIX
読出し	ファイル	ファイルを読み出してもよい。	E	E	E	E	E	E
読出し	ディレクトリ	ディレクトリを読み出してもよい。	E	E	E	E	E	E
書込み	ファイル	ファイルの内容を更新してもよい。	E	E	E	E	E	E
書込み	ディレクトリ	ファイル又はディレクトリを作成，削除又は名前変更してもよい。	E	E	E	E	E	E
実行	ファイル	ファイルを実行してもよい。	I	I	I	I	I	E
実行	ディレクトリ	ファイル又はサブディレクトリを規定するために，ディレクトリを検索してもよい。	E	E	E	E	E	E
属性	ファイル	ファイルの許可条件を変更してもよい。	E	E	E	E	E	E
属性	ディレクトリ	ディレクトリの許可条件を変更してもよい。	E	E	E	E	E	E
削除	ファイル	ファイルを削除してもよい。	E	E	E	E	E	E
削除	ディレクトリ	ディレクトリを削除してもよい。	E	E	E	E	E	E

検索ビットとしてときどき参照するディレクトリの実行ビットは，特別な意味をもつ。このビットは，ディレクトリの検索を可能にするが，その内容を一覧表示できるわけではない。例えば，実行許可条件だけを設定し，さらに読出し許可条件ビットを設定しないPRIVATEと呼ぶディレクトリがある場合，ディレクトリPRIVATEの内容は，一覧表示できない。PRIVATEディレクトリ中にREADMEと呼ぶ一つのファイルがあると仮定する。利用者は，PRIVATEディレクトリが検索可能であるため，READEファイルにアクセスできる。

ディレクトリの内容を一覧表示するためには，読出し許可条件ビット及び実行許可条件ビットの両方をディレクトリに設定しなければならない。ファイル又はサブディレクトリの作成，削除及び名前変更をするためには，書込み許可条件ビット及び実行許可条件ビットの両方をディレクトリに設定しなければならない。 ディレクトリに対する実行ビットをもっとよく理解するためには，ファイル及びディレクトリの許可条件を扱うUNIXの文献を参照のこと。ディレクトリの実行ビットに定義する規則は，すべての処理システムで実施するものとする。この規則はMacintoshの処理システムには該当しない。Macintoshの処理システムではディレクトリのアクセス可能性を決定する際，読み出しビットの状態を無視してもよい。

 備考 ファイル又はサブディレクトリを削除するには，ファイル又はサブディレクトリの削除許可条件ビットが設定されており，ファイル又はサブディレクトリを含むディレクトリには，書込み許可条件ビット及び実行許可条件ビットの両方が設定されていなければならない。

3.3.3.4 一意ID(Uint64 UniqueID)

 備考 いくつかのオペレーティングシステム(例えばMacintosh)に関しては，この値はInt32の最大値(2³¹-1)より小さくする必要がある。Macintoshオペレーティングシステムでは，この値はMacintoshのディレクトリID又はファイルIDを表すために使用する。そのために，処理システムはInt32の最大値(2³¹-1)より小さい値であることが望ましい。値1〜15は，Macintosh用に確保するものとする。

3.3.3.5 拡張属性 (byte Extended Attributes)

拡張属性は，実行処理のためにファイルエントリのこの欄に記録するのが望ましい。他の拡張属性は，拡張属性ICB欄で指示するICBに記録するのが望ましい。拡張属性の節では，この欄に記録するのが望ましい拡張属性について規定する。

3.3.4 拡張属性(Extended Attributes)

長さの変更が可能ないくつかの長拡張属性(EAs)を扱うために，次に示す規則をEA空間に適用する。

• a) 一つの論理ブロック以上の属性長をもつすべてのEAsは，論理ブロック境界で開始し，論理ブロック境界で終了するブロック列とする。
• b) より短いEAsは，4バイト単位の属性長とする。
• c) 各拡張属性空間は，次に示す構成のうち，一つの連続論理空間を表すものとする。
  • JIS X 0607の拡張属性
  • ブロック境界でない処理システム用拡張属性
  • ブロック境界の処理システム用拡張属性
  • 応用プログラム用拡張属性

 備考 ファイルごとに，二つの拡張属性空間が存在してもよい。一方はファイルエントリ又は拡張ファイルエントリに埋め込まれ，他方は，ファイルエントリ又は拡張ファイルエントリ内の拡張属性ICB番地によってアクセスされる分離空間とする。各拡張属性空間が存在する場合は，独自の拡張属性ヘッダ記述子をもたなければならない。(次節を参照。)

3.3.4.1 拡張属性ヘッダ記述子(Extended Attribute Header Descriptor)

    struct ExtendedAttributedHeaderDescriptor{  /*ECMA 167 4/14.10.1*/
          struct tag   DescriptorTag;
          Uint32       ImplementationAttributesLocation;
          Uint32       ApplicationAttributesLocation;
    }

• a) 意味 前述の処理システム拡張位置欄の一つの値が，拡張属性空間の長さと同等であるか，それより大きいものは，対応する属性が存在しないと解釈するものとする。
• b) 設定値 前述の処理システム拡張位置欄の一つに関係している属性が存在しない場合，対応する位置欄の値は#FFFFFFFFに設定するものとする。

3.3.4.2 代替許可条件(Alternate Permissions)

    struct AltematePermissionsAttribute{ /*ECMA 167 4/14.10.4*/
           Uint32    AttributeType;
           Uint8     AttributeSubtype;
           byte      Reserved[3];
           Uint32    AttributeLength;
           Uint16    OwnerIdentification;
           Uint16    GroupIdentification;
           Uint16    Permission;
    }

この構造は記録してはならない。

3.3.4.3 ファイル日時拡張属性(File Times Extended Attribute)

    struct FileTimeExtendedAttribute{  /*ECMA 167 4/14.10.5*/
          Uint32     AttributeType;
          Uint8      AttributeSubtype;
          byte       Reserved[3];
          Uint32     AttributeLength;
          Uint32     DataLength;
          Uint32     FileTimeExistence;
          byte       FileTimes;
    }
)

3.3.4.3.1 ファイル日時(byte FileTimes)

• a) 意味 この欄にファイル作成日時が含まれている場合，関連ファイルの作成日時と解釈するものとする。主ファイルエントリが拡張ファイルエントリである場合，この構造のファイル作成日時は無視し，主ファイルエントリのファイル作成日時を使用しなければならない。
• b) 設定値 主ファイルエントリが拡張ファイルエントリである場合，この構造は，ファイル作成日時を記録してはならない。

主ファイルエントリが拡張ファイルエントリではなく，ファイル日時拡張属性が存在しない場合，又はファイル作成日時を含まない場合，処理システムでは，ファイル作成日時を表すために，ファイルエントリの訂正日時欄を使用しなければならない。

3.3.4.4 装置仕様の拡張属性(Device Specification Extended Attribute)

    struct DeviceSpecificationExtendedAttribute{  /*ECMA 167 4/4.10.7*/
           Uint32     AttributeType;
           Uint8      AtrributeSubtype;
           byte       Reserved[3];
           Uint32     AttributeLength;
           Uint32     ImplementationUseeLength;  /* (=IU_L) */
           Uint32     MajorDeviceIdentification;
           Uint32     MinorDeviceIdentification;
           byte       ImplementationUse[IU_L];
    }

次に示す規範は，ファイルに関連する装置仕様拡張属性を作成する処理システムに従うものとする。

a) ファイルが関連する装置仕様拡張属性をもつ場合，icbtag構造中のファイル種別欄の内容は，値6(ブロック特殊装置ファイルを示す)又は値7(文字特殊装置ファイルを示す)を指定する。

b) icbtag構造中のファイル種別欄の内容が値6又は値7でない場合，ファイルに関連する装置仕様拡張属性は無視する。

c) icbtag構造中のファイル種別欄内容が値6又は値7に等しく，ファイルに関連する装置仕様拡張属性がない場合，ファイルへのアクセスは拒否するものとする。

d) ブロック特殊装置ファイルに関連する解釈方法を規定しないオペレーティングシステム環境において，関連する装置仕様拡張属性をもつファイルへのopen/read/write/close要求は拒否するものとする。

e) 処理システムは，現状の処理システムを識別するdeveloperIDを処理システム用欄に記録するものとする。

3.3.4.5 処理システム用拡張属性(Implementation Use Extended Attribute)

    struct ImplementationUseExtendedAttribute{  /*ECMA 167 4/14.10.8    */
           Uint32        AttributeType;
           Uint8         AttributeSubtype;
           byte          Reserved[3];
           Uint32        AttributeLength;
           Uint32        ImplementationUseLength; /* (=IU_L) */
           struct EntityID  ImplementationIdentifier;
           byte          ImplementationUse[IU_L];
    }

属性長欄(Attribute Length)は，全体の拡張属性の長さを指定する。処理システム用拡張属性の使用を定義する可変長の拡張属性に関して，属性長欄には，処理システム用(Implementation Use)欄の最後及び処理システム用拡張属性の最後との間に埋め込み空間を残すのに，十分な大きさを指定するのが望ましい。

次の節は，オペレーティングシステム固有の拡張属性を記録するために，いろいろなオペレーティングシステムで処理システム用拡張属性を使用する方法を記述する。

次の節に定義する構造は，ヘッダチェックサム欄を含む。この欄は，処理システム用拡張属性ヘッダの16ビットチェックサムを表す。 属性種別から処理システム識別子までの欄を，チェックサムで保護するデータとして表す。ヘッダチェックサム欄は，拡張属性空間の障害回復の支援として使う。ヘッダチェックサムのためのCのソースコードを附属書に示してもよい。

 備考 すべての適合する処理システムでは，媒体中の既存の拡張属性を保存するものとする。処理システムは，動作中のオペレーティングシステムに関する拡張属性を作成し，利用可能にするものとする。例えば，Macintosh処理システムでは，媒体中に存在するOS/2拡張属性を保存するものとする。また，この標準情報(TR)に規定するすべてのMacintosh拡張属性を作成し，利用可能にするものとする。

3.3.4.5.1 すべてのオペレーティングシステム(All Operating System)

3.3.4.5.1.1 空きEA空間(FreaaEAspace)

この拡張属性は，拡張属性空間で未使用な空間を示すために使用するものとする。この拡張属性は，処理システム用拡張属性として記録しなければならない。その処理システム用拡張属性の処理システム識別子は,

"*UDF FreeEASpace"

この拡張属性の処理システム用領域は，表3.3に示す構成とする。

表3.3 空きEA空間のフォーマット

RBP	長さ	名前	内容
0	2	ヘッダチェックサム	Uint16
2	IU_L-1	空きEA空間	バイト

この拡張属性は，拡張属性空間のすべてを再度書き込むことなく，処理システムが他の拡張属性を縮小又は拡大することを可能にする。空きEA空間の拡張属性は上書きしてもよく，上書きを必要とする処理システムがその空間を再利用してもよい。

3.3.4.5.1.2 DVD著作権管理情報(DVD Copyright Management Information)

この拡張属性は，DVD著作権管理情報を示すために使用するものとする。この拡張属性は，処理システム用拡張属性として記録しなければならない。その処理システム用拡張属性の処理システム識別子は,

"*UDF DVD CGMS Info"

この拡張属性の処理システム用領域は，表3.4に示す構成とする。

表3.4 DVD CGMS Infoのフォーマット

RBP	長さ	名前	内容
0	2	ヘッダチェックサム	Uint16
2	1	CGMS情報	バイト
3	1	データ構造種別	Uint8
4	4	保護システム情報	バイト

この拡張属性は，DVD著作権管理情報の記録を可能にする。このフォーマットの解釈は，DVDコンソーシアム(6.9.3を参照)が出版するDVD規定で定義するものとする。この拡張属性を利用可能にすることは，オプションとする。

3.3.4.5.2 MS-DOS，Windows95，WindowsNT

• a) 意味 無視する。
• b) 設定値 サポートしない。媒体中の既存ファイルの拡張属性は保存するものとする。

3.3.4.5.3 OS/2

OS/2は，制限のない個数の拡張属性を利用可能にする。これらの拡張属性は，3.3.8.2に定義するとおり，名前付きストリームとして記録するものとする。性能を高めるために，次に示す処理システム用拡張属性を作成する。

3.3.4.5.3.1 OS/2拡張属性長(OS2EALength)

この拡張属性は，OS/2拡張属性ストリーム(3.3.8.2)情報の長さを規定する。この値は，ディレクトリ操作でOS/2に通知する必要があるため，効率上の理由から，ファイルエントリの拡張属性欄に記録するのが望ましい。この拡張属性は，処理システム識別子に

"*UDF OS/2 EALength"

この拡張属性の処理システム用領域は，表3.7に示す構成とする。

表3.5 OS/2拡張属性長フォーマット

RBP	長さ	名前	内容
0	2	ヘッダチェックサム	Uint16
2	4	OS/2拡張属性長	Uint32

OS/2拡張属性長欄に記録する値は，OS2EAストリームのファイルエントリの情報長欄に一致しなければならない。

3.3.4.5.4 Macintosh OS

Macintosh OSは，次に示す四つの拡張属性の利用を要求する。

3.3.4.5.4.1 Macintoshボリューム情報(MacVolumeInfo)

この拡張属性は，Machintoshボリューム情報を含み，処理システム用識別子に

"*UDF Mac VolumeInfo"

この拡張属性の処理システム用領域は，次に示す構成とする。

表 3.6 Macintoshボリューム情報フォーマット

RBP	長さ	名前	内容
0	2	ヘッダチェックサム	Uint16
2	12	最後の更新日時	timestamp
14	12	最後のバックアップ日時	timestamp
26	32	ボリュームファインダ情報	Uint32

Macintoshボリューム情報の拡張属性は，ルートディレクトリのファイルエントリの拡張属性として記録するものとする。

3.3.4.5.4.2 Macintoshファインダ情報(MacFinderInfo)

この拡張属性は，関連ファイル又はディレクトリのMacintoshファインダ情報を含む。この情報は頻繁にアクセスするため，効率上の理由からファイルエントリの拡張属性欄に記録するのが望ましい。

Macintoshファインダ情報の拡張属性は，処理システム識別子に

"*UDF Mac FinderInfo"

この拡張属性の処理システム用領域は，次に示す構成とする。

表3.7 ディレクトリに対するMacintoshファインダ情報フォーマット

RBP	長さ	名前	内容
0	2	ヘッダチェックサム	Uint16
2	2	埋込み(=0)	Uint16
4	4	親ディレクトリID	Uint32
8	16	ディレクトリ情報	UDFDInfo
24	16	ディレクトリ拡張情報	UDFDXInfo

表3.8 ファイルに対するMacintoshファインダ情報フォーマット

RBP	長さ	名前	内容
0	2	ヘッダチェックサム	Uint16
2	2	埋込み(=0)	Uint16
4	4	親ディレクトリID	Uint32
8	16	ファイル情報	UDFFInfo
24	16	ファイルの拡張情報	UDFFXInfo
40	4	リソースフォークデータ長	Uint32
44	4	リソースフォーク割付け長	Uint32

Macintoshファインダ情報の拡張属性は，論理ボリューム中のすべてのファイル及びディレクトリの拡張属性として記録するものとする。

Macintoshファインダ情報中で使用する次に示す構造は，明確化のために表3.11〜表3.16で示す。これらの構造の完全な情報については，"Inside Macintosh"と呼ぶMacintoshの文献を参照のこと。各構造のボリューム及びページ番号は, "Inside Macintosh"固有のボリューム及びページに対応する。

表3.9 UDFPointフォーマット(ボリュームI, 139ページ)

RBP	長さ	名前	内容
0	2	V	Int16
2	2	H	Int16

表3.10 UDFRectフォーマット(ボリュームI, 141ページ)

RBP	長さ	名前	内容
0	2	Top	Int16
2	2	Left	Int16
4	2	Bottom	Int16
6	2	Right	Int16

表3.11 UDFDInfoフォーマット(ボリュームIV, 105ページ)

RBP	長さ	名前	内容
0	8	FrRect	UDFRect
8	2	FrFlags	Int16
10	4	FrLocation	UDFPoint
14	2	FrView	Int16

表3.12 UDFDXInfoフォーマット(ボリュームIV, 106ページ)

RBP	長さ	名前	内容
0	4	FrScroll	UDFPoint
4	4	FrOpenChain	Int32
8	1	FrScript	Uint8
9	1	FrXflags	Uint8
10	2	FrComment	Int16
12	4	FrPutAway	Int32

表3.13 UDFFInfoフォーマット(ボリュームII, 84ページ)

RBP	長さ	名前	内容
0	4	FdType	Uint32
4	4	FdCreator	Uint32
8	2	FdFlags	Uint16
10	4	FdLocation	UDFPoint
14	2	FdFldr	Int16

表3.14 UDFFXInfoフォーマット(ボリュームII, 105ページ)

RBP	長さ	名前	内容
0	2	FdIconID	Int16
2	6	FdUnused	バイト
8	1	FdScript	Int8
9	1	FdXFlags	Int8
10	2	FdComment	Int16
12	4	FdPutAway	Int32

 備考 簡単に前述した構造は，元のMacintosh構造と実際に異なることを示すために，"UDF"が先行する元のMacintosh名をもつ。媒体中では，ビッグエンディアン形式の元のMacintosh構造に対して，UDF構造ではリトルエンディアンで記録する。

3.3.4.5.5 UNIX

• a) 意味 無視する。
• b) 設定値 サポートしない。媒体上の既存ファイルの拡張属性は保存しなければならない。

3.3.4.6 アプリケーション用拡張属性(Application Use Extended Attribute)

    struct ApplicationUseExtendedAttribute{  /*ECMA 167 4/14.10.9    */
           Uint32        AttributeType;    /* 65536 */
           Uint8         AttributeSubtype;
           byte          Reserved[3];
           Uint32        AttributeLength;
           Uint32        ApplicationUseLength; /* (=AU_L) */
           struct EntityID  ApplicationIdentifier;
           byte          ApplicationUse[IU_L];
    }

属性長欄(Attribute Length)は，全体の拡張属性の長さを指定する。アプリケーション用拡張属性の使用を定義する可変長の拡張属性に対して，属性長欄には，アプリケーション用(Application Use)欄の最後及びアプリケーション用拡張属性の最後との間に埋め込み空間を残すのに，十分な大きさを指定するのが望ましい。

次の節に定義する構造は，ヘッダチェックサム欄を含む。この欄は，アプリケーション用拡張属性ヘッダの16ビットチェックサムを表す。 属性種別からアプリケーション識別子までの欄を，チェックサムで保護するデータとして表す。ヘッダチェックサム欄は，拡張属性空間の障害回復の支援として使う。ヘッダチェックサムのためのCのソースコードを附属書に示してもよい。

 備考 すべての適合する処理システムでは，媒体中の既存の拡張属性を保存しなければならない。処理システムは，動作中のオペレーティングシステムに対する拡張属性を作成し，利用可能にしなければならない。例えば，Macintosh処理システムでは，媒体中に存在するOS/2拡張属性を保存しなければならない。この標準情報(TR)に規定するすべてのMacintosh拡張属性をも作成し，利用可能にしなければならない。

3.3.4.6.1 すべてのオペレーティングシステム(All Operating Sytsem)

この拡張属性は，拡張属性空間でアプリケーション用拡張属性に確保された未使用な空間を示すために使用するものとする。この拡張属性は，アプリケーション識別子に

"*UDF FreeAppEASpace"

この拡張属性のアプリケーション用領域は，次に示す構成とする。

表3.15 FreeAppEASpaceのフォーマット

RBP	長さ	名前	内容
0	2	ヘッダチェックサム	Uint16
2	IU_L-1	空きEA空間	バイト

この拡張属性は，拡張属性空間のすべてを再度書き込むことなく，処理システムが他の拡張属性を縮小又は拡大することを可能にする。FreeAppEASpaceの拡張属性は上書きしてもよく，上書きを必要とする処理システムがその空間を再利用してもよい。

3.3.5 名前付きストリーム(Named Stream)

名前付きストリームはファイルの関連データを関連付ける機構を提供する。この機構は，概念的に拡張属性に類似している。しかし，名前付きストリームは, 拡張属性よりもはるかに優れている。名前付きストリームには, 長さの制限がない。各ストリームは独自の空間をもつため，拡張属性の共通空間よりもはるかに空間管理を行い易い。特定のストリームを見つけるのに，拡張属性の場合に必要であったデータ空間全体の検索は行わない。

名前付きストリームは, 主に利用者データを対象にする。例えば，データベースアプリケーションは，レコードをデフォルトストリーム又は主ストリームに記録してよく，索引を名前付きストリームに記録してよい。そこで利用者は, 多くのファイルではなくデータベース用の一つのファイルだけを見ることになり，アプリケーションは，多様なストリームをあたかも独立したファイルとして使用できる。

名前付きストリームは，拡張ファイルエントリによって識別する。拡張ファイルエントリは，関連付けられた名前付きストリームをもつファイルに必要となる。名前付きストリームをもたないファイルは，拡張ファイルエントリを使用するのが望ましい。ファイルは通常のファイルエントリを含んでもよい。通常のファイルエントリは，DVDビデオディスクの書込みなどの下位互換性が必要な場合に使われる。

ファイル集合記述子によって識別されるストリームディレクトリであるシステムストリームディレクトリがある。これらのストリームは，ファイルに関連するデータではなく，媒体全体に関連するデータを記述するために使用する。UDFは，システムストリームディレクトリによって識別される幾つかのシステムストリームを定義する。

名前付きストリームは，新しい処理システムにおいて，拡張属性ではなく，メタデータ及びアプリケーションデータを記録するのに使うことを推奨する。

3.3.5.1 名前付きストリームの制約(Named Stream Restrictions)

JIS X 0607はその追補1と共に，ストリームディレクトリを識別する欄を含む，新しいファイルエントリを定義している。新しいファイルエントリは, 古いファイルエントリの代わりに用い，ストリーム自体を記述するのに用いるのが望ましい。新旧のファイルエントリは，自由に混合してもよい。特に，古い再生用の処理システムとの互換性は，特定のファイルのために保守され得る。

制約

a) ストリームディレクトリ又は名前付きストリームを記述するICBの，ストリームディレクトリICB欄はZEROに設定しなければならない。[階層的なストリームではない。]

b) 各名前付きストリームは，厳密に一つのストリームディレクトリにおける，厳密に一つのFIDによって識別しなければならない。[名前付きストリーム又はファイルとのハードリンク(hard link)ではない。]

c) 各ストリームディレクトリICBは，厳密に一つのストリームディレクトリICB欄によって識別されなければならない。[ストリームディレクトリへのハードリンクではない。]

d) 名前付きストリームをもつファイルへのハードリンクは, 許容される。

e) 名前付きストリーム及びストリームディレクトリは, 拡張属性をもってはならない。

f) 名前付きストリーム及びストリームディレクトリの一意ID欄はZEROに設定し，読み取るときは無視するものとする。名前付きストリーム又はストリームディレクトリの一意IDは，主データストリームの一意IDと同等だと考えるものとする。

g) 主ファイルエントリのUID，GID及び許可条件の欄は，主ストリームに関連付けられたすべての名前付きストリームに適用する。名前付きストリームの作成時に，主ファイルエントリのUID，GID及び許可条件の欄の値は，名前付きストリームの対応する欄のデフォルト値として使用するのが望ましい。処理システムは，名前付きストリームのこれらの欄を保守又はチェックする必要はない。

h) 処理システムは，FIDの中でセットされたメタデータビットでマーク付けされたストリームを利用者に示さないことが望ましい。メタデータビットでマーク付けされたストリームは，ファイルシステムの実装での使用だけを目的とする。

i) ストリームディレクトリにおける親エントリFIDは，主拡張ファイルエントリを指示し，したがって，その参照は，拡張ファイルエントリのLink Count欄で数えなければならない。

 備考 ファイル/ディレクトリの削除に際しては，次の危険があり得る。FIDが削除されるときに，リンクカウントが1になると，処理システムでは，ストリームディレクトリの存在をチェックしなければならない。ストリームディレクトリが存在すると，このファイルエントリを示すFIDはもはやない。したがって，それと関連する構造は, すべて削除されなければならない。

j) 主拡張ファイルエントリの訂正日時欄は，関連する名前付きストリームの訂正時には必ず更新するのが望ましい。主拡張ファイルエントリのアクセス日時欄は，関連する名前付きストリームへのアクセス時には必ず更新するのが望ましい。主拡張ファイルエントリにおけるICBタグフラグ欄のSETUIDビット及びSETGIDビットは，関連する名前付きストリームの訂正時には必ずクリアするのが望ましい。

k) 名前付きストリームディレクトリのICBは，ファイル種別13をもつのが望ましい。名前付きストリームは, すべてファイル種別5をもたなければならない。

l) すべてのシステムは, 名前付きストリームを実装していない実装システムにおいても, 主データストリームを利用可能にしなければならない。

3.3.5.2 システム名前付きストリーム(メタデータ)[System Named Stream (Metadata)]

名前付きストリームの集合は，ファイルシステム用にUDFによって規定する。UDF名前付きストリームの中には，ファイル集合記述子によって識別され，ファイル集合全体(システムストリームディレクトリ)に適用されるものもある。他のUDF名前付きストリームは, 個々のファイル又はディレクトリに属し，ストリームディレクトリによって識別子される。

UDF名前付きストリームはすべて，この標準情報(TR)で特記しない限り，ストリームディレクトリのファイル識別記述子においてセットされたメタデータビットをもつものとする。ファイルシステムの実装によって生成されないストリームはすべて，このビットをZEROに設定するものとする。

UDF名前付きストリームはすべて，ストリームを識別するICBにファイル種別5をもつものとする。

4文字の*UDFは，この標準情報(TR)におけるUDF定義のすべての名前付きストリームの最初の4文字とする。処理システムは，この標準情報(TR)で規定していない名前付きストリームに，*UDFで始まる識別子を使用してはならない。*UDFで始まる名前付きストリームのためのすべての識別子は，OSTAによる将来の定義のために確保される。

3.3.6 名前付きストリームとしての拡張属性(Extended Attributes as Named Stream)

名前付きストリームの代わりに拡張属性を記録してよい。拡張属性は, 次の規則に従って変換される。

a) ストリームは, メタデータストリームとしてマーク付けされる。

b) 拡張属性のヘッダ及びヘッダチェックサムは, 記録されない。拡張属性が，ヘッダチェックサムと残りのデータとの間にパッドバイトを含んでいたら，これらも記録されない。ファイル又はディレクトリの拡張属性は，次のアルゴリズムによって，同じファイル又はディレクトリのストリームに変換できる。

• 1) 拡張属性を含むファイル又はディレクトリのためのストリームを作成する。実体識別子に指定される識別子が，ストリーム名になる。
• 2) 拡張属性のデータをストリームにコピーする。
• 3) 拡張属性を消去する。

3.3.7 UDF定義のシステムストリーム(UDF Defined System Streams)

この節は，UDF定義のシステムストリームの規定を含む。

表3.16

ストリーム名	ストリーム位置	メタデータフラグ
“*UDF Unique ID Mapping Data”	システムストリームディレクトリ(ファイルセット記述子)	1
“*UDF Non-Allocatable Space”	システムストリームディレクトリ(ファイルセット記述子)	1
“*UDF Power Cal Table”	システムストリームディレクトリ(ファイルセット記述子)	1
“*UDF Backup”	システムストリームディレクトリ(ファイルセット記述子)	1

表3.16に列挙されたストリームは，メタデータフラグ集合を備えているので，処理システムは，プラットフォームのプラグインファイルシステムインタフェースを介してストリームの名前を通してはならない。

3.3.7.1 一意IDマッピングデータストリーム(Unique ID Mapping Data Stream)

一意IDマッピングデータは，処理システムが，UDF一意IDに関連付けられたファイル/ディレクトリのICB階層に直接進むことを可能にし，又はUDF一意IDに関連付けられたファイル/ディレクトリを含むディレクトリのICB階層に進むことを可能にする。一意IDマッピングデータは，(ファイル集合記述子に関連付けられた)システムストリームディレクトリの名前付きストリームとして記録される。このストリームの名前は

"*UDF Unique ID Mapping Data"

ファイル識別記述子のファイル特性欄の中のメタデータビットは，プラットフォームのファイルシステムインタフェースのクライアントに，このファイルの存在を知らせないことが望ましいことを示すため，1に設定しなければならない。

• a) 再生専用媒体のために作成されなければならない。
• b) 追記形及び書換可能形媒体にボリュームをバッチ書込みする処理システム(例えば，プリマスタリングツール)によって作成されなければならない。
• c) 追記形又は書換可能形媒体(例えば，オンラインファイルシステム)にボリュームの増加的更新をする処理システムには，次の規則を適用する。
  • 1) 存在しない場合は，作成し，保守してよい。
  • 2) 存在しており，ボリュームが汚れていない場合，保守するものとする。
  • 3) 存在しているが，ボリュームが汚れている場合，修復し保守することが望ましいが，消去してもよい。
  • 4) これらの規則に関して，有効な閉じた論理ボリューム保全記述子，又は有効な仮想番地表のいずれかが記録されれば，ボリュームは汚れていない。

3.3.7.1.1 UDF一意IDマッピングデータ(UDF Unique ID Mapping Data)

表3.17 UDF一意IDマッピングデータ

RBP	長さ	名前	内容
0	32	処理システム識別子	実体ID
32	4	フラグ	Uint32
36	4	マッピングエントリカウント(=MEC)	Uint32
40	8	予備	バイト(=#00)
48	16*MEC	マッピングエントリ	IDマッピングエントリ

処理システム識別子は, [2.1.5への相互参照]に記述されている。

フラグは, 次のとおりに規定される。

• a) ビット0は，ONEに設定するとき，UDF一意IDを意味するものとし，16(次の一意IDが初期設定される値)ずつ減らす場合，配列マッピングエントリの項目として使用できる。空白のエントリは, もしそれがあると，UDF一意IDをもつ最後の配列要素を越えることはない。
• b) 予備のビット1〜31は, ZEROに設定するものとする。

マッピングエントリカウントは，配列マッピングエントリの，エントリにおける大きさとする。

マッピングエントリは，UDF一意IDマッピングエントリ構造の配列とする。非ストリームの親でないファイル識別記述子ごとに，一つのマッピングエントリがある。ボリュームが一致していれば，常に配列は，UDF一意IDの昇順にソートされる。フラグで制限される場合を除いて，空白エントリは，配列のどの位置でも可能であり，エントリは，直前のエントリより一つ大きいUDF一意IDの値をもつ必要はない。空白エントリは, すべての欄でZEROの値をもつ。

3.3.7.1.2 UDF一意IDマッピングエントリ(UDF Unique ID Mapping Entry)

ストリームの内容は，"UDF一意IDマッピングエントリ"の配列の前にヘッダ欄を含む"UDF一意IDマッピングデータ"表によって示す。構造の欄は, 次の対応表によって示される。

表3.18 UDF一意IDマッピングエントリ

RBP	長さ	名前	内容
0	4	UDF一意ID	Uint32
4	4	親論理ブロック番号	Uint32
8	4	対象論理ブロック番号	Uint32
12	2	親区画参照数	Uint16
14	2	対象区画参照数	Uint16

UDF一意IDは，ファイル又はディレクトリに関するFIDの値とする。

親論理ブロック番号は，対象を識別するFIDを含むディレクトリを識別するICBの論理ブロック番号とする。

対象論理ブロック番号は，この対象を識別するICBの論理ブロック番号とする。

親区画参照番号は，このファイル又はディレクトリ用のFIDを含む，同一のディレクトリの親におけるICB欄のlong_adからの区画参照番号とする。

対象区画参照番号は，このUDF一意IDをもつFIDのICB欄のlong_adからの区画参照番号とする。

3.3.7.2 割付け禁止空間ストリーム(Non-Allocatable Space Stream)

JIS X 0607は，媒体の欠陥領域を記述したり，ファイルシステム以外の割付けのために使用できない領域を記述する機構を規定しない。割付け禁止空間ストリームは，ファイルシステムが使用できない空間を記述するための方法を提供する。割付け禁止空間ストリームは，欠陥管理をしない媒体システム(例えば，CD-RW)だけに記録されなければならない。

割付け禁止空間ストリームは, 初期化時に生成されなければならない。割付け禁止空間ストリームが示す空間も, すべて自由空間マップで割り付けられたとしてマーク付けされるものとする。割付け禁止空間ストリームは，ファイル集合記述子のシステムストリームディレクトリで名前付きストリームとして記録するものとする。ストリーム名は, 次のとおりとする。

"*UDF Non-Allocatable Space"

ストリームは, 属性メタデータ(ONEに設定されたファイル特性集合の4ビット)及びシステム(ONEに設定されたICBフラグ欄の10ビット)でマーク付けされるものとする。このストリームは，割り付けエクステントが識別するすべての割付け禁止セクタをもつものとする。割付けエクステントは，各エクステントが割り付けられるが記録されないことを示すものとする。このリストには，初期化時の欠陥セクタと初期化時に予備のため割り付けられる空間との両方が含まれるものとする。

3.3.7.3 パワー較正ストリーム(Power Calibration Stream)

CD-Rドライブのパケットライト機能を効果的に利用する際にあり得る制約の一つに，現CD-R媒体で利用可能な，パワー較正領域の限られた数(100)がある。これらのパワー較正領域は，ドライブに現在入っているCD-Rディスクに，データを確実にうまく書込める適切なパワー較正設定を確立するのに使われる。特定のドライブのための適切な設定値は，同一の製造及び型をもつ二つの異なるドライブ間で異なり，同一のディスク，ドライブ，システム構成を使っても，環境条件が異なれば，ディスク間で大きく異なる。

このため，ほとんどの現在のCD-Rドライブは，媒体変更が起きた後の最初の書込みが行われようとするときに, 較正し直す。ディスクアトワンス又はトラックアトワンスのモードを使って記録する場合には，これが制約を課することはない。それは, これらの各モードでは，100回に満たない各書込みでディスクが(利用可能なデータ容量をすべて使い，又は記録可能なトラック数をすべて使って)一杯になることによる。しかしパケットライトを使うと，ディスクはディスクが一杯になるまで，長期間に亘って，何千回も書込むことができる。

例えば，仮に，各作業日の最後に新規ファイル及び/又は訂正ファイルを増加的にバックアップしたいとする(ドライブは同じ日に他の仕事で断続的に使われるかもしれないが)。これらのバックアップには，1日に1MB(又はそれ以下)程度の書込みが必要かもしれない。毎日ディスクに書込みする前に，パワー較正領域の一つがドライブの較正に使われれば，5ヶ月以内にパワー較正領域はすべて使用されるだろうが，消費されるのは，ディスクの全容量の断片的な部分だけとする。その結果は，それらの製品の利用者が予期しないことであり，受け入れられそうもない。

業界では，CD-Rディスクのパワー較正領域を使わなければならない，周波数を減らす方法の提供を行おうとしている。少なくとも，現在のCD-Rドライブのあるモデルは，最近使用した少数のディスクそれぞれにデータを記録するのに使われた最後のパワー較正値を記憶しようとする。ほとんどのCD-Rドライブは，ホストソフトウェアが，現ディスクにデータを記録するために，ドライブで使われた最新のパワー較正設定をドライブから検索し，将来それらを回復して使用する機構を備えている。

ここに示されるパワー較正表は，互換性のある処理システムで将来使用するため，こうして得られたパワー較正情報をディスクに記録するのに使われる。表はヘッダで構成されており，このヘッダの後には，このディスクにデータを記録するため，異なる条件の下で多様なドライブ及び/又はホストが使用してきた，パワー較正設定を含むレコードのリストが続く。記録済み較正設定のどれが将来の状況で使用するのに適しているかを決定するのに使用できる，他の関連情報も続く。記録済みパワー較正情報を効果的に使用するため，あらゆる必要な情報を予想し，含めるための努力が払われてきたが，それらの情報が実際に使われるのか，使われる場合はいつどのような形でかを決定するには，個々の処理システムに依存している。

パワー較正表は，3.3.5の規則に従って，ファイル集合記述子のシステムストリームとして記録するものとする。ストリーム名は，次のとおりとする。

"*UDF Power Cal Table"

パワー較正表をサポートしない処理システムは，このストリームを消去してはならない。パワー較正表をサポート及び/又は使用する処理システムは，その処理システムがその使用によって，明らかにかつ特別に時代遅れにしたことも更新したこともなかった表からのレコードを消去したり修正してはならない。

ストリームは次のとおりに初期化するものとする。

3.3.7.3.1 パワー較正表システム(Power Calibration Table System)

表3.19

RBP	長さ	名前	内容
0	32	処理システム識別子	実体ID[UDF 2.1.5]
32	4	レコード数	Uint32[1/7.1.5]
56	*	パワー較正表レコード	バイト

処理システム識別子については, 2.1.5を参照されたい。

レコード数は, パワー較正表に含まれるレコード数を規定するものとする。

パワー較正表レコードは, このディスクに書込んだドライブのための一連のパワー較正表レコードとする。この表の長さは可変であるが，4バイトの倍数とする。未構造化欄のデータの記録は左揃えにし，右側は，#20バイトで埋めるものとする。

表3.20 パワー較正表記録レイアウト

RBP	長さ	名前	内容
0	2	レコード長	Uint16[1/7.1.3]
2	2	ドライブ一意領域長[DUA_L]	Uint16[1/7.1.3]
4	32	ベンダID	バイト
36	16	製品ID	バイト
52	4	ファームウェア改訂レベル	バイト
56	16	連続番号/装置一意ID	バイト
72	8	ホストID	バイト
80	12	生成日時スタンプ	日時スタンプ[1/7.3]
92	12	更新日時スタンプ	日時スタンプ[1/7.3]
104	2	速度	Uint16[1/7.1.3]
106	6	パワー較正値	バイト
112	[DUA_L]	ドライブ一意領域	バイト

a) レコード長 このパワー較正表レコードのバイトの長さで，オプションの可変長ドライブ一意領域を含む。4バイトの倍数とする。

b) ドライブ一意領域長 このレコードの最後のバイトに記録されるオプションのドライブ一意領域の長さ。4バイトの倍数とする。

c) ベンダID ドライブによって報告されるベンダID。

d) 製品ID ドライブによって報告される製品ID。

e) ファームウェア改訂レベル ドライブによって報告されるファームウェア改訂レベル

f) 連続番号/装置一意ID ベンダによって指定されるモデルの，特定ドライブに関する連続番号又はその他の一意識別子，及びこのディスクにデータを記録するために報告されたパワー較正値をうまく使用した, 与えられた製品ID。

g) ホストID ホスト連続番号，イーサネットID又はその他の値(又は値の組合わせ)。これは, このディスクにデータを記録するために報告されるパワー較正値をうまく使用したときに，ドライブが接続されている特定のホストコンピュータを識別する処理システムによって使用される。処理システムでは，各ホストに対して一意の値を提供しようとしなければならないが，値の一意性を保証する必要はない。

h) 生成日時スタンプ パワー較正値が記録された日時で，適切に使用されたことを最初に証明している。

i) 更新日時スタンプ パワー較正値が記録された日時で，適切に使用されたことを最近証明している。

j) 速度 ドライブで報告される記録速度で，ここに記録されたパワー較正値が適切に使用された記録速度。この値は，データがドライブによってディスクに書き込まれた, 毎秒のキロバイト(バイト/1000分の１)数とする(端数は切り捨てる。)。例えば，176という速度は，データがディスクに毎秒176キロバイトで書込まれたことを意味する。これは，基本的なCD-DA(ディジタルオーディオ)のデータ速度(CD-DAで別名"1X")とする。353の速度は，データがディスクに毎秒353キロバイト，つまり，CD-DAの基本速度の2倍の速度(CD-DAで別名"2X")で書込まれたことを意味する。CD-ROMの記録速度は，正しい速度値(例えば，"1X"のCD-ROMデータ速度は，176の速度である"1X"CD-DAとして記録するのが望ましい)を決定するために，対応するCD-DA速度に対して高めに(約15%)調整するのが望ましい。注意することは，これらは未処理のデータであり，(追加の)ヘッダ，エラー訂正データなどに起因するオーバヘッドをすべて反映しているわけではない。

k) パワー較正値 ドライブによって報告されるベンダ固有のパワー構成値とする。

l) ドライブ一意領域 ドライブに対して一意の，非制限情報を記録するためのオプション領域で，ある処理システムは，記録済みパワー較正情報の使用, 又は関連付けられたドライブの操作を拡張するために，この領域を使用してよい。この欄のデータの記録は，ドライブ製造業者が定義しなければならない。この領域は, 4バイト長の整数倍でなければならない。

3.3.7.4 UDFバックアップ日時(UDF Backup Time)

このストリームの名前は

"*UDF Backup"

このストリームは，次の内容をもつものとし，ICBに埋め込まなければならない。

表3.21 UDFバックアップ日時

RBP	長さ	名前	内容
0	12	バックアップ日時	日時スタンプ

バックアップ日時は，このボリュームのバックアップが実行された最新の時間とする。

3.3.8 UDF定義の非システムストリーム(UDF Defined Non-System Streams)

この節では次の非システムストリームを定義している。

表3.22

ストリーム名	ストリーム位置	メタデータフラグ
*UDF Macintosh Resource Fork	ファイル又はディレクトリ	0
*UDF OS/2 EA	ファイル又はディレクトリ	0
*UDF NT ACL	ファイル又はディレクトリ	0
*UDF UNIX ACL	ファイル又はディレクトリ	0

3.3.8.1 Macintosh資源フォークストリーム(Macintosh Resource Fork Stream)

資源フォークは明瞭なインタフェースで参照するため，UDF処理システムでは，このストリームに正式な名前を与えていない。交換のためには，名前は次のとおりに設定しなければならない。

"*UDF Macintosh Resource Fork"

ファイル識別記述子のファイル特性欄のメタデータビットは，プラットフォームファイルシステムインタフェースのクライアントに，このファイルの存在を知らせるのが望ましいことを示すため，0に設定するものとする。

3.3.8.2 OS/2 EAストリーム(OS/2 EA Stream)

OS/2で規定できる拡張属性はすべて，名前付きストリームとして記録するものとし，その名前は，次のとおりに設定しなければならない。

"*UDF OS/2 EA"

OS2EAストリームは，次に示すとおり，OS/2完全EA(FEA)の表を含む。

表3.23 FEAフォーマット

RBP	長さ	名前	内容
0	1	Flags	Uint8
1	1	Length of Name(=L_N)	Uint8
2	2	Length of Value(=L_V)	Uint16
4	L_N	Name	バイト
4+L_N	L_V	Value	バイト

完全EA(FEA)を完全に記述するには，IBMの次の規定を参照されたい。

"Installable File System for OS/2 Version 2.0"
OS/2 File Systems Department
PSPC Boca Raton, Florida
February 17, 1992

3.3.8.3 アクセス管理リスト(Access Control List)

一定のオペレーティングシステムでは，ファイルへのアクセスの制約を強化するためアクセス管理リスト(ACL)の概念をサポートしている。ACLの支援を促進するため，UDF2.0では，システムレベルの名前付きストリームの集合を規定している。この目的は，与えられたファイル対象に関連するACLを記録することとする。

UDFのACLは，3.3.5の規則に従って，名前付きストリームとして記録される。名前付きストリームACLの内容は不明瞭であり，この標準情報(TR)では規定しない。命名ACLの内容の解釈は，ACLが意図しているオペレーティングシステムに任されるものとする。次の名前は, ACLを識別するのに使われ，予約されなければならない。これらの名前はアプリケーション名前付きストリームに使用してはならない。

"*UDF NT ACL"

"*UDF UNIX ACL"

4. 利用者インタフェース要件

4.1 第3部 ボリューム構造

JIS X 0607の第3部には，処理システムに依存して，利用者に提示しなければならないいろいろな識別子を含む。

• a) ボリューム識別子
• b) ボリューム集合識別子
• c) 論理ボリュームID

これらの識別子は，CS0で記録され，利用者に表示可能にするために，ある翻訳方式を採らなければならないことがある。そのため，処理システムが前記の識別子について，OS固有の解釈を実行しなければならないとき，処理システムは4.1.2.1に記述するアルゴリズムを使用するものとする。

翻訳アルゴリズムのためのCのソースコードは，この標準情報(TR)の附属書に示す。

4.2 第4部 ファイルシステム

4.2.1 ICBタグ(ICB Tag)

    Struct icbtag {	/* ECMA 1674/14.6 */
		Uint32	PriorRecordedNumberofDirectEntries;
		Uint16	StrategyType;
		byte	StrategyParameter[2];
		Uint16	NumberofEntries;
		byte	Reserved;	/* == #00 */
		Uint8	FileType;
		Lb_addr	ParentICBLocation;
		Uint16	Flags;
    }

4.2.1.1 ファイル種別(FileType)

UNIXでないオペレーティングシステム環境では，次に示す値のいずれかをこの欄の中にもつファイルに関するopen/close/read/write要求は，アクセス拒否エラーの状態とする。

ファイル種別値 - 0(Unknown), 6(ブロック装置), 7(文字装置), 9(FIFO)及び10(C_ISSOCK)

種別12(シンボリックリンク)のファイルに関するopen/close/read/write要求は，このシンボリックリンクが指し示しているファイル又はディレクトリにアクセスするものとする。

4.2.2 ファイル識別記述子(File Identifier Descriptor)

    Struct FileIdentifierDescriptor{	/* ECMA 1674/14.4 */
		struct tag	DescriptorTag;
		Uint16		FileVersionNumber;
		Uint8		FileCharacteristics;
		Uint8		LengthofFileIdentifier;
		struct long_ad  ICB;
		Uint16		LengthofImplementationUse;
		byte		ImplementationUse[];
		char		FileIdentifier[];
		byte		Padding[];
    }

4.2.2.1 ファイル識別子(char FileIdentifier)

ほとんどのオペレーティングシステムは，正当なファイル識別子の特性に関するそれ自体の規定があるので，これは交換に伴う問題となる。そのため，すべての処理システムが，ファイル識別子翻訳の何らかの方式を実行しなければならないので，すべての処理システムが同一アルゴリズムを使用すれば，それは利用者にとって有益となる。

ファイル識別子翻訳の問題は，次の一つ以上に分類される。

• a) 名前長 ほとんどのオペレーティングシステムは，ファイル識別子の長さに，ある決まった制限がある。
• b) 無効文字 ほとんどのオペレーティングシステムは，ファイル識別子名中に不当と考えられる文字がある。
• c) 表示可能文字 UDFがUnicode文字集合を利用可能にするので，ファイル識別子中の文字が，受領システムで表示可能でないものも含んでよい。
• d) 大文字及び小文字の区別 いくつかのオペレーティングシステムは，ファイル識別子に関して大文字及び小文字の区別を行わない。例えば，OS/2はファイルを作成するとき，ファイル識別子の元の状態を記録するが，ファイル識別子にアクセスしているとき，大文字及び小文字を区別しない操作を使用する。OS/2では，"Abc"及び"ABC"は同一ファイル名とする。
• e) 予約名 いくつかのオペレーティングシステムには，ファイル識別子名に使用できない名前がある。

次節は，この標準情報(TR)で扱う各特定オペレーティングシステムに対するファイル識別子の翻訳アルゴリズムを概説する。すべてのOSTA UDF適合処理システムは，このアルゴリズムを使用するものとする。このアルゴリズムは，不当なファイル識別子を読み出した場合だけに適用する。媒体中の元のファイル識別子名は，変更してはならない。このアルゴリズムは，オペレーティングシステムのファイル識別子制限に合致させるために，ファイル識別子の翻訳方式を実行する処理システムに適用するものとする。

すべてのOSTA UDF適合処理システムは，UDF翻訳アルゴリズムを利用しなければならないが，追加アルゴリズムを利用可にしてもよい。複数のアルゴリズムを利用可能にする場合，処理システムの利用者に，UDF翻訳アルゴリズムの選択方法を提供しなければならない。デフォルトの表示可能アルゴリズムは，UDFが定義するアルゴリズムであることを推奨する。

これらのアルゴリズムの主目的は，ファイルが属するディレクトリのすべてを調べずに，固有のオペレーティングシステムの制限に適合する一意のファイル名を作成することとする。

次に示すアルゴリズムのためのCのソースコードは，この標準情報(TR)の附属書に示してもよい。

 備考 次のアルゴリズムの定義では，常に，d文字は引用符中に指定され，Unicodeの16進の数値が指定される。さらに，このアルゴリズムは，CS0の16進表示を参照する。これは，16進数で値を表すのにUnicodeの値#0030〜#0039及び#0041〜#0046を使用することに相当する。

次のアルゴリズムは，処理システムの利用者に名前の重複を報告する結果となることもある。その理由は，利用者に(ファイルの名前変更により)ディレクトリ中のどんなファイルへのアクセスも可能とする一方で，ディレクトリの内容への効率的なアクセスと論理ボリュームマウント及びファイルシステムドライバ処理システムにまたがって一貫した名前の翻訳とに関する必要性にある。

定義

ファイル識別子は，ファイル名及びファイル拡張子の二つの部分で構成するものとする。

文字"."(#002E)は，ファイルのファイル識別子に関する分離子とする。最後の"." (#002E)に続く文字が5文字以下の場合，それはファイル拡張子を構成するものとする。5文字を超える場合，ファイル拡張子は存在ししてはならない。ファイル拡張子に先行して現れ，最後の"." (#002E)を除いた文字は，ファイル名を構成するものとする。

 備考 たとえOS/2，Macintosh及びUNIXが，ファイル拡張子の概念を形式的にもたないとしても，1文字から5文字の拡張子がその後に続く"." でもってファイルを終えることが，共通のファイル命名規則とする。そのため，次のアルゴリズムでは，ファイル拡張子は最大5文字までとしている。

4.2.2.1.1 MS-DOS

MS-DOSオペレーティングシステム環境が，ファイルに関連するファイル識別子に制限を強いるため，上に挙げたオペレーティングシステム環境でファイル識別子を扱うために，次に示す方法を使用するものとする。

制限 ファイル識別子のファイル名要素は，8文字を超えてはならない。ファイル識別子のファイル拡張子要素は，3文字を超えてはならない。

• a) ファイル識別子の照合 ファイル識別子の"照合"に対する要求に，大文字及び小文字を区別しない比較 を実行するものとする。
• b) ファイル識別子の有効性確認 ファイル識別子が有効なMS-DOSファイル識別子である場合，次の段階 は適用しない。
• c) スペースの除去 識別子中のすべての埋込みスペースは削除するものとする。
• d) 無効文字 (先に定義した)ファイル名中の無効文字又はファイル拡張子中の無効文字，若しくは現状の環境で表示不可能な文字を含むファイル識別子は，これらを"_"(#005F)に翻訳するものとする。(媒体中のファイル識別子は，変更しない)。複数の連続する無効文字，又は表示不可能な文字は，1文字の"_"(#005F)に翻訳するものとする。無効文字は附属書の全リストを参照。
• e) 先行終止符 最初の"."(#002E)文字の前に文字が存在しない場合，このヒューリスティックなアプリケーションでは，先行する"."(#002E)を，最初の"."(#002E)でない文字まで無視するものとする。
• f) 複数終止符 複数の"."(#002E)文字を含むファイル識別子の場合，最後の"."(#002E)に続くすべての 文字が5文字以下であれば，ファイル拡張子を構成するものとする。ファイル拡張子の前の最後の"."(#002E)を除く文字はファイル名を構成するものとする。ファイル名中の"."(#002E)文字は，削除するものとする。
• g) 長拡張子 この処理のこの段階で，ファイル拡張子を構成する文字数が3を超える場合，このファイル拡張子は，この処理のこの段階でのファイル拡張子を構成している文字の中の先頭の3文字で構成するとみなすものとする。
• h) 長ファイル名 この処理のこの段階で，ファイル名を構成する文字数が8を超える場合，ファイル名は4文字に切り縮めるものとする。
• i) ファイル識別子CRC 前述の処理により，元のファイル識別子の文字情報が失われているので，同一ディレクトリ中で重複ファイル識別子を作成する機会が増す。重複ファイル識別子をもつ機会を大きく減らすために，ファイル名を元ファイル識別子のCRCを含むように変更するものとする。ファイル名は，この処理のこの段階でファイル名を構成する４文字を先頭として，元のCS0ﾌァイル識別子の 16ビットCRCのCS0の16進表示した4数字を続けて構成するものとする。

   備考 DOSを除く他のアルゴリズムはすべて，分離子‘#’(#0023)によってCRCに先行する。DOSファイル名の文字が制限されているため，CRCの分離子は使用されない。

• j) 新しいファイル識別子は，すべて大文字に翻訳するものとする。

4.2.2.1.2 OS/2

OS/2オペレーティングシステム環境が，ファイルに関連するファイル識別子に制限を強いるため，前述のオペレーティングシステム環境でファイル識別子を扱うために，次に示す方法を使用するものとする。

• a) ファイル識別子の照合 ファイル識別子の"照合"に対する要求に，大文字及び小文字を区別しない比較を実行してもよい。大文字及び小文字を区別しない比較が行われなかったり，失敗した場合，大文字及び小文字を区別する比較を実行するものとする。
• b) ファイル識別子の有効性確認 ファイル識別子が有効なOS/2ファイル識別子である場合，次の段階は適用しない。
• c) 無効文字 OS/2のファイル名として無効な文字，又は現状の環境で表示不可能な文字を含むファイル 識別子は，これらを"_"(#005F)に翻訳するものとする。複数の連続する無効文字又は表示不可能な文字は，1文字の"_"(#005F)に翻訳するものとする。無効文字は附属書の全リストを参照。
• d) 末尾の終止符及びスペース すべての末尾の"."(#002E)及び" "(#0020)は削除するものとする。
• e) ファイル識別子CRC 前述の処理により，元のファイル識別子の文字情報が失われるので，同一ディレクトリ中で重複ファイル識別子を作成する機会が増す。重複ファイル識別子をもつ機会を大きく減らすために，ファイル名を元のファイル識別子のCRCを含むように変更するものとする。

  ファイル拡張子がある場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する先頭の[254 - {新ファイル拡張子の長さ+ ("."用の)1} -(#CRC用の)5]個までの文字から成り，これに分離子"#"(#0023)が続き，元のCS0ﾌァイル識別子の16ビットCRCをCS0 の16進表示した4数字を続けて，さらに"."(#002E)及びこの処理のこの段階でのファイル拡張子を続けて構成するものとする。

  ファイル拡張子がない場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する先頭の[254-(#CRC用の)5]個の文字から成る。これに分離子"#"(#0023)を続け，元のCS0ﾌァイル識別子の16ビットCRCをCS0 の16進表示した4数字を続けて構成する。

4.2.2.1.3 Macintosh

Macintoshオペレーティングシステム環境が，ファイルに関連するファイル識別子に制限を強いているため，前述のオペレーティングシステム環境でファイル識別子を扱うために，次に示す方法を使用するものとする。

• a) ファイル識別子の照合 ファイル識別子の"照合"に対する要求に，大文字及び小文字を区別しない比較を実行してもよい。大文字及び小文字を区別しない比較が行われなかったり，失敗した場合，大文字及び小文字を区別する比較を実行するものとする。
• b) ファイル識別子の有効性確認 ファイル識別子が有効なMacintoshファイル識別子である場合，次の段階を適用しない。
• c) 無効文字 Macintoshファイル名として無効な文字，又は現状の環境で表示不可能な文字を含むファイル識別子は，これらを"_"(#005F)に翻訳するものとする。複数の連続する無効文字又は表示不可能文字は，1文字の"_"(#005F)に翻訳するものとする。無効文字は附属書の全リストを参照。
• d) 長ファイル識別子 この処理のこの段階で，ファイル識別子を構成する文字数が31個(Macintoshオペレーティングシステムでの名前の最大長)より大きい場合，この処理のこの段階で，新しいファイル識別子はファイル識別子の先頭26文字で構成する。
• e) ファイル識別子CRC 前述の処理により，元のファイル識別子の文字情報が失われているので，同一ディレクトリ中で重複ファイル識別子を作成する機会が増す。重複ファイル識別子をもつ機会を大きく減らすために，ファイル名を元のファイル識別子のCRCを含むように変更するものとする。

  ファイル拡張子がある場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する先頭の[31-{新ファイル拡張子の長さ+1("."用)}-5(#CRC用)]個の文字から成り，これに分離子"#"(#0023)が続き，元のCS0ﾌァイル識別子の16ビットCRCをCS0 の16進表示した4数字を続けて，さらに"."(#002E)及びこの処理のこの段階でのファイル拡張子を続けて構成するものとする。

  ファイル拡張子がない場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する先頭の[31-5(#CRC用)]個の文字から成る。これに分離子"#"(#0023)を続け，元のCS0ﾌァイル識別子の16ビットCRCをCS0の16進表示した4数字を続けて構成するものとする。

4.2.2.1.4 Windows 95及びWindows NT

Windows 95及びWindows NTオペレーティングシステム環境が，ファイルに関連するファイル識別子に制限を強いるため，前述のオペレーティングシステム環境でファイル識別子を扱うために，次に示す方法を使用するものとする。

• a) ファイル識別子の照合 ファイル識別子の"照合"に対する要求に，大文字及び小文字を区別しない比較を実行してもよい。大文字及び小文字を区別しない比較が行われなかったり，失敗した場合，大文字及び小文字を区別する比較を実行するものとする。
• b) ファイル識別子の有効性確認 ファイル識別子が有効なWindows 95又はWindows NTファイル識別子である場合，下の段階を適用しない。
• c) 無効文字 Windows 95又はWindows NTのファイル名として無効な文字，又は現状の環境で表示可能でない文字を含むファイル識別子は，これらを"_"(#005F)に翻訳するものとする。複数の連続する無効文字又は表示不可能な文字は，1文字の"_"(#005F)に翻訳するものとする。無効文字は附属書の全リストを参照。
• d) 末尾の終止符及びスペース すべての末尾の“．”(#002E)及び“”“(#0020)”は削除するものとする。
• e) ファイル識別子CRC 前述の処理により，元のファイル識別子の文字情報が失われているので，同一ディレクトリ中で重複ファイル識別子を作成する機会が増す。重複ファイル識別子をもつ機会を大きく減らすために，ファイル名を元のファイル識別子のCRCを含むように変更するものとする。

  ファイル拡張子がある場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する先頭の[MAXNameLength-{新ファイル拡張子の長さ+1("."用)}-5(#CRC用)]個の文字から成り，これに分離子"#"(#0023)が続き，元のCS0ﾌァイル識別子の16ビットCRCのCS0の16進表示した4数字を続けて，さらに"."(#002E)及びこの処理のこの段階でのファイル拡張子を続けて構成するものとする。

  ファイル拡張子がない場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する 最初の[255-5(#CRC用)]個の文字から成るものとする。これに分離子"#"(#0023)を続け，元のCS0ﾌァイル識別子の16ビットCRCをCS0の16進表示した4数字を続けて構成する。

4.2.2.1.5 UNIX

UNIXオペレーティングシステム環境による制約のため，ファイルに関連するファイル識別子に関して，前述のオペレーティングシステム環境でファイル識別子を扱うために，次の方法論を採用するものとする。

• a) ファイル識別子の照合 ファイル識別子の"照合"に対する要求に，大文字と小文字の区別をしない比較を実行するものとする。
• b) 有効ファイル識別子 ファイル識別子が，現在のシステム環境に有効なUNIXファイル識別子である場合，次の段階には適応しない。
• c) 無効ファイル識別子 現在のシステム環境に関して，UNIXファイル名内で無効と考えられる文字，又は，現在の環境で表示できないと考えられる文字を含むファイル識別子は，それらを"_"(#005E)に変換するものとする。複数の連続無効文字又は表示不能文字は，1文字の"_"(#005E)に変換するものとする。無効文字の完全リストについては附属書を参照。
• d) 長ファイル識別子 この処理のこの段階でファイル識別子を構成する文字数が最大名前長(特定のUNIXオペレーティングシステムの最大名前長)より大きい場合，新しいファイル識別子は，この処理のこの段階のファイル識別子の，最初の5文字の最大名前長から成る。
• e) ファイル識別子CRC 前述の手順により，もとのファイル識別子の文字情報が失われるので，同一のディレクトリに，重複ファイル識別子を作成する機会が増える。重複ファイル識別子を作成する機会を大幅に減らすためには，もとのファイル識別子のCRCを含むように，ファイル名を変更するものとする。

  ファイル拡張子がある場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する先頭の[最大名前長-(新しいファイル拡張子長+1('.'用))-5(#CRC用)]数文字から成り，これに分離子'#'(#0023)を続け，元のCS0ファイル識別子の16ビットCRCのCS0の16進表示した4数字を続け，さらに'.'及びこの処理のこの段階でのファイル拡張子を続けて構成するものとする。

  ファイル拡張子がない場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する，先頭(最大名前長-5(#CRC用))の数文字で構成するものとする。これに，分離子'#'(#0023)が続き，元のCS0ファイル識別子の16ビットのCRCをCS0の16進表示した4数字が続く。

5. 参考

5.1 記述子長

次の表は，JIS X 0607に記述する記述子の長さに対するUDF制限を要約する。

表5.1

N/A：規定しない

記述子	長さ
開始ボリューム記述子ポインタ	512
ボリューム記述子ポインタ	512
処理システム用ボリューム記述子	512
区画記述子	512
論理ボリューム記述子	最大値なし
未割付け空間記述子	最大値なし
終端記述子	512
論理ボリューム保全記述子	最大値なし
ファイル集合記述子	512
ファイル識別記述子	論理ブロック長
割付けエクステント記述子	24
間接エントリ	52
終端エントリ	36
ファイルエントリ	論理ブロック長
未割付け空間エントリ	論理ブロック長
空間ビットマップ記述子	最大値なし
区画保全エントリ	N/A

5.2 処理システム用領域の使用

5.2.1 実体識別子(Entity Identifier)

この標準情報(TR)のはじめに定義する実体識別子の節を参照。

5.2.2 孤立空間(Orhan Space)

孤立空間が論理ボリューム中に存在してもよいが推奨はしない。それは，いくつかの論理ボリュームの修理機能によって再割り付けされる可能性があるためとする。孤立空間は，JIS X 0607で定義する処理システム用記述子以外のいずれの記述子で，直接又は間接に参照しない空間として定義する。

 備考 処理システム用欄中だけに参照が存在する割付け済みのエクテントを孤立空間とみなす。

5.3 起動記述子

起動記述子の情報については，文献"OSTA Native Implementation Specification"を参照。

5.4 技術的問合わせ

この標準情報(TR)の原規定に関する技術的質問は，e-mailでinfo@osta.org.のOSTA Technical Committeeまで送られたい。また技術的質問は，1-805-962-1542でOSTA Technical Committeeの受付けへファックスしてもよい。

OSTAへの連絡は，次に示す住所宛でも可能とする。

	Technical Committee Chairman
	OSTA
	311 East Carrillo Street
	Santa Barbara, CA 93101
	(805)963-3853

追加の情報については，www.osta.org のOSTAウェブサイトを参照のこと。

6. 附属書

6.1 UDF実体識別記述子

表6.1

実体識別子	記述
“*OSTA UDF Compliant”	論理ボリューム規定の内容，又はファイル集合の内容が，この標準情報(TR)で定義する適合範囲であることを示す。
“*UDF LV Info”	付加的な論理ボリューム識別情報を含む。
“*UDF FreeEASpace”	処理システム用拡張属性空間中の未使用の空き空間を含む。
“*UDF FreeAppEASpace”	アプリケーション用拡張属性空間中に未使用の空き空間を含む。
“*UDF DVD CGMS Info”	DVD 著作権管理情報を含む。
“*UDF OS/2 EALength”	OS/2拡張属性長を含む。
“*UDF Mac Volume Info”	Macintosh ボリューム情報を含む。
“*UDF Mac FinderInfo”	Macintosh ファインダ情報を含む。
“*UDF Virtual Partition”	UDF仮想区画を記述する。
“*UDF Sparable Partition”	UDF予備区画を記述する。
“*UDF Virtual Alloc Tbl”	連続書込み媒体への再書込みを扱う情報を含む。
“*UDF Sparing Table”	媒体で欠陥領域を扱う情報を含む。

6.2 UDF実体識別値

表6.2 UDF実体識別子値

実体識別子	バイト値
"*OSTA UDF Compliant"	#2A,#4F,#53,#54,#41,#20,#55,#44,#46,#20,#43,#6F,#6D,#70,#6C,#69,#61,#6E,#74
"*UDF LV Info"	#2A,#55,#44,#46,#20,#4C,#56,#20,#49,#6E,#66,#6F
"*UDF FreeEASpace"	#2A,#55,#44,#46,#20,#46,#72,#65,#65,#45,#41,#53,#70,#61,#63,#65
"*UDF FreeAppEASpace"	#2A,#55,#44,#46,#20,#46,#72,#65,#65,#41,#70,#70,#45,#41,#53,#70,#61,#63,#65
"*UDF DVD CGMS Info"	#2A,#55,#44,#46,#20,#44,#56,#44,#20,#43,#47,#4D,#53,#20,#49,#6E,#66,#6F
"*UDF OS/2 EALength"	#2A,#55,#44,#46,#20,#45,#41,#4C,#65,#6E,#67,#74,#68
"*UDF Mac VolumeInfo"	#2A,#55,#44,#46,#20,#4D,#61,#63,#20,#56,#6F,#6C,#75,#6D,#65,#49,#6E,#66,#6F
"*UDF Mac FinderInfo"	#2A,#55,#44,#46,#20,#4D,#61,#63,#20,#49,#69,#6E,#64,#65,#72,#49,#6E,#66,#6F
"*UDF Virtual Partition"	#2A,#55,#44,#46,$20,#56,#69,#72,#74,#75,#61,#6C,#20,#50,#61,#72,#74,#69,#74, #69,#6F,#6E
"*UDF Sparable Partition"	#2A,#55,#44,#46,#20,#53,#70,#61,#72,#61,#62,#6C,#65,#20,#50,#61,#72,#74,#69, #74,#69,#6F,#6E
"*UDF Virtual Alloc Tbl"	#2A,#55,#44,#46,#20,#56,#69,#72,#75,#61,#6C,#20,#41,#6C,#6C,#6F,#63,#20,#54, #62,#6C
"*UDF Sparing Table"	#2A,#55,#44,#46,#20,#53,#70,#61,#72,#69,#6E,#67,#20,#54,#61,#62,#6C,#65

6.3 オペレーティングシステム識別子

次に示す表は，実体識別子の識別子添字中のOSクラス欄及びOS識別子欄に対して現状許可する値を定義する。

OSクラス欄は，記述子を記録したオペレーティングシステムのクラスを識別する。この欄の有効な値を表6.3に示す。

表6.3 OSクラス欄の値

値	オペレーティングシステムクラス
0	未定義
1	DOS
2	OS/2
3	Macintosh OS
4	UNIX
5	Windows 9x
6	Windows NT
7-255	予備

OS識別子欄は，記述子を記録したオペレーティングシステムを識別する。この欄の有効な値は次のとおりとする。

表6.4 OS識別子の値

OSクラス	OS識別子	識別されるオペレーティングシステム
0	任意の値	未定義
1	0	DOS/Windows 3.x
2	0	OS/2
3	0	Macintosh OS System 7
4	0	UNIX-Generic
4	1	UNIX-IBM AIX
4	2	UNIX-SUN OS/Solaris
4	3	UNIX-HP/UX
4	4	UNIX-Silicon Graphics Irix
4	5	UNIX-Linux
4	6	UNIX-MKLinux
4	7	UNIX-FreeBSD
5	0	Windows 95
6	0	Windows NT

OSクラス及びOS識別子に関する値の最新表については，OSTAに連絡し，UDF実体識別子ディレクトリのコピーを要求されたい。このディレクトリには，必須情報をOSTAへ提供したISVsの処理システム識別子も含まれる。

 備考 この表への追加を希望する場合，5.3の技術術的問合せに示したOSTAの住所のOSTA Technical Committee Chairmanに連絡されたい。

6.4 OSTA圧縮Unicodeの圧縮アルゴリズム

/**********************************************************************************
   * OSTA compliant unicode compression,uncompression routines.
   * Copyright 1995 Micro Design International, Inc,
   * Written by Jason M. Rinn.
   * Micro Design International gives permission for the free use of the
   * following source code.
   */
   #include 
  /***********************************************************************************
   * The follwing two typedef's are to remove compiler dependancies.
   * byte needs to be unsigned 8-bit, and unicode_t needs to be
   * unsigned 16-bits.
   */
  typedef unsigned short unicode_t;
  typedef unsigned char byte;
  /***********************************************************************************
   * Takes an OSTA CS0 compressed unicode name, and converts
   * it to unicode.
   * The unicode output will be in the byte order
   * that the local compiler uses for 16-bit values.
   * NOTE: This routine only performs error checking on the compID.
   * It is up to the user to ensure that the unicode buffer is large
   * enough, and that the compressed unicode name is correct.
   *
   * RETURN VALUE
   * 
   *    The number of unicode characters which were uncompressed.
   *    A -1 is returned if the compression ID is invalid.
   */
   int UncompressUnicode(
   int numberOfBytes,   /* (Input) number of bytes read from media.  */
   byte *UDFCompressed, /* (Input) bytes read from media. */
   unicode_t *unicode)  /* (Output) uncompressed unicode characters. */
   {
    unsigned int compID;
    int returnValue, unicodeIndex, byteIndex;
    /* Use UDFCompressed to store courrent byte being read.    */
    CompID=UDFCompressed[0];
    /* First check for valid compID. */
    if (compID !=8 && compID !=16)
    {
        returnValue =-1;
    }
    else
    { 
        unicodeIdex =0;
        byteIndex =1;
        /* Loop through all the bytes. */
       while (byteIndex < numberOfBytes)
        {
          if (compID ==16)
          {
           /*Move the first byte to the high bits the unicode char. */
             unicode[unicodeIndex] = UDFCompressed[byteIndex++] <<8;
          }else unicode[unicodeindex]=0;
          if (byteIndex < numberOfBytes)
          {
           /*Then the next byte to the low bits. */
           unicode[unicodeIndex] ｜=UDFCompressed[byteIndex++];
          }
          unicodeIndex++;
        }
        returnValue = unicodeIndex;
      }
      return(returnValue);
     }
   /***************************************************************************
    * DESCRIPTION:
    * Takes a string of unicode wide characters and returns an OSTA CS0
    * compressed unicode string.  The unicode MUST be in the byte order of
    * the compiler in order to obtain correct results.  Returns an error
    * if the commpression ID is invalid.
    *
    * NOTE:  This routine assumes the implementation already knows, by
    * the local environment, how many bits are appropriate and
    * therefore does no checking to test if the input characters fit
    * into that number of bits or not.
    *
    * RETURN VALUE
    *
    *    The total number of bytes in the compressed OSTA CS0 string,
    *    including the compression ID.
    *    A -1 is returned if the compression ID is invarild.
    */
    int CompressUnicode(
    int numberOfChars,      /* (Input) number of unicode characters.      */
    int compID,             /* (Input) compression ID to be used.         */
    unicode_t *unicode,     /* (Input) unicode characters to compress.    */
    byte *UDFCompressed)    /* (Output) compressed string, as bytes.      */
    {
      int byteIndex,  unicodeIndex;
      if (compID != 8  &&  compID != 16)
      {
        byteIndex = -1;    /* Unsupported compression ID !  */
      }
      else
      {
        /* place compression code in first byte.   */
        UDFCompressed[0] = compID;
        byteIndex = 1;
        unicodeIndex = 0;
        while (unicodeIndex < numberOfChars)
        {
          if (compID == 16)
           {
             /* First, place the high bits of the char
              * into the byte stream.
              */
            UDFCompressed[byteIndex++] =
                         (unicode[unicodeIndex] & 0xFF00) >> 8;
            }
            /* Then place the low bits into the stream.   */
               UDFCompressed[byteIndex++] = unicode[unicodeIndex] & 0x00FF;
               unicodeIndex++;
         }
      }
     return(byteIndex);
    }

6.5 CRC計算

次に示すCプログラムは，JIS X 0607のタグ記述子に使用するCRC-CCITTチェックサムを計算するために利用する。

    /*
     *    CRC 010041
     */
    static unsigned short crc_table[256] = {
          0x0000,0x1021,0x2042,0x3063,0x4084,0x50A5,0x60C6,0x70E7,
          0x8108,0x9129,0xA14A,0xB16B,0xC18C,0xD1AD,0xE1CE,0xF1EF,
          0X1231,0x0210,0x3273,0x2252,0x52B5,0x4294,0x72F7,0x62D6,
          0x9339,0x8318,0xB37B,0xA35A,0xD3BD,0xC39C,0xF3FF,0xE3DE,
          0x2462,0x3443,0x0420,0x1401,0x64E6,0x74C7,0x44A4,0x5485,
          0xA56A,0xB54B,0x8528,0x9509,0xE5EE,0xF5CF,0xC5AC,0xD58D,
          0x3653,0x2672,0x1611,0x0630,0x76D7,0x66F6,0x5695,0x46B4,
          0xB75B,0xA77A,0x9719,0x8738,0xF7DF,0xE7FE,0xD79D,0xC7BC,
          0x48C4,0x58E5,0x6886,0x78A7,0x0840,0x1861,0x2802,0x3823,
          0xC9CC,0xD9ED,0xE98E,0xF9AF,0x8948,0x9969,0xA90A,0xB92B,
          0x5AF5,0x4AD4,0x7AB7,0x6A96,0x1A71,0x0A50,0x3A33,0x2A12,
          0xDBFD,0xCBDC,0xFBBF,0xEB9E,0x9B79,0x8B58,0xBB3B,0xAB1A,
          0x6CA6,0x7C87,0x4CE4,0x5CC5,0x2C22,0x3C03,0x0C60,0x1C41,
          0xEDAE,0xFD8F,0xCDEC,0xDDCD,0xAD2A,0xBD0B,0x8D68,0x9D49,
          0x7E97,0x6EB6,0x5ED5,0x4EF4,0x3E13,0x2E32,0x1E51,0x0E70,
          0xFF9F,0xEFBE,0xDFDD,0xCFFC,0xBF1B,0xAF3A,0x9F59,0x8F78,
          0x9188,0x81A9,0xB1CA,0xA1EB,0xD10C,0xC12D,0xF14E,0xE16F,
          0x1080,0x00A1,0x30C2,0x20E3,0x5004,0x4025,0x7046,0x6067,
          0x83B9,0x9398,0xA3FB,0xB3DA,0xC33D,0xD31C,0xE37F,0xF35E,
          0x02B1,0x1290,0x22F3,0x32D2,0x4235,0x5214,0x6277,0x7256,
          0xB5EA,0xA5CB,0x95A8,0x8589,0xF56E,0xE54F,0xD52C,0xC50D,
          0x34E2,0x24C3,0x14A0,0x0481,0x7466,0x6447,0x5424,0x4405,
          0xA7DB,0xB7FA,0x8799,0x97B8,0xE75F,0xF77E,0xC71D,0xD73C,
          0x26D3,0x36F2,0x0691,0x16B0,0x6657,0x7676,0x4615,0x5634,
          0xD94C,0xC96D,0xF90E,0xE92F,0x99C8,0x89E9,0xB98A,0xA9AB,
          0x5844,0x4865,0x7806,0x6827,0x18C0,0x08E1,0x3882,0x28A3,
          0xCB7D,0xDB5C,0xEB3F,0xFB1E,0x8BF9,0x8BD8,0xABBB,0xBB9A,
          0x4A75,0x5A54,0x6A37,0x7A16,0x0AF1,0x1AD0,0x2AB3,0x3A92,
          0xFD2E,0xED0F,0xDD6C,0xCD4D,0xBDAA,0xAD8B,0x9DE8,0x8DC9,
          0x7C26,0x6C07,0x5C64,0x4C45,0x3CA2,0x2C83,0x1CE0,0x0CC1,
          0xEF1F,0xFF3E,0xCF5D,0xDF7C,0xAF9B,0xBFBA,0x8FD9,0x9FF8,
          0x6E17,0x7E36,0x4E55,0x5E74,0x2E93,0x3EB2,0x0ED1,0x1EF0
    };
    unsigned short
    cksum(s,n)
          register unsigned char *s;
          register int n;
    {
          register unsigned short crc=0;
          whlie (n-- > 0)
            crc = crc_table[(crc>>8 ^ *s++) & 0xff] ^ (crc<<8);
         return crc;
    }
    /* UNICODE Checksum */
    unsigned short
    unicode_cksum(s,n)
           register unsigned short *s;
           register int n;
    {
           register unsigned short crc=0;
           while (n-- > 0) {
    /* Take high order byte first-corresponds to a big endian byte stream.*/
                 crc = crc_table [(crc >>8 ^ (*s>>8) & Oxff] ^ (crc >>8);
                 crc = crc_table [(crc >>8 ^ (*s++ & Oxff)) & Oxff] ^ (crc <<8);
           }
          return crc;
    }
    #ifdef    MAIN
    unsigned char bytes[] = { 0x70,  0x6A, 0x77};
    main()
      usigned short x;
      x = cksum(bytes, sizeof bytes);
      printf("checksum: calculated=%4.4x, correct=%4.4x＼en",x,  0x3299);
　　　exit(0);
    }
    #endif

先に挙げたCRC表は，次のプログラムで生成した。

    #include  
    /*
     *  a.out 010041 for CRC-CCITT
     */
    main(argc,argv)
        int argc; char *argv[];
    {
        unsigned long crc, poly;
        int n, i;
        sscanf(argv[1], "%lo", &poly);
        if(poly & 0xffff0000){
          fprintf(stderr, "polynomial is too large＼en");
          exit(1);
      }
      printf("/*＼en *  CRC 0%o＼en */＼en", poly);
      printf("static unsigned short crc_table[256] = {＼en");
      for(n =0; n < 256; n++){
          if(n % 8 ==0)
            printf("    ");
          crc = n <<8;
          for(i = 0; i < 8; i++){
            if(crc & 0x8000)
              crc = (crc << 1) ^ poly;
            else
              crc <<= 1;
            crc &= 0xFFFF;
          }
          if(n ==255)
            printf("0x%04X ", crc);
          else
            printf("0x%04X, ", crc);
         if(n % 8 == 7)
            printf("＼en");
      }
      printf("};＼en");
      exit(0);
    }

これらのすべてのCRC符号は，AT&T Bell研究所のDon P. Mitchell及びSoftware System GroupのNed W. Rhodesが考案した。これは，既に文献”Design and Validation of Computer Protocols”(Prentice Hall, Englewood Cliffs, NJ, 1991, 3章, ISBN 0-13-539925-4)で公開されており，AT&Tが著作権をもつている。

AT&Tは，上記のソースコードの自由使用の許可を与えている。

6.6 方策種別4096のアルゴリズム

この節は，ICB階層を構成するための方策を記述する。方策種別4096のルートICB階層は，1個の直接エントリ及び1個の間接エントリを含むものとする。1個の直接エントリがあることを示すために，ICBタグ欄の方策パラメータ欄中のUint16に値1を記録する。ICBタグ欄のエントリの最大個数(MaximumNumberOfEntries)欄に値2を記録する。

間接エントリが，1個の直接エントリ及び1個の間接エントリをも含む他のICB番地を規定し，この間接エントリは，同一種別の他のICB番地を規定するものとする。図6.1を参照。

            ┌──┐                                                                              
            │ DE │                                                                              
            ├──┤                                                                              
            │ IE ├−→┌──┐        DE：直接エントリ                                          
            └──┘    │ DE │        IE：間接エントリ                                          
                        ├──┤                                                                  
                        │ IE ├−→┌──┐                                                      
                        └──┘    │ DE │                                                      
                                    ├──┤                                                      
                                    │ IE │                                                      
                                    └──┘ 

　　　　　　　　　図6.1 ICB番地の規定

 備考 この方策は，直接エントリの簡単なリンクリストのICB階層を構成する方策とする。

6.7 識別子翻訳アルゴリズム

次に示すサンプルソースコードの例は，この標準情報(TR)に記述するファイル識別子翻訳アルゴリズムを与えている。

次に示す基本アルゴリズムは，ボリューム記述子，ボリューム集合記述子，論理ボリュームID及びファイル集合IDのOS 固有の翻訳を扱うために利用してもよい。

6.7.1 DOSアルゴリズム(DOS Algorithm)

    /*************************************************************************
     * OSTA UDF compliant file name translation routine for DOS.
     * copyright 1995 Micro Design International, Inc
     * Written by Jason M.Rinn.
     * Micro Design International gives permission for the free use of the
     * following source code.
     */
    #include 
    #define  DOS_NAME_LEN  8
    #define  DOS_EXT_LEN   3
    #define  ILLEGAL_CHAR_MARK    0x005F
    #define  TRUNE                 1
    #define  FALSE                 0
    #define  PERIOD               0x002E
    #define  SPACE                0x0020
    /**************************************************************************
     * The following two typedef's are to remove compiler dependancies.
     * byte needs to be unsigned 8-bit, and unicode_t needs to
     * be unsigned 16-bit.
     */
    typedef unsigned short unicode_t;
    typedef unsigned char byte;
    /*** PROTOTYPES ***/
    unsigned short unicode_cksum(register unsigned short *s, register int n);
    int IsIllegal(unicode_t current);
    /* Define functions or macros to both determine if a character
     * is printable and compute the uppercase version of a character
     * under your implementation.
     */
    int UnicodeIsPrint(unicode_t);
    unicode_t UnicodeToUpper(unicode_t);
    /****************************************************************************
     * Translate udfName to dosName using OSTA compliant.
     * dosName must be a unicode string with min length of 12.
     *
     * RETURN VALUE
     *     Number of unicode characters in dosName.
     */
    int UDFDOSName(
    unicode_t  *dosName,     /* (Output)DOS compatible name.          */
    unicode_t  *udfName,     /* (Input) Name from UDF volume.         */
    int         udfLen)      /* (Input) Length of UDF Name.           */
    {
      int  index,  dosIndex = 0,  extIndex =0,  lastPeriodIndex;
      int  needsCRC =  FALSE,  hasEXT  =  FALSE,  writingExt  =  FALSE;
      unsigned  short  valueCRC;
      unicode_t  ext[DOS_EXT_LEN],  current;
      /* Used to convert hex digits.  Used ASCII for readability.    */
      const char hexChar[]  =  "0123456789ABCDEF";
      for (index  =  0  ;  index  <  udfLen  ;  index++)
      {
          current  =  udfName[index];
          current  =  UnicodeToUpper(current);
          if  (current == PERIOD)
          {
              if  (dosIndex==0  ‖  hasExt)
              (
            /* Ignore leading periods or any other than
             * used for extension.
             */
                needsCRC  =  TRUE;
              }
              else
              {
            /* First, find last character which is NOT a period
             * or space.
             */
               lastPeriodIndex  =  udfLen - 1;
               while(lastPeriodIndex  >=0  &&
                  (udfName[lastPeriodIndex]==  PERIOD  ‖
                   udfName[lastPeriodIndex] ==  SPACE))
               {
                 lastPeriodIndex--;
               }
            /* Now search for last remaining period.  */
               while(lastPeriodIndex  >=  0  &&
                     udfName[lastPeriodIndex]  !=  PERIOD)
               {
                  lastPeriodIndex--;
               }
            /* See if the period we found was the last or not.    */
               if (lastPiriodIndex != index)
               {
                  needsCRC = TRUE;    /* If not, name needs translation.    */
               }
            /* As long as the period was not trailing,
             * the file name has an exttention.
             */
               if (lastPeriodIndex  >=0)
               {
                  hasExt  =  TRUE;
               }
             }
           }
           else
          {
           if  ((!hasExt  && dosIndex  ==  DOS_NAME_LEN)  ‖
                  extIndex  ==  DOS_EXT_LEN)
          {
             /* File name or extension is too long for DOS.    */
            needsCRC  =  TRUE;
          }
           else
           {
             if  (current  ==  SPACE)    /* Ignore spaces.    */
                  needsCRC  =  TRUE;
            }
            else
             {
                /* Look for illegal or unprintable characters.    */
                if  (IsIllegal(current)  ‖  !UnicodeIsPrint(current))
                {
                   NeedsCRC  =  TRUE;
                   current  =  ILLEGAL_CHAR_MARK;
                   /* Skip Illegal characters(even  spaces),
                    * but not periods.
                    */
                   while(index+1  <  udfLen
                         &&  (IsIllegal(udfName[index+1])
                         ‖  !UnicodeIsPrint(udfName[index+1]))
                         &&  udfName[index+1]  !=  PERIOD)
                    {
                      index++;
                    }
                 }
                 /* Add current char to either file name or ext.    */
                if  (writingExt)
                {
                   ext[extIndex++]  =  current;
                }
                else
                {
                   dosName[dosIndex++]  =  current;
                }
              }
           }
        }
        /* See if we are done with file name, either because we reached
         * the end of the file name length , or the final  period.
         */
        if  (!writingExt  && hasExt  &&  (dosIndex  ==  DOS_NAME_LEN  ‖
                       index  == lastPeriodIndex))
        {
          /* If so,  and  the name has an  extension, start reading it.    */
         writingExt  =  TRUE;
         /* Extension starts after last period.    */
          index  =  lastPeriodIndex;
         }
      }
       /* Now handle CRC if needed.    */
      if  (needsCRC)
      {
        /* Add CRC to end of file name or at position 4.    */
        if  (dosIndex  >4)
        {
           dosIndex  =4;
        }
        valueCRC  =  unicode_cksum(udfName,  udfLen);
        /* Convert 16-bits CRC to hex characters.    */
        dosName[dosIndex++]  =  hexChar[(valueCRC  &  0xfooo)  >> 12];
        dosName[dosIndex++]  =  hexChar[(valueCRC  &  0x0f00)  >> 8];
        dosName[dosIndex++]  =  hexChar[(valueCRC  &  0x00f0)  >> 4];
        dosName[dosIndex++]  =  hexChar[(valueCRC  &  0x000f)];
      }
      /* Add extension, if any.    */
      if (extIndex  !=0)
      {
        dosNAme[dosIndex++]  =  PERIOD;
        for   (index  =  0;  index  <  extIndex;  index++)
        {
          dosName[dosIndex++]  =  ext[index];
        }
      }
      return(dosIndex);
    }
    /**********************************************************************
     * Decides if a Unicode character matches one of a list
     * of ASCII characters.
     * Used by DOS version of IsIllegal for readability, since all of the
     * illegal characters above 0x0020 are in the ASCII subset of Unicode.
     * Works very similarly to the standard C function strchr().
     *
     * RETURN VALUE
     *
     * Non-zero if the Unicode character is in the given ASCII string.
     * /
    int  UnicodeInString(
    unsigned char  *string,  /* (Input) String to search through.    */
    unicode_t ch)  /* (input) Unicode char search for.    */
    {
      int found  =  FALSE;
      while  (*string  != '＼0'  &&  found  == FALSE)
      {
        /* These types should compare, since both are unsigned numbers.    */
       if  (*string  ==  ch)
        {
        found  =  TRUE;
        }
        string++;
      }
      return(found);
    }
    /*************************************************************************
     * Decides whether character passed is an illegal character for a
     * DOS file Name.
     *
     * RETURN VALUE
     *
     * Non-zero if file character is illegal.
     */
     int  IsIllegal(
    unicode_t ch)    /* (Input) character to test.    */
    {
      /* Genuine illegal char's for DOS.    */
      if  (ch  <  0x20 ‖ UnicodeInString("＼＼ /:*?＼"<>|",  ch))
      {
        return(1);
      }
      else
      {
        return(0);
      }
    }

6.7.2 OS/2, Macintosh, Windows 95, Windows NT及びUNIXアルゴリズム(OS/2, Macintosh, Windows 95, Windows NT and UNIX Algorithm)

    /*************************************************************************
     * OSTA UDF compliant file name translation routine for OS/2.
     * Windows 95, Windows NT, Macintosh and UNIX.
     * copyright 1995 Micro Design International, Inc
     * Written by Jason M.Rinn.
     * Micro Design International gives permission for the free use of the
     * following source code.
     */
    /*************************************************************************
     * To use these routines with different operating systems.
     *
     * OS/2
     *    Define  OS2
     *    Define  MAXLEN  =  254
     *
* Windows 95
*    Define WIN_95
*    Define MAXLEN = 255
*
 WINDOWS NT
*    Define WIN_NT
*    Define MAXLEN = 255
     * 
     *Macintosh:
     *    Define  MAC.
     *    Define  MAXLEN  =  31.
     *
     * UNIX
     *    Define  UNIX.
     *    Define  MAXLEN as specified by unix version.
     */
    #define  ILLEGAL_CHAR_MARK    0x005F
    #define  CRC_MARK             0x0023
    #define  EXT_SIZE              5
    #define  TRUE                  1
    #define  FALSE                 0
    #define  PERIOD               0x002E
    #define  SPACE                0x0020
    /**************************************************************************
     * The following two typedef's are to remove compiler dependancies.
     * byte needs to be unsigned 8-bit, and unicode_t needs to
     * be unsigned 16-bit.
     */
    typedef unsigned int  unicode_t;
    typedef unsigned char byte;
    /*** PROTOTYPES ***/
    int IsIllegal(unicode_t ch);
    unsigned short unicode_cksum(register unsigned short  *s, register int n);
    /* Define a function or macros which determines if a Unicode character is
     * printable under your implementation.
     */
    int UnicodeIsPrint(unicode_t);
    /****************************************************************************
     * Translates a long file name to one using a MAXLEN and an illegal
     * char set in accord with the OSTA requirements.  Assumes the name has
     * already been translated to Unicode.
     *
     * RETURN VALUE
     *     Number of unicode characters in translated name.
     */
    int UDFTransName(
    unicode_t  *newName,     /* (Output)Translated name. Must be of length MAXLEN.          */
    unicode_t  *udfName,     /* (Input) Name from UDF volume.         */
    int         udfLen,      /* (Input) Length of UDF Name.           */
    {
      int  index,  newIndex = 0,  needsCRC = FALSE;
      int  extIndex, newExtIndex  =0,  hasExt  =  FALSE;
    #ifdef  (OS2 | WIN_95 | WIN_NT)
      int  trailIndex  =  0;
    #endif
      unsigned  short  valueCRC;
      unicode_t  current;
      const char hexChar[]  =  "0123456789ABCDEF";
      for (index  =  0  ;  index  <  udfLen  ;  index++)
      {
          current  =  udfName[index];
          if  (IsIllegal(current)  ‖  !UnicodeIsPrint(current))
          {
             needsCRC  =  TRUE;
            /* Replace Illegal and non-displayable chars with underscore.*/
              current = ILLEGAL_CHAR_MARK;
            /* skip any other illegal or non-displayable characters.    */
            while(index+1  <  udfLen  && (IsIllegal(udfName[Index+1]
                         ‖ !UnicodeIsPrint(udfName[Index+1] )))
            {
              index++;
            }
          }
          /*Record position of extension, if one is found  */
          if  (current  == PERIOD  && (udfLen  -  index  -1)  <=  EXT_SIZE
          {
            if  (udfLen  ==  index  +1)
               /* A trailing period is NOT an extension.    */
              hasExt  =  FALSE;
              }
             else
             {
               hasExt  =  TRUE;
               extIndex  =  index;
               newExtIndex  =  newIndex;
             }
           }
    #ifdef  (OS2 | WIN_95 | WIN_NT)
         /*Record position of last char which is NOT period or space. */
          else if  (current  != PERIOD  && current  !=  SPACE)
          {
            trailIndex  =  newIndex;
          }
    #endif
          if  (newIndex  <  MAXLEN)
          {
            newName[newIndex++]  =  current;
          }
          else
          {
             needsCRC  =  TRUE;
          }
        }
    #ifdef  (OS2 | WIN_95 | WIN_NT)
          /* For OS2, 95 & NT,truncate any trailing periods and＼or spaces */
          if  (trailIndex  !=  newIndex -1)
          {
            newIndex  =  trailIndex  +1;
            needsCRC  =  TRUE;
            hasExt  =  FALSE;    /* Trailing period does not make an extension    */
          }
    #endif
          if  (needsCRC)  
          {
            unicode_t  ext[EXT_SIZE];
            int  localExtIndex  =  0;
            if  (hasExt)
            {
              int  maxFilenameLen;
              /* Translate extension, and store it in ext.    */
              for(index  =0;  index  maxFilenameLen)
              {
                newIndex  =  maxFilenameLen;
              }
              else
              {
                newIndex  =  newExtIndex;
              }
            }
          else if (newIndex  >  MAXLEN  -5)
          {
             /*If no extension, make sure to leave room for CRC.    */
            newIndex  =  MAXLEN  - 5;
          }
          newName[newIndex++]  =  CRC_MARK;    /* Add mark for CRC.    */
          /*Calculate CRC from original filename from FileIdentifier.    */
          valueCRC  =  unicode_cksum(udfName, udfLen);
          /* Convert lower  16-bits of CRC to hex characters.    */
          newName[newIndex++]=hexChar[(valueCRC & Oxf000) >>12];
          newName[newIndex++]  =  hexChar[(valueCRC  &  0x0f00)  >>  8];
          newName[newIndex++]  =  hexChar[(valueCRC  &  0x00f0)  >>  4];
          newName[newIndex++]  =  hexChar[(valueCRC  &  0x000f)]; 
         /*Plase a translated extension at end, if found.         */
         if  (hasExt)
         {
            newName[newIndex++]  =  PERIOD;
            for (index  =  0; index  <  localExtIndex ; index++)
            {
               newName[newIndex++]  =  ext[index];
            }
          }
        }
        return(newIdex)
    }
    #ifdef  (OS2 | WIN_95 | WIN_NT)
    /**********************************************************************
     * Decides if a Unicode character matches one of a list
     * of ASCII characters.
     * Used by OS2 version of IsIllegal for readability, since all of the
     * illegal characters above 0x0020 are in the ASCII subset of Unicode.
     * works very similarly to the standard C function strchr().
     *
     * RETURN VALUE
     *
     * Non-zero if the Unicode character is in the given ASCII string.
     * /
    int  UnicodeInString(
    unsigned char  *string,  /* (Input) String to search through.    */
    unicode_t ch)  /* (input) Unicode char search for.    */
    {
      int found  =  FALSE;
      while  (*string  != '＼0'  &&  found  == FALSE)
      {
        /* These types should compare, since both are unsigned numbers.    */
       if  (*string  ==  ch)
        {
          found  =  TRUE;
        }
        string++;
      }
      return(found);
    }
    #endif    /*  OS2    */
    /*************************************************************************
     * Decides whether the given character is illegal for a given OS.
     *
     * RETURN VALUE
     *
     * Non-zero if char is illegal.
     */
     int  IsIllegal(unicode_t  ch)
    {
    #ifdef  MAC
      /* Only  illegal character on the MAC is the colon.    */
      if  (ch  ==  0x003A)
      {
        return(1);
      }
      else
      {
        return(0);
      }
    #elif  defined  UNIX
      /*  Illegal UNIX characters are NULL and slash.    */
      if  (ch  ==  0x0000 ‖ ch  ==  0x002F)
      {
        return(1);
      }
      else
      {
        return(0);
      }
    #elif defined  (OS2 | WIN_95 | WIN_NT)
      /* Illegal char's for OS/2 according to WARP toolkit.    */
      if  (ch  <  0x0020 ‖ UnicodeInString("＼＼ /:*?＼"<>|",  ch))
      {
        return(1);
      }
      else
      {
        return(0);
      }
    #endif
    }

6.8 拡張属性チェックサムアルゴリズム

    /*
     * Calculates a 16-bit checksum of the Implementation Use
     * Extended Attribute header.  The fields Attributestype
     * through ImplementationIdentifier inclusively represent the
     * data covered by the checksum (48 bytes).
     *
     */
    Uint16  ComputeEAChecksum(byte  *data)
    {
      Uint16    checksum  = 0;
      Uint      count;
                for(count  =0;  count  <  48;  count++)
                {
                   checksum += *data++;
                }
                return(checksum);
    }

6.9 DVD-ROMに対する要件

この附属書は，ユニバーサルディスクフォーマット(UDFS)のDVD-ROMディスクに対する要件及び制限を定義する。

• a) DVD-ROMディスクは，UDFファイルシステムで作成するものとする。
• b) DVD-ROMディスクは，単一ボリューム及び単一区画から成るものとする。

 備考 ディスクは，JIS X 0606(ISO 9660)ファイルシステムも含んでよい。ディスクがUDFファイルシステム及びJIS X 0606(ISO 9660)ファイルシステムの両方を含むとき，UDFブリッジディスクとする。UDFブリッジディスクは，JIS X 0606(ISO 9660)だけを利用可能なコンピュータで直接DVD-ROM媒体を再生することを可能にする。UDFコンピュータ処理システムの提供によって，JIS X 0606(ISO 9660)の必要性はなくなり，将来のディスクはUDFだけを含むのが望ましい。

6.9.1 DVD-Videoに関するUDFの制約(Constraints imposed by UDF for DVD-Video)

この節は，専用DVDプレーヤのためのUDFでフォーマットしたDVD-Videoディスクに対する制限及び要件を記述する。DVD-Videoは，家電市場向けにUDFを使用するDVD-ROMの一つの専用アプリケーションとする。DVDプレーヤ中ではコンピュータ資源が限られているのでDVDプレーヤがUDF定義のすべての機能を利用可能にしなくともよいように制限及び要件を作成した。

すべてのDVD-Videoディスクは，JIS X 0607(追補を含まない)及びUDFの規定に従って，すべての必要なデータを含むように作成しなければならない。これにより，DVD-Videoをコンピュータシステムで再生することが可能になる。そのデータの例は，日時及び許可条件のビット並びに空き空間マップ(空き空間がないことを示す)とする。DVDプレーヤの処理システムはこれらの欄を無視してもよいが，UDFコンピュータの処理システムがこれらを無視することはしない。娯楽用の内容及びコンピュータ用の内容が，同一のディスクに共存できる。

 備考 UDF 2.00に従って作成されたDVD-VideoディスクはDVD-Videoプレーヤと互換性がなくてもよい。DVD-Videoプレーヤでは，UDF 1.02フォーマットの媒体に互換性を期待する。

符号量の削減及び効率の向上を意図して，すべての除算は整数で記述し，すべての除数は2のn乗とする。その結果，すべての除算は論理シフト演算で行ってよい。

• a) DVDプレーヤは，UDFだけを利用可能とし，JIS X 0606(ISO 9660)は利用可能としてはならない。
• b) 作成システムは，各ファイルの長さを(2³⁰-論理ブロック長)バイト以下とする。
• c) 各ファイルのデータは，単一エクステントに記録する。各ファイルエントリは，ICB方策種別4を用いて記録しなければならない。
• d) ファイル名及びディレクトリ名は，OSTA圧縮Unicode形式で，1文字当たり8ビットに圧縮しなければならない。
• e) DVDプレーヤは，どんなファイルに対するシンボリックリンクも追ってはならない。
• f) DVD-Videoファイルは，ルートディレクトリの下の"VIDEO_TS"という名前のサブディレクトリに記録するものとする。ディレクトリ名は，文献”DVD Specifications for Read-Only Disc”おいて標準化されたい。

   備考 DVD Specification for Read-Only Discは，DVDコンソーシアムが開発した規定であり，媒体上に記録するDVD-Videoファイルの名前及びDVD-Videoディレクトリの名前を記述している。さらにDVD-Videoファイルの内容についても記述している。

• g) VIDEO_TSサブディレクトリにおいて"VIDEO_TS.IFO"と名付けられたファイルを最初に読み出すものとする。

これらすべての制約は，DVDプレーヤがアクセスする必要があるディレクトリ及びファイルだけに適用する。媒体中にはDVDプレーヤ向けではなく，これらの制限に適合しない，他のファイル及びディレクトリが存在してもよい。これらの他のファイル及びディレクトリを，DVDプレイヤは無視する。これにより，同一ディスク上に娯楽用の内容及びコンピュータ用の内容の両方をもつことができる。

6.9.2 UDFディスクの読出し法(How to read a UDF disc)

この節は，DVDプレーヤが，UDFでフォーマットしたDVD-Videoディスクを読み出すために実行する基本的な手続きを記述する。

6.9.2.1 手順1 ボリューム認識列(Volume Recognition Sequence)

論理セクタ16から開始するものとするボリューム認識列中のJIS X 0607記述子を見つける。

6.9.2.2 手順2 開始ボリューム記述子ポインタ(Anchor Volume Descriptor Pointer)

開始位置の開始ボリューム記述子ポインタを見つけなければならない。二つの開始位置は，論理セクタ256及び論理セクタnに記録されるものとする。ここで，nはディスクの論理セクタに番号付けした最大数とする。

DVDプレーヤは，論理セクタ256だけを見ればよい。論理セクタnのコピーは冗長であり，欠陥対応のためにだけに必要とする。開始ボリューム記述子ポインタは，次の三項目を含む。

• a) ディスクの識別及び保全検証のために使用してもよい静的構造
• b) 主ボリューム記述子列の位置(絶対論理セクタ番号)
• c) 主ボリューム記述子列の長さ(バイト)

開始ボリューム記述子ポインタのバイト0〜3及び5にあるデータは，必要に応じてフォーマット検証に使用してもよい。バイト4のチェックサム及びバイト8〜11のCRCの検証は，実行すべき適切な追加検証とする。MVDS_Location及びMVDS_Lengthを，この構造から読み出す。

6.9.2.3 手順3 ボリューム記述子列(Volume Descriptor Sequence)

次の論理セクタを読み出す。

MVDS_Location から MVDS_Location+(MVDS_Length-1)/セクタ長

論理セクタ長は，DVD媒体では2048バイトとする。 この列が読み出せない場合，予備ボリューム記述子列を読み出すのが望ましい。

区画記述子は，値5のタグ識別子をもつ記述子とする。区画番号及び論理セクタ番号による区画位置が記録されるものとする。

この構造から，Partition_Location及びPartition_Lengthを得る。

論理ボリューム記述子は，値6のタグ識別子をもつ記述子とする。ファイル集合記述子の位置及び長さが論理ブロック番号で記録されるものとする。

この構造から，FSD_Location及びFSD_Lengthを得る。

6.9.2.4 手順4 ファイル集合記述子(File Set Descriptor)

　 ファイル集合記述子は，次に示す論理セクタ番号の論理セクタに存在する。

Partition_Location+FSD_Location から
Partition_Location+FSD_Location+(FSD_Length-1)/ブロック長

RootDir_Location及びRootDir_Lengthを，論理ブロック番号によりファイル集合記述子から読み出すものとする。

6.9.2.5 手順5 ルートディレクトリのファイルエントリ(Root Directory File Entry)

RootDir_Location及びRootDir_Lengthは，ファイルエントリの位置を定義する。このファイルエントリは，ルートディレクトリのデータ空間及び許可条件を記述する。

ルートディレクトリの位置及び長さを得る。

6.9.2.6 手順6 ルートディレクトリ(Root Directory)

"VIDEO_TS"サブディレクトリを見つけるために，ルートディレクトリエクステント中のデータを解釈する。

VIDEO_TSファイル識別子記述子を見つける。その名前は，8ビットの圧縮UDFフォーマットとする。VIDEO_TSが，ディレクトリであることを検証する。

ファイル識別子記述子を読み出し，VIDEO_TSディレクトリを記述するファイルエントリの位置及び長さを得る。

6.9.2.7 手順7 VIDEO_TSのファイルエントリ(File Entry of VIDEO_TS)

前述の段階で見つけたファイルエントリは，VIDEO_TSディレクトリのデータ空間及び許可条件を含む。

VIDEO_TSディレクトリの位置及び長さを得る。

6.9.2.8 手順8 VIDEO_TSディレクトリ(VIDEO_TS Directory)

前述の段階で見つけたエクステントは，ファイル識別子記述子の集合を含む。このパスでは，エントリがファイルをポイント史VIDEO_TS.IFOという名前をもつことを検証する。

6.9.2.9 手順9 VIDEO_TS.IFOのファイルエントリ(File Entry of VIDEO_TS.IFO)

前述の段階で見つけたファイルエントリは，VIDEO_TS.IFOファイルのデータ空間及び許可条件を含む。

VIDEO_TS.IFOファイルの位置及び長さが返される。

必要ならば，他のファイルは，VIDEO_TS.IFOファイルと同じ方法で見つけることができる。

6.9.3 DVD関連文献の入手(Obtaining DVD Document)

文献"DVD Specifications for Read-Only Disc”及び他のDVD関連資料のコピーを入手するには，次に連絡されたい。

　　　　Toshiba Corporation
        DVD Business Promotion ＆ Support
        DVD Products Division
        Attn: Senior Manager
        TEL: 03-3457-2473
        FAX: 03-5444-9430

6.10 CD媒体に関する勧告

CD媒体(CD-R及びCD-RW)は，その特徴により，特別な配慮を必要とする。CDは元々，書込み方法に影響を与える，再生専用アプリケーション用に設計された。次の指針は，交換を確実に行うために作られた。

各ファイル及びディレクトリは，1個の直接ICBで記述するものとする。そのICBは，書込み中のデータ不足を見込んで，ファイルデータの後で書込まれるのが望ましいが，これは，ファイルデータの論理ギャップを引き起こす。ICBは，後で書込むことができるが，このことは，ファイルデータのすべてのエクステントを正しく識別する。ICBは，データトラック，ファイルシステムトラック(もし存在すれば)，又は両方に書込まれるものとする。

6.10.1 CD-R媒体でのUDFの使用

JIS X 0607では，セクタ256及び，N又は(N-256)のいずれかで(この場合，ｎは，媒体に最後に記録された物理番地とする)，開始ボリューム記述子ポインタ(AVDP)を必要とする。UDFでは，各セションが閉じると(2.2.3)，セクタ256及びセクタ(N-256)の両方でAVDPを記録することを要求する。ファイルシステムは，閉じる前は中間状態にあり，まだ交換可能状態であるが，JIS X 0607と厳密に互換性がなくてもよい。中間状態では，ただ一つのAVDPが存在する。セクタ256に存在するのが望ましいが，トラック予備のためにそれが不可能な場合は，セクタ512に存在するものとする。

処理システムでは，ファイルシステム管理構造を仮想空間に，ファイルデータは，現実の空間に置くのが望ましい。読取り装置処理システムは，VAT全体をキャッシュメモリに入れてもよい。VATの大きさは，UDFに基くソフトで検討するのが望ましい。コンピュータを基本にした処理システムでは，最低64Kバイトの大きさのVATを扱う。専用プレーヤ処理システムでは，より小さいサイズだけを扱ってもよい。

VATは，未完成媒体の場合は，READ TRACK INFORMATIONを，又，完成媒体の場合は，READ TOC又はREAD CD RECORDED CAPACITYを使用して位置を決めてもよい。X3T10-1048D(SCSI-3 マルチメディアコマンド)を参照。

6.10.1.1 要求事項

a) 書込みでは，モード1又はモード2フォーム1セクタを使用するものとする。1枚のディスクで，モード1又は，モード2フォーム1を使用するものとする。1枚のディスクでモード1とモード2フォーム1セクタを混合して使用することはできない。

b) モード2フォーム1を使用する場合，利用者データファイル及びUDF構造で使用されるすべてのセクタのサブヘッダバイトは，次の値をもつものとする。

ファイル数=0
チャネル数=0
サブモード=08h
コード化情報=0

c) 中間状態は，ただ一つのADVPが記録されるCD-R媒体で可能とする。この一つのAVDPは，セクタ256又はセクタ512にあるものとし，次の複セション規則に従う。

d) 連続ファイルシステムの書込みは可変パケットライトで行うものとする。これは，大小の更新に最大空間効率を可能にする。現在の様式では，固定パケットが要求する第2方式アドレッシングをサポートしないので，可変パケットライトは，CD-ROMドライブとより互換性がある。

e) 論理ボリューム保全記述子は記録するものとし，ボリュームは開放と表示するものとする。論理ボリュームの保全性は，最後に記録された物理番地にVAT ICBを見つけることで証明できる。VAT ICBが存在すれば，ボリュームはきれいであり，存在していなければ，汚れている。

f) 区画ヘッダ記述子が記録されると，未割付け空間表，未割付け空間ビットマップ，区画保全表，空き空間表，及び空き空間ビットマップは規定してはならない。ドライブは，空き空間を直接報告することができ，分離記述子の必要性を取り除く。

g) 各表面には，0又は1個の読み出し専用区画，0又は1個の追記区画，及び，0又は1個の仮想区画が含まれるものとする。CD媒体は，1個の追記区画及び，1個の仮想区画を含むのが望ましい。

6.10.1.2 "ブリッジ"フォーマット

JIS X 0606では，セクタ16に主ボリューム記述子(PVD)を要求する。JIS X 0606ファイルシステムが要求すれば，JIS X 0607構造でアクセスされる，同一ファイルへのアクセスを含んでもよい。また，異なるファイル集合へのアクセス，又は，両方の組み合わせを含んでもよい。

初期の処理システムでは，JIS X 0606構造を記録するが，UDFの処理システムが利用可能になると，JIS X 0606構造の必要性は低下することが確実とする。

JIS X 0606ブリッジディスクにモード2フォーム1セクタが含まれる場合，JIS X 0606のCD-ROM XA拡張子を使用しなければならない。

6.10.1.3 セションデータの末端

CD-ROMドライブが読み取りを行えるように，セションは閉じられる。ディスク上の最後の完全セションは完全にJIS X 0607に従い，2個のAVDPを記録するものとする。これは，次のセションデータ表の末端に従って，データを書込むことで完成するものとする。次の例に示されてはいないが，データは複数のパケットに書込んでもよい。

表6.5 セションデータの末端

数	記述
1	開始ボリューム記述子ポインタ
255	処理システム仕様。利用者データ，ファイルシステム構造，リンク領域を含んでもよい。
1	VAT ICB

処理システム仕様データは，VAT及び，VAT ICBの反復コピーを含んでもよい。最後のセクタの位置を正確に報告しないドライブとの互換性が高まる。処理システムでは，セションデータの最後尾を記録するのに十分な空間が利用できることが確実にしなければならない。セションデータの最後尾を記録することにより，ボリュームはJIS X 0607に一致する。

6.10.2 CD-RW媒体でのUDFの使用

CD-RW媒体は，任意の読み出し及びブロックの書込みができる。つまり，個々のセクタを読み取るとき，複数セクタを含むブロックで書込みが行われなければならない。CD-RWシステムでは，不良領域の予備は用意しない。書込み規則及び予備機構は定義されている。

6.10.2.1 要求事項

a) この規定のこの節に一致して書込みを行う場合，固定長パケットを使用するものとする。

b) 書込みは，モード1又はモード2，フォーム1セクタを使用して行うものとする。1枚のディスクではモード1又はモード2フォーム1を使用するものとする。

c) モード2フォーム1を使用する場合，利用者データファイル及びUDF構造で使用するすべてのセクタのサブヘッダバイトは次の値をもつものとする。

ファイル数=0
チャネル数=0
サブモード=08h
コード化情報=0

d) ホストでは，2Kセクタの書込みを明確に行えるように，読み出し/訂正/書込みを実行するものとする。

e) パケット長はディスクのフォーマット時に設定するものとする。パケット長は32セクタ(64KB)とする。

f) ホストでは，割付け禁止空間リストを使用して，ディスクに欠陥リストを保守するものとする。(3.3.7.1.2を参照。)

g) 予備は，予備可能区画及び予備表を介してホストが管理するものとする。

h) ディスクは使用前に初期化するものとする。

6.10.2.2 初期化

初期化は，リードイン，利用者データ領域，リードアウトから成るものとする。これらの領域は，任意の順序で書込みをしてもよい。この物理的フォーマットには，検証パスが続いてもよい。検証パスの間に見つかる欠陥は，割付け禁止空間リストに列挙しなければならない(3.3.7.1.2を参照。)。最後にファイルシステムルート構造が記録されるものとする。これらの強制的なファイルシステム及びルート構造にはボリューム認識列，開始ボリューム記述子ポインタ，ボリューム記述子列，ファイルセット記述子，及びルートディレクトリが含まれる。

開始ボリューム記述子ポインタはセクタ256及びN-256に記録しなければならないが，この場合，Nは，番地付け可能な最後のセクタの物理番地とする。

予備の割付けは，初期化プロセスの間に行うものとする。予備割付けの長さは0でもよい。

空き空間記述子を，欠陥領域及びセクタ予備領域に割り付けられた空間を反映するように，記録しなければならない。

フォーマットは，媒体で利用可能なすべての空間を含んでよい。しかし，利用者が要求した場合，初期化時間を節約するため，部分集合を初期化してもよい。その，少量のフォーマットを，後に，完全に利用可能な空間に"成長"させてもよい。

6.10.2.3 成長するフォーマット

媒体を部分的に初期化し，後に大きく成長させてもよい。この動作は次の要素から成る。

• a) 最後のセションのリードインを任意に消去する。
• b) 最後のセションのリードアウトを任意に消去する。
• c) パケットの書込みを，事前に記録した最後のパケットのすぐ後から始める。
• d) 予備表更新は，新しい空間領域を反映する。
• e) 区画マップを適宜調節する。
• f) 新しく利用可能な領域を示すために，空き空間を更新する。
• g) 最後のAVDPを新しい(N-256)に移動する。
• h) リードイン(新しいトラックサイズを反映する)の書込みをする。
• i) リードアウトの書込みをする。

6.10.2.4 ホストベースの欠陥管理

ホストでは欠陥管理動作を行うものとする。CDフォーマットは欠陥管理を含めないで定義されたので，現存の技術及びコンポーネントと互換性をもたせるには，ホストで欠陥を管理しなければならない。初期化時に不良セクタを表示し，オンラインで予備を割り当てるのが，欠陥管理の2段階とする。ホストは現在の媒体に表を保持するものとする。

6.10.2.5 読み出し訂正書込み動作

CD-RW媒体は大きな書込み可能単位を必要とする。これは，各装置が，14KBオーバヘッドを受けるためとする。ファイルシステムは2KBの書込み可能単位を必要とする。書込みサイズの差は，ホストの読み出し−訂正−書込み動作で処理される。パケット全体が読み取られ，適切な部分が訂正され，パケット全体がCDに書込まれる。

パケットは，32セクタ境界に整列しなくてもよい。

6.10.2.6 適合のレベル

6.10.2.6.1 レベル1

ディスクは，厳密に1個のリードイン，プログラム領域，及びリードアウトで初期化するものとする。プログラム領域は，厳密に1個のトラックを含むものとする。区画は，パケット境界で開始するものとする。区画長はパケットサイズの整数倍とする。

6.10.2.6.2 レベル2

最後のセションはUDFファイルシステムを含むものとする。事前のすべてのセションは，1個の読み出し専用区画に含まれるものとする。

6.10.2.6.3 レベル3

いかなる制約も適用してはならない。

6.10.3 複セション及び混合モード

ボリューム認識列及び開始ボリューム記述子ポインタの位置は，ディスクの始まりに関連する位置であると，JIS X 0607で規定されている。ディスクの始まりは，VRS及びAVDPを見つける目的で，基本番地Sから決定するものとする。

'S'は，ボリュームの最後の既存のセション内に記録された，最初のデータトラックの，最初のデータセクタの物理番地とする。'S'は，複セションのJIS X 0606の記録で現在使われているもと同じ値とする。このセションの最初のトラックはデータトラックとする。

'N'はディスクに記録された最後のデータセクタの物理セクタ数とする。任意書込みモードを使用する場合，媒体は０又は１のオーディオセションで初期化し，その後に，1個のトラックを含む，書込み可能なデータセションを厳密に1個続けてもよい。他のセションの構成も可能だが，ここでは記述していない。1回に1個だけ書込み可能区画又はセションがあるものとし，このセションはディスクでは最後のセションとする。

6.10.3.1 ボリューム認識列

複セションディスクを扱うために，次の記述をUDFに加える(JIS X 0607第2部参照)。

• a) UDFブリッジフォーマットのボリューム認識領域は，セクタS+16で始まるボリューム空間の一部とする。
• b) ボリューム認識空間の，始まりと終わりのトラックは同じとする。この定義の結果，ボリューム認識領域は常にディスクの最後のセションに存在する。
• c) 任意アクセスモードで記録するとき，重複ボリューム認識列は，セクタN-16から記録を始めるのが望ましい。

6.10.3.2 開始ボリューム記述子ポインタ

開始ボリューム記述子ポインタ(AVDP)は，S+256及びN-256の論理セクタ数に記録するものとする。セクタN-256のAVDPはセションを閉じる前に記録するものとする。セションを開放している間は，記録しなくてもよい。

6.10.3.3 UDFブリッジフォーマット

UDFブリッジフォーマットにより，UDFは，別のファイルシステムを含んでいるディスクに加えることができる。UDFブリッジディスクは，最後のセションにUDFファイルシステムを含むものとする。最後のセションは，前述の"複セションと混合モード"に記述された規則に従うものとする。このディスクは，JIS X 0606，オーディオ，ベンター一意，又は，結合されたファイルシステムに基くセションを含んでもよい。UDFブリッジフォーマットにより，CD強化ディスクが作成できる。

新しい主ボリューム記述子列及び予備ボリューム記述子列は, 各追加セションに存在してもよく，前のVDSと異なってもよい。

CDの最後のセションが，有効なUDFファイルシステムを含まない場合，そのディスクはUDFディスクではない。最後のセションのUDF構造，UDF構造，及びそれらで参照されるデータだけが有効とする。

UDFセションは，他のセションのデータ又はメタデータを示すポインタ，UDFセション内だけにあるデータ又はメタデータを示すポインタ，又は両方のセションを結合した場合のデータ又はメタデータを示すポインタを含んでもよい。UDFブリッジディスクのいくつかの例を次に示す。

図6.1 複セションUDFディスク

図6.2 CD強化ディスク

図6.3 JIS X 0606のUDFへの変換

図6.4 異種フォーマットのUDFへの変換

6.11 UDF媒体フォーマット改訂履歴

次の表は，媒体に記録できるUDFフォーマットに影響するUDF定義の変更がいつ行われたかを示す。各変更を示す文書変更通知(DCN)が表中に記入してある。変更UDF版数の欄には，変更を含むUDF規定の版数を示す。UDF読出し最小版数及びUDF書込み最小版数の欄は，2.2.6.4で記述する版数アクセス制御欄に関連する。

表6.6 改訂履歴

記述	DCN	変更UDF版数	UDF読出し最小版数	UDF書込み最小版数
割付けエクステント記述子	2-002	1.02	1.02	1.02
パス要素ファイル版数	2-003	1.02	1.02	1.02
親ディレクトリエントリ	2-004	1.02	1.02	1.02
装置仕様拡張属性	2-005	1.02	1.01	1.02
最大論理エクステント長	2-006	1.02	1.02	1.02
未割付け空間エントリ	2-008	1.02	1.01	1.02
DVD著作権管理情報	2-009	1.02	1.02	1.02
論理ボリューム識別子	2-010	1.02	1.01	1.02
割付け記述子のエクステント長欄	2-012	1.02	1.01	1.02
再配置禁止フラグ及び連続フラグ	2-013	1.02	1.01	1.02
DVD-ROMに対する要件の改版	2-014	1.02	1.02	1.02
版数アクセス制御	2-015	1.02	1.01	1.02
ボリューム集合識別子	2-017	1.02	1.01	1.02
拡張IDの一意属性	2-018	1.02	1.02	1.02
Dstringの明確化	2-01	1.02	1.01	1.02
アプリケーションFreeEASpace拡張属性	2-020	1.02	1.02	1.02
識別子添字の1.02への変更	2-021	1.02	1.02	1.02
識別子添字の1.50への変更	2-025	1.50	1.50	1.50
仮想区画マップエントリ	2-026	1.50	1.50	1.50
予備区画マップの割付け	2-027	1.50	1.50	1.50
仮想割付け表の追加	2-028	1.50	1.50	1.50
予備表の追加	2-029	1.50	1.50	1.50
割付け禁止空間リストの追加	2-030	1.50	1.02	1.50
CD媒体の推薦	2-031	1.50	1.50	1.50
1.50から2.00への変更	2-033	2.00	1.02	2.00
明確化されたドメインフラグ	2-034	2.00	1.02	2.00
Unicode2.0のサポート	2-035	2.00	1.02	2.00
名前付きストリーム	2-036	2.00	2.00	2.00
名前付きストリームとしての一意ID表	2-037	2.00	1.02	2.00
名前付きストリームとしてのMacリソースフォーク	2-038	2.00	2.00	2.00
拡張属性ヘッダの位置欄	2-043	2.00	1.02	2.00
アクセス管理リスト	2-044	2.00	2.00	2.00
ブロック境界にまたがる記述子タグ	2-047	2.00	1.02	2.00
パワー較正ストリーム	2-048	2.00	1.02	2.00
CD-R複セションが要求するサポート	2-050	2.00	1.50	2.00
CD-Rの仮想区画用LVIDの欄の値	2-051	2.00	1.50	2.00
ボリュームバックアップ日時を示すシステムストリーム	2-055	2.00	2.00	2.00
新VAT	2-056	2.00	2.00	2.00
制約的仮想番地	2-057	2.00	1.50	2.00
ファイル日時拡張属性	2-058	2.00	1.02	2.00
OS/2 EA ストリーム	2-061	2.00	2.00	2.00
割付け禁止空間ストリーム	2-062	2.00	1.02	2.00