図6.2 複セションUDFディスク
この文書は, 1998年4月にOSTA(Optical Storage Technology Association)から発行されたUniversal Disk Format Specification Revision 2.00を翻訳して, 技術的内容を変更することなく作成した標準仕様書(TS)である。
この標準仕様書(TS)は，JIS X 0607の部分集合を規定する。データ交換を最大限にすること，並びにJIS X 0607を実施するためのコスト及び複雑性を最小限にすることを, その主な目的とする。
この課題を達成するために，規定範囲を定義する。規定範囲は，JIS X 0607の使用上の規則及び制限を定義する。ここで定義する規定範囲を，UDFの適用範囲(UDF Compliant domain)とする。
この標準仕様書(TS)は，オペレーティングシステムごとにJIS X 0607の構造に関する次の課題に応える。
JIS X 0607の構造Xが与えられたとき，その構造Xの各欄について，指定されたオペレーティングシステムに関する次の課題に回答する。
- a) その欄の読出しオペレーティングシステムが，その欄中のデータを利用可能である場合，そのオペレーティングシステムにおける何に対して，その欄は対応しなければならないか。
- b) その欄の読出しオペレーティングシステムが，その欄中のデータを制約付きで利用可能である場合，そのオペレーティングシステムにおいて，その欄をどのように解釈しなければならないか。
- c) その欄の読出しオペレーティングシステムが，その欄中のデータを利用可能でない場合，そのオペレーティングシステムにおいて，その欄をどのように解釈しなければならないか。
- d) その欄の書込みオペレーティングシステムが，その欄中のデータを利用可能である場合，そのオペレーティングシステムにおける何から，その欄は対応しなければならないか。
- e) その欄の書込みオペレーティングシステムが，その欄中のデータを利用可能でない場合，オペレーティングシステムにおいて，その欄をどのように解釈しなければならないか。
JIS X 0607の構造のいくつかに関しては，これらの課題への回答は自明であるため，その構造は，ここには含めない。
JIS X 0607を明確にするための補足として，各構造に関する付加情報を提供することがある。
この標準仕様書(TS)は，JIS X 0607を実装する作業を容易にする支援をする。
この標準仕様書(TS)は，JIS X 0607が規定する構造の扱いについての情報を与える。
この標準仕様書(TS)は，次に示す四つの基本的な節から成る。
この標準仕様書(TS)は，JIS X 0607で定義する構造の扱いに関する情報を提供し，次に示す分野をカバーしている。
各構造の欄がまず示され，次いで前述の分類に関して各欄の記述がある。各欄の記述情報で補足する。欄に関する意味が明白な場合には，構造の1個以上の欄を，記述しない場合がある。
用語遣い この標準仕様書(TS)では, "でなければならない(shall)"は必須の行為又は要件を示し, "してよい(may)"はオプションの行為又は要件を示し, "であることが望ましい(should)"は推奨するがオプションである行為又は要件を示す。
欄及び/又は構造に関連する特別な注釈は，"備考"と前置きして示す。
この標準仕様書(TS)は，JIS X 0607の第1部,第2部,第3部及び第4部への適合性を必要とする。この標準仕様書(TS)は，JIS X 0607の第5部への適合性はサポートしない。
ある処理システムがこの標準仕様書(TS)への適合性を主張するためには，その処理システムは，この標準仕様書(TS)で規定するすべての(必須の)要件を満たさなければならない。
適合性に関していくつかの要点を次に確認する。
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:2005, 120mm再生専用形光ディスク(CD-ROM)
備考1 ISO/IEC 10149:1995, Data interchange on read-only 120mm optical data disc (CD-ROM)が, この規格に一致している。
備考2 Yellow Book: Compact Disc Read Only Memory System Description が, この規格に対応している。
TS X 0025:2005, 追記形コンパクトディスク(CD-R)システム
備考 Orange Book, Recordable Compact Disc System, part-II が, この規定に一致している。
Orange Book, Recordable Compact Disc System, part-III
JIS X 0607:2001 非逐次記録を用いる追記形及び書換形の情報交換用媒体のボリューム及びファイルの構造
備考1 ISO/IEC 13346:1999 Volume and file structure of write-once and rewritable media using non-sequential recording for information interchange が, この規格に一致している。
備考2 ECMA 167 3rd Edition, Volume and file structure of write-once and rewritable media using non-sequential recording for information interchange も, この規格に一致している。
備考3 この標準仕様書(TS)において[ ]で括られた参照は, ISO/IEC 13346:1999 を[x/a.b.c]の様式で参照し, ここで，xは節番号，a.b.c.は項又は図の番号とする。
1.3.2.1 オーディオセション (Audio session) 一つ又は複数のオーディオトラックを含み，データトラックを含まない。
1.3.2.2 オーディオトラック (Audio track) JIS S 8605が規定するオーディオセクタを含む設計がなされたトラック。
1.3.2.3 CD-R (CD-Recordable) 追記形CD。TS X 0025が規定する追記形コンパクトディスク。
1.3.2.4 CD-RW (CD-Rewritable) 書換形CD。Orange Book，part-IIIが規定する重ね書き可能なコンパクトディスク。
1.3.2.5 クリーンファイルシステム (Clean File System) この標準仕様書(TS)に適合する媒体のファイルシステム。
1.3.2.6 データトラック (Data track) JIS X 6281が規定するデータセクタを含む設計がなされたトラック。
1.3.2.7 ダーティファイルシステム (Dirty File System) クリーンファイルシステムではないファイルシステム。
1.3.2.8 固定パケット (Fixed Packet) 与えられたトラックに含まれるパケットすべてが，トラック記述子ブロックに指定された長さをもつ，インクリメンタル記録方式。CDドライブに提示される番地は，TS 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ドライブに提示される番地は，TS 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 してよい (May) オプションの行為又は機能を示す。
1.3.3.2 オプションの (Optional) 実装しても，しなくてもよい機能を示す。実装する場合，その機能は規定どおりに実装しなければならない。
1.3.3.3 でなければならない (Shall) 必須であってこの標準仕様書(TS)に適合していることを主張するために実装しなければならない行為又は機能を示す。
1.3.3.4 望ましい (Should) オプションではあるが，その実装が強く推奨される行為又は機能を示す。
1.3.3.5 予備の (Reserved) 予備欄は，将来の使用のために確保され，ZEROに設定しなければならない。予備の値は, 将来の使用のために確保され，使用してはならない。
次の表2.1は，この標準仕様書(TS)が定義する基本制約及び基本要件のいくつかを要約している。これらの制約及び要件は，追加の制約及び要件とともに，この標準仕様書(TS)の以降の節で詳細に記述する。
| 項目 | 制約及び要件 |
|---|---|
| 論理セクタ長 | 特定のボリュームに関する論理セクタ長は，この特定のボリュームの物理セクタ長と同じとする。 |
| 論理ブロック長 | 論理ボリュームに関する論理ブロック長は，この特定の論理ボリュームが存在するボリューム又はボリューム集合の論理セクタ長に設定しなければならない。 |
| ボリューム集合 | 同一ボリューム集合中のすべての媒体は，同じ物理セクタ長をもつものとする。書換形/上書き可能形の媒体及び追記形の媒体は，同一ボリューム集合に混在してはならない｡ |
| ボリューム空間の最初の32Kバイト | ボリューム空間の最初の32768バイトは，JIS X 0607の構造の記録に使用してはならない。この領域は，未割付け空間記述子又は他のいかなるJIS X 0607の記述子も参照してはならない。この領域は，元のオペレーティングシステムでの自由使用に任されている。 |
| ボリューム認識列 | JIS X 0607の第2部の規定に従ってボリューム認識列を記録しなければならない。 |
| 日時表示 | すべての日時表示は，現地時で記録しなければならない。時間帯は，時間帯の概念をサポートするオペレーティングシステムに従って記録しなければならない。 |
| 実体識別子 | 実体識別子は，この標準仕様書(TS)に従って記録しなければならない。この規定で特記しない限り，実体識別子は，処理システムを一意に識別する値を含まなければならない。 |
| 記述子CRC | CRCは，空間ビットマップ記述子を除くすべての記述子に関して, 利用可能で，計算されなければならない。 |
| ファイル名の長さ | 最大255バイトとする。 |
| パス長 | 最大1023バイトとする。 |
| エクステント長 | 最大エクステント長は，[230-(論理ブロック長)]バイトとする。仮想区画における最大エクステント長は論理ブロックサイズとする。 |
| 基本ボリューム記述子 | ボリュームごとにただ一つの最新の基本ボリューム記述子を記録しなければならない。 |
| 開始ボリューム記述子ポインタ | ボリュームの最大セクタ番号をNとするとき，256, N-256又はNの3位置の少なくとも2箇所に記録しなければならない。 |
| 区画記述子 | 再生専用形，書換形/上書き可能形及び追記形の区画アクセス種別を利用可能とする。次に示す一つの例外を除き，ボリュームごとにただ一つの種別1の最新の区画記述子を記録しなければならない。単一ボリュームで構成するボリューム集合において，一つの区画が再生専用のアクセス種別をもち，他区画が書換形/上書き可能形のアクセス種別をもつ場合だけ，ボリュームは二つの最新の区画記述子とともに，二つの区画を含んでもよい。このボリュームの論理ボリュームは，両方の区画の内容で構成する。 |
| 論理ボリューム記述子 |
ボリューム集合ごとにただ一つの最新のボリューム記述子を記録する。 論理ボリューム識別子欄は，空にしてはならず，論理ボリュームの識別のための識別子を含むことが望ましい。特に，この規定に適合するボリュームを作成するソフトウェアは，この欄に固定の値又は無意味な値を設定してはならない。同一であることを意図する重複ディスクは，この欄が同一の値でもよい。この欄は，ジュークボックス中に複数の媒体が存在するときの，論理ボリュームの識別のために，特に重要となる。この名前は，典型的には，利用者に表示するものとする。 |
| 論理ボリューム保全記述子 | 記録しなければならない。LVIDのエクステントは，エクステント長で終了してもよい。 |
| 未割付け空間記述子 | ボリュームごとに一つだけの最新の未割付け空間記述子を記録する。 |
| ファイル集合記述子 | 書換形/上書き可能形の媒体中の論理ボリュームごとに一つだけのファイル集合記述子を記録する。追記形の媒体においては，この標準仕様書(TS)で定義する制約に従って複数のファイル集合記述子を記録してもよい。ファイル集合記述子のファイル集合識別子欄は，利用者に対して論理ボリュームを識別するために，別名として使用できる名前を使用してもよい。詳細は，2.3.2.7を参照。FSDエクステントは，エクステント長で終了してもよい。 |
| ICBタグ | 方策種別4又は方策種別4096だけを記録しなければならない｡ |
| ファイル識別記述子 | ファイル識別記述子の長さの合計は，一つの論理ブロック長を超えてはならない。 |
| ファイルエントリ | ファイルエントリの長さの合計は，一つの論理ブロック長を超えてはならない。 |
| 割付け記述子 | 短割付け記述子及び長割付け記述子だけを記録できる。 |
| 割付けエクステント記述子 | 一つの割付けエクステントの長さは，論理ブロック長を超えてはならない。 |
| 未割付け空間エントリ | 未割付け空間エントリの長さの合計は，論理ブロック長を超えてはならない。 |
| 空間ビットマップ記述子 | CRCは必要でない。 |
| 区画保全エントリ | 記録してはならない。 |
| ボリューム記述列エクステント | 主ボリューム記述子列エクステント及び予備ボリューム記述子列エクステントの両方とも，最小長16個の論理セクタで構成しなければならない。VDSエクステントはエクステント長で終了してもよい。 |
| レコード構造 | JIS X 0607の第5部で定義するレコード構造ファイルは, 作成してはならない。 |
参考 この規定における第n部(n=1〜5)の表記は, JIS X 0607の第n部の規定内容への対応を示す。
この標準仕様書(TS)で定義する構造に関して，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フォーマットで記録される。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 1 | 圧縮識別子 | Uint8 |
| 1 | ?? | 圧縮ビット列 | バイト |
圧縮識別子は，圧縮ビット列欄の圧縮に使用する圧縮アルゴリズムを識別する。表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の圧縮識別子と，ファイル識別子のバイトのオフセットを使ってもよい。
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"
この標準仕様書(TS)と同様に，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を設定することによって記録する。
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;
}
次の記述において，種別は，この欄の最上位4ビットを示し，時間帯は，この欄の最下位12ビットを示す。
備考 協定世界時の時間帯西は, 負の時間差をもつ。例えば，東標準時は-300分であり，東の夏時間は-240分とする。
struct EntityID{ /* ECMA 167 1/7.4 */
Uint8 Flags;
char Identifier[23];
char IdentifierSuffix[8];
}
UDFは，実体識別子を次に示す三つの種別に分類する。
以降の節で，これらの異なる種別に基づいて実体識別子のフォーマット及び使用方法を示す。
この標準仕様書(TS)では，特記しない限り，この欄には，処理システムを一意に識別する識別子を設定しなければならない。この方法は，異なる処理システム間で交換する媒体中に記録した構造が，どの処理システムによるものかの識別を可能にする。
処理システムが，他の処理システムで書き込んだ媒体中に存在する構造を更新する場合，現状の処理システムは，現状の処理システムを一意に識別する値を識別子欄に設定しなければならない。
表2.4は，JIS X 0607及びこの標準仕様書(TS)で定義する実体識別子欄を要約したものであり，設定しなければならない値を示す。
| 記述子 | 欄 | 識別子値 | 添字種別 |
|---|---|---|---|
| 基本ボリューム記述子 | 処理システム識別子 | "*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製品の現在の版数を記録することを選択してよい。この情報は，異なる会社の複数の製品がメディアに記録していた場合，どの処理システムがメディアの一部に不適切な構造を書き込んだのかを決定する際，非常に助けになる。
実体識別子の表の添字種別欄は，相当する実体識別子で使用する添字のフォーマットを定義する。これらの異なる添字種別は，次の節で定義する。
備考 この標準仕様書(TS)(附属書6.1)で定義するすべての識別子は，UDF識別子としてOSTAが登録しなければならない。
識別子欄のフォーマットは，識別子の種別に依存する。
この標準仕様書(TS)(附属書6.1)で規定するOSTA範囲実体識別子に関しては，識別子添字欄を次に示す構成とする。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 2 | UDF版数 | Uint16(=#0200) |
| 2 | 1 | 範囲フラグ | Uint8 |
| 3 | 5 | 予備 | バイト(=#00) |
UDF版数欄は，この標準仕様書(TS)の版数2.00を示す値#0200を設定する。この欄は，この標準仕様書(TS)の改訂版に加えられた変更を，処理システムが検出することを可能にする。OSTA範囲識別子は，論理ボリューム記述子及びファイル集合記述子だけに使用する。範囲フラグ欄は，次に示すビットフラグを定義する。
| 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)で定義する処理システム用実体識別子に対しては，識別子添字欄は，次にに示す構成とする。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 2 | UDF版数 | Uint16(=#0200) |
| 2 | 1 | オペレーティングシステムクラス | Uint8 |
| 3 | 1 | オペレーティングシステム識別子 | Uint8 |
| 4 | 4 | 予備 | バイト(=#00) |
オペレーティングシステムクラス及びオペレーティングシステム識別子欄の内容は，オペレーティングシステム識別子に関する附属書に記述する。
UDFで定義しない実体識別子を使用する処理システムに関して，識別子添字欄は，表2.8に示す構成とする。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 1 | オペレーティングシステムクラス | Uint8 |
| 1 | 1 | オペレーティングシステム識別子 | Uint8 |
| 2 | 6 | 処理システム用領域 | バイト |
備考 オペレーティングシステムクラス欄及びオペレーティングシステム識別子欄の意図した使用並びに重要性を理解することが重要になる。これらの欄の主な目的は，UDFボリューム中で問題を検出したときに，誤りを取り除く支援をすることとする。この欄は，利用者に提供可能な有効な情報も提供する。これらの二つの欄を正しく設定した場合，処理システムに次の情報を提供する。
struct tag{ /* ECMA 167 3/7.2 */
Uint16 TagIdentifier;
Uint16 DescriptorVersion;
Uint8 TagChecksum;
byte Reserved;
Uint16 TagSerialNumber;
Uint16 DescriptorCRC;
Uint16 DescriptorCRCLength;
Uint32 TagLocation;
}
タグ通し番号は，ボリュームの再初期化時には，以前に記録した値と異なる値を設定しなければならない。タグ通し番号=((基本ボリューム記述子のタグ通し番号)+1)であることを推奨する。
CRCは，各記述子で利用可能であり，計算されなければならない。この欄の値は，(記述子の大きさ)−(記述子タグの長さ)を設定しなければならない。記述子を読み出すときは，CRCを検証するのが望ましい。
仮想番地でアクセスする(即ちVATでアクセスする)構造では，この値は，仮想番地であり，物理番地又は論理番地ではない。
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];
}
JIS X 0607は，規定する現状の交換水準に関連する制限の実施を処理システムに要求する。処理システムは，交換最大水準欄の値を超えない限り，この欄の値を変更してもよい。
備考 この欄は，ボリューム作成者の意図の指定に使用する。この欄が値2の場合，作成者の意図は, このボリュームが複数ボリュームから成るボリューム集合(交換水準3)に属さないこととする。受領者は，この欄を無視して値3を設定してもよいが，その場合には，処理システムはボリューム作成者の意図を示す警告を受領者に与えることが望ましい。
備考 ここで意図する目的は，一意の識別子をもつボリューム集合の保証にある。この欄の最初の16文字において，最初の8文字は，32ビットの日時の値のCS0による16進表示とするのが望ましく，残りの8文字は，処理システム用に任されている。
この欄の適切な扱いに関する詳細情報は，2.1.5を参照のこと。
struct AnchorVolumeDescriptorPointer{ /* ECMA 1673/10.2 */
struct tag DescriptorTag;
struct extent_ad MainVolumeDescriptorSequenceExtent;
struct extent_ad ReserveVolumeDescriptorSequenceExtent;
byte Reserved[480];
}
備考1 開始ボリューム記述子ポインタ構造は，媒体中の次に示す三つの位置のうち，最低2箇所に記録する。
備考2 閉じていないCD-R媒体では，セクタ512だけに開始ボリューム記述子ポインタが記録されてもよい。閉じる際，CD-R媒体はこれらの規則に従う。
主ボリューム記述子列エクステントは，最小長16論理セクタとする。
予備ボリューム記述子列エクステントは，最小長16論理セクタとする。
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[];
}
備考 この欄の内容が"*OSTA UDF Compliant"でない場合，処理システムは論理ボリュームに対する利用者からのアクセスを拒否してもよい。
"*OSTA UDF Compliant"に指定しなければならない。
実体識別子の節で記述したとおり，実体識別子の識別子添字欄には，論理ボリュームの内容が互換性をもつこの標準仕様書(TS)の版数を含む。この欄の適切な扱いに関する詳細情報は，2.1.5を参照のこと。
備考 実体識別子の識別子添字欄は，ソフト書込み保護フラグ及びハード書込み保護フラグを含む。2.1.4.3を参照のこと。
この欄には，ファイル集合記述子のエクステント位置が含まれる。これは，JIS X 0607の4/3.1に次のとおりに規定される。
ボリュームが"エラー！参照元見つからず"に従って記録される場合，論理ボリュームの最初のファイル集合記述子列が記録されるエクステントは，long_ad(エラー！参照元見つからず｡/エラー！参照元見つからず｡)で識別される。このlong_adは，ファイル集合記述子を記録する論理ボリュームを記述する論理ボリューム記述子の論理ボリューム内容用欄(エラー！参照元見つからず｡/エラー！参照元見つからず，を参照)に記録されている。
この欄は，ファイル集合記述子を見つけるのに使用でき，ファイル集合記述からルートボリュームを見つけることができる。
この欄の適切な扱いに関する詳細情報は，実体識別子の節を参照のこと。
この欄の値は，論理ボリューム保全記述子のために必要となる。書換形/上書き可能形媒体に関しては，最小値8Kバイトを設定しなければならない。
備考 追記形媒体に対しては，この欄は，十分な長さのエクステントを設定するのが望ましい。論理ボリューム保全記述子は，最新論理ボリューム記述子と同一のボリュームに存在しなければならないため，論理ボリューム保全記述子が存在する追記形媒体が一杯になった場合は，ボリューム集合に新しいボリュームを追加しなければならない。
交換の目的として，区画マップは，この標準仕様書(TS)(2.2.8及び2.2.9)に記述されているとおり, 種別2を除き，区画マップ種別1に限定しなければならない。
struct UnallocatedSpaceDesc{ /* ECMA 167 3/10.8 */
struct tag DescriptorTag;
Uint32 VolumeDescriptorSequenceNumber;
Uint32 NumberofAllocationDescriptors;
exted_ad AllocationDescriptors[];
}
使用可能なボリューム空間がない場合でも，この記述子を記録しなければならない。
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[];
}
論理ボリューム保全記述子は，関連する論理ボリュームの内容を更新したときに書き込む構造とする。論理ボリューム保全記述子の内容によって，処理システムは次に示す有用な問いに対し容易に回答できる。
この欄の内容の情報に関しては，論理ボリュームヘッダ記述子の節を参照のこと。
ほとんどのオペレーティングシステムは，媒体のマウント時に，処理システムが論理ボリューム中の利用可能空間の大きさを提供することを要求するため，これらの値をすべての非仮想区画のために保守することは重要となる。有効な利用可能空間の量が不明なことを示す#FFFFFFFFのオプション値は，非仮想区画に使用してはならない。仮想区画については，利用可能空間表を#FFFFFFFFに設定しなければならない。
備考 論理ボリューム保全記述子をクローズ状態にしたときだけ，正しい利用可能空間表を保証する。
ほとんどのオペレーティングシステムは，媒体のマウント時に，処理システムが論理ボリュームの大きさを提供することを要求するため，これらの値をすべての非仮想区画に保守することは重要となる。区画長が不明なことを示す#FFFFFFFFのオプション値は仮想区画に使用してはならない。仮想区画については，サイズ表を#FFFFFFFFに設定しなければならない。
論理ボリューム保全記述子の処理システム用領域は，表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) 処理システム用 処理システム識別子で識別する処理システムだけの固有情報を含む。
struct ImpUseVolumeDescriptor{ /*ECMA 167 3/10.4*/
struct tag DescriptorTag;
Uint32 VolumeDescriptorSequenceNumber;
struct EntityID ImplementationIdentifier;
byte ImplementationUse[460];
}
この節は，UDF処理システム用ボリューム記述子を定義する。この記述子はボリューム集合のすべてのボリュームに記録しなければならない。ボリュームは，処理システム固有の追加の処理システム用ボリューム記述子を含んでもよい。この記述子の意図する目的は，特定の論理ボリュームに属するボリューム集合中のボリュームの識別を支援することとする。
備考 処理システムは，媒体中にそれ自体のフォーマットにおける追加の処理システム用ボリューム記述子を記録してもよい。UDF処理システム用ボリューム記述子は，追加の記述子を除外しない。
この欄は"*UDF LV Info"を指定するものとする。
処理システム用領域は，次に示す構造とする。
struct LVInformation{
struct charspec LVICharset;
dstring LogicalVolumeIdentifier[128];
dstring LVInfo1[36];
dstring LVInfo2[36];
dstring LVInfo3[36];
struct EntityID ImplementationID;
byte ImplementationUse[128];
}
この記述子で参照する論理ボリュームの識別子。
論理ボリューム情報欄(LVInfo1，LVInfo2，LVInfo3)は，媒体の識別を支援する追加情報を含むのが望ましい。例えば，論理ボリューム情報欄は，所有者名，組織名及び連絡先の情報を含むことができる。
実体識別子の節を参照のこと。
この領域は，追加の処理システム固有の情報を記録するために処理システムで使用してもよい。
これは，JIS X 0607の範囲を拡大し，連続書込み媒体(例えばCD-R)を含んだものとする。これを拡大したのは，区画マップエントリが仮想空間を記述するためとする。
論理ボリューム記述子には，与えられたボリュームを構成する区画の一覧が含まれる。仮想区画は，物理区画と同じ方法で記述することはできないので，次に指定する種別2区画マップを使うものとする。
仮想区画マップが記録されると，論理ボリューム記述子は，最低二つの区画マップを含まなければならない。一つの区画マップは種別1の区画マップとして記録しなければならない。もう一つの区画マップは種別2区画マップとして記録しなければならない。この種別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バイト |
特定のディスク/ドライブシステムは欠陥管理を行わない(例えばCD-RW)。これらのシステムに明らかに欠陥のない空間を与えるために，種別2の区画が使われる。区画マップは区画番号，パケットサイズ(1.3.2を参照)，予備テーブルの大きさと位置を定義する。この種別2のマップは，通常の媒体にある種別1のマップと置き換えるためのものとする。このマップは，区画番号とボリューム列番号を識別するだけでなく，パケット長及び予備表を識別する。予備区画マップは，欠陥管理を行うディスクク/ドライブシステムに記録してはならない。
| 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バイト |
仮想割付け表(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は指定されない。
| オフセット | 長さ | 名前 | 内容 |
|---|---|---|---|
| 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
特定のディスク/ドライブシステムは欠陥管理を行わない(例えばCD-RW)。これらのシステムに明らかに欠陥のない空間を作ること。特定のメディアでは，セクタのまとまり(パケット)にだけ書込みができ，再配置をさらに複雑にする。これは, セクタだけが書込まれるのではなく，パケット全体を再配置しなければならないことによる。この問題に取り組むため，区画マップで予備区画を識別するが，これはさらに，予備表の位置を識別する。予備表は媒体上で再配置された領域を識別する。予備表は，予備表区画マップで識別される。予備表は，欠陥管理を行うディスク/ドライブシステムに記録してはならない。
予備表は予備用に割り付けられた空間を示し，取替え部分に対する欠陥セクタの配置リストを含む。予備表の分離コピーは分離パケットに記録しなければならない。予備表は最新のものを維持しなければならない。
区画マップの論理空間を物理空間へ。通常，これは，オフセットと長さが指定される直線配置とする。予備区画ではこの配置に基くが，物理空間内の区画のオフセットと長さは区画記述子で指定される。予備表はさらに，論理配置から物理配置への例外リストを指定する。あらゆる配置の長さは，パケット一つ分とする。パケットサイズは予備区画マップで指定される。
予備領域は，メディアのどの部分でも，つまり区画の内外いずれでもよい。区画の内側の場合，予備空間は割付けられたとして表示され，割付け不可能空間リストに含まれるものとする。マップされた位置は，フォーマット時に埋めるものとする。元の位置は，エラーが起こると，自在に割り当てられる。各予備表は次のような構造とする。
| BP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 16 | 記述子タグ | タグ=0 |
| 16 | 32 | 予備識別子 | EntityID |
| 48 | 2 | 再割付け表長(=RT_L) | Uint16 |
| 50 | 2 | 予備 | #00バイト |
| 52 | 4 | 列番号 | Uint32 |
| 56 | 8*RT_L | マップエントリ | マップエントリ |
この構造は必要ならば一つのセクタより大きくてもよい。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 4 | 元の位置 | Uint32 |
| 4 | 4 | マップ位置 | Uint32 |
struct tag{ /* ECMA 167 4/7.2 */
Uint16 TagIdentifier;
Uint16 DescriptorVersion;
Uint8 TagChecksum;
byte Reserved;
Uint16 TagSerialNumber;
Uint16 DescriptorCRC;
Uint16 DescriptorCRCLength;
Uint32 TagLocation;
}
タグ通し番号は，ボリュームの再初期化時には，以前に記録した値と異なる値を設定しなければならない。この欄の意図する使用方法は，障害回復とする。第4部のすべての記述子のタグ通し番号は，関連するファイル集合記述子に使用した通し番号と同一であるのが望ましい。
特記しない限り，CRCは，各記述子で利用可能であり，計算されなければならない。この欄の値は，(記述子の大きさ)-(記述子タグの長さ) に設定するものとする。記述子を読み出すときは，CRCを検証するのが望ましい。
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で記録する場合，そのファイル集合記述子の範囲識別子にはハード書込み保護を設定しなければならない。
追記形媒体中の複数のファイル集合の意図する目的は，媒体中に複数のアーカイブをサポートする機能を利用可能にすることとする。例えば，一つのファイル集合は，特定の時点で作成した情報集合のバックアップを表現する。
後続のファイル集合は，その後作成した同一情報集合の他のバックアップとして表現する。
処理システムは，規定する現状の交換水準に関連する制限を実施する。
"*OSTA UDF Compliant"に設定しなければならない。
実体識別子の節で記述したとおり，実体識別子の識別子添字欄には，論理ボリュームの内容が互換性をもつ本規定の版数を含む。この欄の適切な扱いに関する詳細情報は，実体識別子の節を参照のこと。
備考 実体識別子の識別子添字欄は，ソフト書込み保護フラグ及びハード書込み保護フラグを含む。
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];
}
要するに，未割付けとした論理ブロックは，前処理なしに書込み可能なブロックとする。書換形媒体の場合，消去処理なしに書き込める。未初期化とした論理ブロックは，書込み準備が必要なブロックであり，何らかの前処理をする必要がある。書換形媒体の場合，消去処理後に書き込む。
備考 空間表又は空間ビットマップの使用は，論理ボリューム中で一貫していなければならない。空間表及び空間ビットマップの両方を一つの論理ボリューム中で同時に使用してはならない。
区画保全エントリは使用しないため，すべて0を指定しなければならない。
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[];
}
ファイル識別記述子は，一つの論理ブロックの長さに制限しなければならない。
削除ビットは，ディレクトリから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は無視してもよい。
あらゆるファイル識別記述子のlong_adの処理システム用バイトは，ファイル及びディレクトリ名前空間のUDF一意IDを記録するのために使用するものとする。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 2 | 予備 | バイト(=#00) |
| 2 | 4 | UDF一意ID | Uint32 |
3.2.1の論理ボリュームヘッダ記述子は，ファイル識別記述子のlong_adの処理システム用バイトにおけるUDF一意ID欄，並びに，ファイルエントリ及び拡張ファイルエントリの一意ID欄の設定方法を記述している。
ファイル識別記述子を追記形媒体に書き込むとき，次のFIDの記述子タグ欄がブロック境界に及ばないことを保証するため，FIDの後の現在のブロックに16未満のバイトが残っていれば，FIDの長さは，これを避けるのに十分なだけ増加する｡(この場合処理システム用欄を使用する｡)CRC長は，FID−16未満の大きさに設定してもよい。(処理システム用領域を含めないため。)
備考 この欄の適切な扱いに関する詳細情報は，実体識別子の節を参照のこと。
この欄は，特定のファイル識別記述子を最後に作成又は更新した処理システムを識別することを処理システムに許可する。
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;
}
備考 附属書で定義する方策種別4096は，追記形媒体中で主に使用する予定であるが，書換形/上書き形媒体で使用してもよい。
標準のバイトで番地付け可能なファイルのために値5を使用し，0は使用しない。
この欄の使用は，オプションとする。
備考 JIS X 0607の4/14.6.7では，この欄が0の場合，そのようなICBを指定していないことを意味する，と規定している。これは，処理システムがICBを論理ブロック番地0に記録できることから，規定の誤りとする。したがって，この欄を使用する場合，ICBを論理ブロック0に記録してはならない。
a) ビット0〜2
これらのビットは，使用する割付け記述子の種別を指定する。使用する割付け記述子種別の選択のガイドラインについては，割付け記述子の節を参照のこと。
b) ビット3(分類)
c) ビット4(再配置不可)
d) ビット9(連続性)
e) ビット11(変換)
データ圧縮法及びその他のデータ変換形式は，将来のOSTAの規定で示す。
f) ビット12(複数版数)
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^30-ブロックサイズバイトを識別する場合，また，最後の割付け記述子の次の部分がブロックサイズの整数倍で，最後の割付け記述子の次の部分に連続していない場合，情報長を確定するために割付け記述子を使うと失敗するだろう。
データを埋め込んだファイル又はディレクトリについて，この欄の値は０とする。
実体識別子の節を参照のこと。
ファイル集合のルートディレクトリに関して，この値は0を指定するものとする。
3.2.1の論理ボリュームヘッダ記述子は，ファイル識別記述子におけるlong_adの処理システム用バイトのUDF一意ID欄並びに，ファイルエントリ及び拡張ファイルエントリの一意IDファイルの設定方法を記述している。
struct UnallocatedSpaceEntry{ /* ECMA 167 4/14.11 */
struct tag DescriptorTag;
struct icbtag ICBTag;
Uint32 LengthofAllocationDescriptors;
byte AllocationDescriptors[];
}
備考 未割付け空間エントリの最大長は，一つの論理ブロック長とする。
短割付け記述子だけを使用する。
備考 割付け記述子中のエクステント長欄の上位2ビットは，エクステント種別(JIS X 0607 4/14.14.1.1)を指定する。未割付け空間エントリで規定する割付け記述子に関して，この種別は，割り付けてはいるが未記録であるエクステントを示す値1に設定し，又はエクステントが割付け記述子の後続エクステントであることを示す値3に指定しなければならない。割付け記述子の後続エクステントは，一つの論理ブロックの長さに制限しなければならない。
割付け記述子は，位置の昇順に連続的に並べるものとする。表中の割付け記述子は重複してはならない。例えば，位置=2,長さ=2048(論理ブロック長=1024)の割付け記述子の次が，位置=3の割付け記述子であることは許されない。隣接する割付け記述子が続いてはならない。例えば，位置=2,長さ=1024(論理ブロック長=1024)の割付け記述子の次が，位置=3の割付け記述子であってはならず，位置=2,長さ=2048の一つの割付け記述子でなければならない。隣接する割付け記述子が続いてもよい唯一の場合は，どちらか一方の隣接する割付け記述子の長さが，割付け記述子で記述可能な最大値のときとする。
struct SpaceBitmap{ /* ECMA 167 4/14.11 */
struct Tag DescriptorTag;
Uint32 NumberOfBits;
Uint32 NumberOfBytes;
byte Bitmap[];
}
空間ビットマップ記述子に関する記述子タグの記述子CRC欄の計算及び保守は，オプションとする。CRCをメンテナンスできない場合，記述子CRC欄及び記述子CRC長欄の両方を0に設定する。
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];
}
論理ボリューム保全記述子の機能により，この記述子は必要でないため，この記述子は記録してはならない。
ファイルのデータ領域を構成するとき，処理システムは，選択対象のいくつかの種別の割付け記述子をもつ。次に示すガイドラインは，使用する適切な割付け記述子の選択時に従うものとする。
a) 短割付け記述子 単一ボリュームを超えて論理ボリュームを拡張する予定のない単一ボリューム中に存在する論理ボリュームに関して，短割付け記述子を使用するのが望ましい。例えば，独立した装置で作成した論理ボリューム。
備考 交換最大水準の2.2.2.2を参照のこと。
b) 長割付け記述子 単一ボリュームを超えて論理ボリュームを後で拡張する予定の単一ボリュームが存在する論理ボリューム又は複数ボリュームに存在する論理ボリュームに関して，長割付け記述子を使用するものとする。例えば，集合形装置で使うために作成した論理ボリューム。
備考 単一ボリューム中でも長割付け記述子を使用する利点はある。この利点は，書換形媒体中の消去したエクステントの追跡を利用可能とすることとする。付加情報については，2.3.10.1を参照のこと。
短割付け記述子及び長割付け記述子の両方に関して，エクステント長欄の下位30ビットが0であれば，上位2ビットは0でなければならない。
仮想空間を識別する割付け記述子は，1個又はそれ以下の，ブロックの拡張長をもつものとする。ファイルデータ，ディレクトリ，又はストリームデータを識別する割付け記述子は物理空間を識別するものとする。仮想空間に記録されたICBは，物理空間を識別するために，long_ad割付け記述子を使用するものとする。short_ad割付け記述子を使用することにより，ICBが仮想空間にあれば，仮想空間のファイルデータを識別するだろう。
仮想空間に記録された記述子は，タグ位置欄に記録された仮想論理ブロック番号をもつものとする。
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を設定するものとする。これは，割り付けたが未記録であるエクステントだけに使用する。
struct AllocationExtentDescriptor{ /* ECMA 167 4/14.5 */
struct tag DescriptorTag;
Uint32 PreviousAllocationExtentLocation;
Uint32 LengthOfAllocationDescriptors;
}
備考 割付け記述子エクステントは，最大長1論理ブロックとする。
struct PathComponent{ /* ECMA 167 4/14.16.1 */
Uint8 ComponentType;
Uint8 LengthofComponentIdentifier;
Uint16 ComponentFileVersionNumber;
char ComponentIdentifier[];
}
レコード構造ファイルは，作成してはならない。これらが媒体中に存在し，処理システムが利用可能でない場合は，内容を解釈しないバイト列として扱うものとする。
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;
}
struct LogicalVolumeHeaderDesc{ /*ECMA 167 4/14.15*/
Uint64 UniqeID,
bytes reserved[24]
}
この欄は，次の段階で使用するのが望ましい，一意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をもつものとする。
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で規定するとおりに，ルートディレクトリの親ディレクトリは，ルートディレクトリとする。
いろいろなオペレーティングシステムでのファイル特性の使用法を次節で記述する。
UNIXで，隠しファイルを普通の隠しファイルでないものとして処理することを除けば，これらのビットは3.3.1.1.1の規定と同様に処理するものとする。
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;
}
a) ビット6及び7(Setuid & Setgid)
b) ビット8(Sticky)
c) ビット10(System)
a) ビット6及び7(Setuid & Setgid)
b) ビット8(Sticky)
c) ビット10(System)
a) ビット6, 7及び8(Setuid, Setgid, Sticky)
これらのビットは，これに相当するUNIXファイルシステムに相当するビットに配置する。
b) ビット10(System)
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[];
}
備考 ファイルエントリの全長は，一つの論理ブロック長を超えてはならない。
/* 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
セキュリティ情報を扱う許可条件の概念は，オペレーティングシステム間で完全には移植可能でない。この標準仕様書(TS)では，次に示す基本的な課題に言及することによって，許可条件ビットを処理する処理システム間で一貫性を保持する。
a) 利用者，グループ及びその他
一般に，利用者ID及びグループIDを利用可能にしないオペレーティングシステムでは，許可条件ビットを処理するとき，次に示すアルゴリズムを使用する。
b) デフォルト許可値(Default Permission Values)
次の表では，この標準仕様書(TS)で扱うオペレーティングシステムに関して，新しいファイルを作成するとき，オペレーティングシステムが利用可能な許可条件ビットに直接配置しない許可条件ビットに，どのようなデフォルト値を使用するのが望ましいかを記述している。
| 許可 | ファイル/ディレクトリ | 記述 | 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)
この標準仕様書(TS)で扱うオペレーティングシステムにおいて，許可条件ビットの処理法を記述する表3.2に従って，処理システムは許可条件ビットを処理する。この表は，オペレーティングシステムが利用可能な許可条件ビットに直接配置していない許可条件ビットに関連する項目を示す。
| 許可 | ファイル/ディレクトリ | 記述 | 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の処理システムではディレクトリのアクセス可能性を決定する際，読み出しビットの状態を無視してもよい。
備考 ファイル又はサブディレクトリを削除するには，ファイル又はサブディレクトリの削除許可条件ビットが設定されており，ファイル又はサブディレクトリを含むディレクトリには，書込み許可条件ビット及び実行許可条件ビットの両方が設定されていなければならない。
備考 いくつかのオペレーティングシステム(例えばMacintosh)に関しては，この値はInt32の最大値(231-1)より小さくする必要がある。Macintoshオペレーティングシステムでは，この値はMacintoshのディレクトリID又はファイルIDを表すために使用する。そのために，処理システムはInt32の最大値(231-1)より小さい値であることが望ましい。値1〜15は，Macintosh用に確保するものとする。
拡張属性は，実行処理のためにファイルエントリのこの欄に記録するのが望ましい。他の拡張属性は，拡張属性ICB欄で指示するICBに記録するのが望ましい。拡張属性の節では，この欄に記録するのが望ましい拡張属性について規定する。
長さの変更が可能ないくつかの長拡張属性(EAs)を扱うために，次に示す規則をEA空間に適用する。
備考 ファイルごとに，二つの拡張属性空間が存在してもよい。一方はファイルエントリ又は拡張ファイルエントリに埋め込まれ，他方は，ファイルエントリ又は拡張ファイルエントリ内の拡張属性ICB番地によってアクセスされる分離空間とする。各拡張属性空間が存在する場合は，独自の拡張属性ヘッダ記述子をもたなければならない。(次節を参照。)
struct ExtendedAttributedHeaderDescriptor{ /*ECMA 167 4/14.10.1*/
struct tag DescriptorTag;
Uint32 ImplementationAttributesLocation;
Uint32 ApplicationAttributesLocation;
}
struct AltematePermissionsAttribute{ /*ECMA 167 4/14.10.4*/
Uint32 AttributeType;
Uint8 AttributeSubtype;
byte Reserved[3];
Uint32 AttributeLength;
Uint16 OwnerIdentification;
Uint16 GroupIdentification;
Uint16 Permission;
}
この構造は記録してはならない。
struct FileTimeExtendedAttribute{ /*ECMA 167 4/14.10.5*/
Uint32 AttributeType;
Uint8 AttributeSubtype;
byte Reserved[3];
Uint32 AttributeLength;
Uint32 DataLength;
Uint32 FileTimeExistence;
byte FileTimes;
}
)
主ファイルエントリが拡張ファイルエントリではなく，ファイル日時拡張属性が存在しない場合，又はファイル作成日時を含まない場合，処理システムでは，ファイル作成日時を表すために，ファイルエントリの訂正日時欄を使用しなければならない。
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を処理システム用欄に記録するものとする。
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拡張属性を保存するものとする。また，この標準仕様書(TS)に規定するすべてのMacintosh拡張属性を作成し，利用可能にするものとする。
この拡張属性は，拡張属性空間で未使用な空間を示すために使用するものとする。この拡張属性は，処理システム用拡張属性として記録しなければならない。その処理システム用拡張属性の処理システム識別子は,
"*UDF FreeEASpace"に設定する。
この拡張属性の処理システム用領域は，表3.3に示す構成とする。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 2 | ヘッダチェックサム | Uint16 |
| 2 | IU_L-1 | 空きEA空間 | バイト |
この拡張属性は，拡張属性空間のすべてを再度書き込むことなく，処理システムが他の拡張属性を縮小又は拡大することを可能にする。空きEA空間の拡張属性は上書きしてもよく，上書きを必要とする処理システムがその空間を再利用してもよい。
この拡張属性は，DVD著作権管理情報を示すために使用するものとする。この拡張属性は，処理システム用拡張属性として記録しなければならない。その処理システム用拡張属性の処理システム識別子は,
"*UDF DVD CGMS Info"に設定する。
この拡張属性の処理システム用領域は，表3.4に示す構成とする。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 2 | ヘッダチェックサム | Uint16 |
| 2 | 1 | CGMS情報 | バイト |
| 3 | 1 | データ構造種別 | Uint8 |
| 4 | 4 | 保護システム情報 | バイト |
この拡張属性は，DVD著作権管理情報の記録を可能にする。このフォーマットの解釈は，DVDコンソーシアム(6.9.3を参照)が出版するDVD規定で定義するものとする。この拡張属性を利用可能にすることは，オプションとする。
OS/2は，制限のない個数の拡張属性を利用可能にする。これらの拡張属性は，3.3.8.2に定義するとおり，名前付きストリームとして記録するものとする。性能を高めるために，次に示す処理システム用拡張属性を作成する。
この拡張属性は，OS/2拡張属性ストリーム(3.3.8.2)情報の長さを規定する。この値は，ディレクトリ操作でOS/2に通知する必要があるため，効率上の理由から，ファイルエントリの拡張属性欄に記録するのが望ましい。この拡張属性は，処理システム識別子に
"*UDF OS/2 EALength"を設定する処理システム用拡張属性として記録しなければならない。
この拡張属性の処理システム用領域は，表3.5に示す構成とする。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 2 | ヘッダチェックサム | Uint16 |
| 2 | 4 | OS/2拡張属性長 | Uint32 |
OS/2拡張属性長欄に記録する値は，OS2EAストリームのファイルエントリの情報長欄に一致しなければならない。
Macintosh OSは，次に示す四つの拡張属性の利用を要求する。
この拡張属性は，Machintoshボリューム情報を含み，処理システム用識別子に
"*UDF Mac VolumeInfo"を設定する処理システム用拡張属性として記録しなければならない。
この拡張属性の処理システム用領域は，次に示す構成とする。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 2 | ヘッダチェックサム | Uint16 |
| 2 | 12 | 最後の更新日時 | timestamp |
| 14 | 12 | 最後のバックアップ日時 | timestamp |
| 26 | 32 | ボリュームファインダ情報 | Uint32 |
Macintoshボリューム情報の拡張属性は，ルートディレクトリのファイルエントリの拡張属性として記録するものとする。
この拡張属性は，関連ファイル又はディレクトリのMacintoshファインダ情報を含む。この情報は頻繁にアクセスするため，効率上の理由からファイルエントリの拡張属性欄に記録するのが望ましい。
Macintoshファインダ情報の拡張属性は，処理システム識別子に
"*UDF Mac FinderInfo"を設定する処理システム用拡張属性として記録しなければならない。
この拡張属性の処理システム用領域は，次に示す構成とする。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 2 | ヘッダチェックサム | Uint16 |
| 2 | 2 | 埋込み(=0) | Uint16 |
| 4 | 4 | 親ディレクトリID | Uint32 |
| 8 | 16 | ディレクトリ情報 | UDFDInfo |
| 24 | 16 | ディレクトリ拡張情報 | UDFDXInfo |
| 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"固有のボリューム及びページに対応する。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 2 | V | Int16 |
| 2 | 2 | H | Int16 |
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 2 | Top | Int16 |
| 2 | 2 | Left | Int16 |
| 4 | 2 | Bottom | Int16 |
| 6 | 2 | Right | Int16 |
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 8 | FrRect | UDFRect |
| 8 | 2 | FrFlags | Int16 |
| 10 | 4 | FrLocation | UDFPoint |
| 14 | 2 | FrView | Int16 |
| 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 |
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 4 | FdType | Uint32 |
| 4 | 4 | FdCreator | Uint32 |
| 8 | 2 | FdFlags | Uint16 |
| 10 | 4 | FdLocation | UDFPoint |
| 14 | 2 | FdFldr | Int16 |
| 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構造ではリトルエンディアンで記録する。
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拡張属性を保存しなければならない。この標準仕様書(TS)に規定するすべてのMacintosh拡張属性をも作成し，利用可能にしなければならない。
この拡張属性は，拡張属性空間でアプリケーション用拡張属性に確保された未使用な空間を示すために使用するものとする。この拡張属性は，アプリケーション識別子に
"*UDF FreeAppEASpace"を設定するアプリケーション用拡張属性として記録しなければならない。
この拡張属性のアプリケーション用領域は，次に示す構成とする。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 2 | ヘッダチェックサム | Uint16 |
| 2 | IU_L-1 | 空きEA空間 | バイト |
この拡張属性は，拡張属性空間のすべてを再度書き込むことなく，処理システムが他の拡張属性を縮小又は拡大することを可能にする。FreeAppEASpaceの拡張属性は上書きしてもよく，上書きを必要とする処理システムがその空間を再利用してもよい。
名前付きストリームはファイルの関連データを関連付ける機構を提供する。この機構は，概念的に拡張属性に類似している。しかし，名前付きストリームは, 拡張属性よりもはるかに優れている。名前付きストリームには, 長さの制限がない。各ストリームは独自の空間をもつため，拡張属性の共通空間よりもはるかに空間管理を行い易い。特定のストリームを見つけるのに，拡張属性の場合に必要であったデータ空間全体の検索は行わない。
名前付きストリームは, 主に利用者データを対象にする。例えば，データベースアプリケーションは，レコードをデフォルトストリーム又は主ストリームに記録してよく，索引を名前付きストリームに記録してよい。そこで利用者は, 多くのファイルではなくデータベース用の一つのファイルだけを見ることになり，アプリケーションは，多様なストリームをあたかも独立したファイルとして使用できる。
名前付きストリームは，拡張ファイルエントリによって識別する。拡張ファイルエントリは，関連付けられた名前付きストリームをもつファイルに必要となる。名前付きストリームをもたないファイルは，拡張ファイルエントリを使用するのが望ましい。ファイルは通常のファイルエントリを含んでもよい。通常のファイルエントリは，DVDビデオディスクの書込みなどの下位互換性が必要な場合に使われる。
ファイル集合記述子によって識別されるストリームディレクトリであるシステムストリームディレクトリがある。これらのストリームは，ファイルに関連するデータではなく，媒体全体に関連するデータを記述するために使用する。UDFは，システムストリームディレクトリによって識別される幾つかのシステムストリームを定義する。
名前付きストリームは，新しい処理システムにおいて，拡張属性ではなく，メタデータ及びアプリケーションデータを記録するのに使うことを推奨する。
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) すべてのシステムは, 名前付きストリームを実装していない実装システムにおいても, 主データストリームを利用可能にしなければならない。
名前付きストリームの集合は，ファイルシステム用にUDFによって規定する。UDF名前付きストリームの中には，ファイル集合記述子によって識別され，ファイル集合全体(システムストリームディレクトリ)に適用されるものもある。他のUDF名前付きストリームは, 個々のファイル又はディレクトリに属し，ストリームディレクトリによって識別子される。
UDF名前付きストリームはすべて，この標準仕様書(TS)で特記しない限り，ストリームディレクトリのファイル識別記述子においてセットされたメタデータビットをもつものとする。ファイルシステムの実装によって生成されないストリームはすべて，このビットをZEROに設定するものとする。
UDF名前付きストリームはすべて，ストリームを識別するICBにファイル種別5をもつものとする。
4文字の*UDFは，この標準仕様書(TS)におけるUDF定義のすべての名前付きストリームの最初の4文字とする。処理システムは，この標準仕様書(TS)で規定していない名前付きストリームに，*UDFで始まる識別子を使用してはならない。*UDFで始まる名前付きストリームのためのすべての識別子は，OSTAによる将来の定義のために確保される。
名前付きストリームの代わりに拡張属性を記録してよい。拡張属性は, 次の規則に従って変換される。
a) ストリームは, メタデータストリームとしてマーク付けされる。
b) 拡張属性のヘッダ及びヘッダチェックサムは, 記録されない。拡張属性が，ヘッダチェックサムと残りのデータとの間にパッドバイトを含んでいたら，これらも記録されない。ファイル又はディレクトリの拡張属性は，次のアルゴリズムによって，同じファイル又はディレクトリのストリームに変換できる。
この節は，UDF定義のシステムストリームの規定を含む。
| ストリーム名 | ストリーム位置 | メタデータフラグ |
|---|---|---|
| “*UDF Unique ID Mapping Data” | システムストリームディレクトリ(ファイルセット記述子) | 1 |
| “*UDF Non-Allocatable Space” | システムストリームディレクトリ(ファイルセット記述子) | 1 |
| “*UDF Power Cal Table” | システムストリームディレクトリ(ファイルセット記述子) | 1 |
| “*UDF Backup” | システムストリームディレクトリ(ファイルセット記述子) | 1 |
表3.16に列挙されたストリームは，メタデータフラグ集合を備えているので，処理システムは，プラットフォームのプラグインファイルシステムインタフェースを介してストリームの名前を通してはならない。
一意IDマッピングデータは，処理システムが，UDF一意IDに関連付けられたファイル/ディレクトリのICB階層に直接進むことを可能にし，又はUDF一意IDに関連付けられたファイル/ディレクトリを含むディレクトリのICB階層に進むことを可能にする。一意IDマッピングデータは，(ファイル集合記述子に関連付けられた)システムストリームディレクトリの名前付きストリームとして記録される。このストリームの名前は
"*UDF Unique ID Mapping Data"に設定するものとする。
ファイル識別記述子のファイル特性欄の中のメタデータビットは，プラットフォームのファイルシステムインタフェースのクライアントに，このファイルの存在を知らせないことが望ましいことを示すため，1に設定しなければならない。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 32 | 処理システム識別子 | 実体ID |
| 32 | 4 | フラグ | Uint32 |
| 36 | 4 | マッピングエントリカウント(=MEC) | Uint32 |
| 40 | 8 | 予備 | バイト(=#00) |
| 48 | 16*MEC | マッピングエントリ | IDマッピングエントリ |
処理システム識別子は, [2.1.5への相互参照]に記述されている。
フラグは, 次のとおりに規定される。
マッピングエントリカウントは，配列マッピングエントリの，エントリにおける大きさとする。
マッピングエントリは，UDF一意IDマッピングエントリ構造の配列とする。非ストリームの親でないファイル識別記述子ごとに，一つのマッピングエントリがある。ボリュームが一致していれば，常に配列は，UDF一意IDの昇順にソートされる。フラグで制限される場合を除いて，空白エントリは，配列のどの位置でも可能であり，エントリは，直前のエントリより一つ大きいUDF一意IDの値をもつ必要はない。空白エントリは, すべての欄でZEROの値をもつ。
ストリームの内容は，"UDF一意IDマッピングエントリ"の配列の前にヘッダ欄を含む"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からの区画参照番号とする。
JIS X 0607は，媒体の欠陥領域を記述したり，ファイルシステム以外の割付けのために使用できない領域を記述する機構を規定しない。割付け禁止空間ストリームは，ファイルシステムが使用できない空間を記述するための方法を提供する。割付け禁止空間ストリームは，欠陥管理をしない媒体システム(例えば，CD-RW)だけに記録されなければならない。
割付け禁止空間ストリームは, 初期化時に生成されなければならない。割付け禁止空間ストリームが示す空間も, すべて自由空間マップで割り付けられたとしてマーク付けされるものとする。割付け禁止空間ストリームは，ファイル集合記述子のシステムストリームディレクトリで名前付きストリームとして記録するものとする。ストリーム名は, 次のとおりとする。
"*UDF Non-Allocatable Space"
ストリームは, 属性メタデータ(ONEに設定されたファイル特性集合の4ビット)及びシステム(ONEに設定されたICBフラグ欄の10ビット)でマーク付けされるものとする。このストリームは，割り付けエクステントが識別するすべての割付け禁止セクタをもつものとする。割付けエクステントは，各エクステントが割り付けられるが記録されないことを示すものとする。このリストには，初期化時の欠陥セクタと初期化時に予備のため割り付けられる空間との両方が含まれるものとする。
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"
パワー較正表をサポートしない処理システムは，このストリームを消去してはならない。パワー較正表をサポート及び/又は使用する処理システムは，その処理システムがその使用によって，明らかにかつ特別に時代遅れにしたことも更新したこともなかった表からのレコードを消去したり修正してはならない。
ストリームは次のとおりに初期化するものとする。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 32 | 処理システム識別子 | 実体ID[UDF 2.1.5] |
| 32 | 4 | レコード数 | Uint32[1/7.1.5] |
| 56 | * | パワー較正表レコード | バイト |
処理システム識別子については, 2.1.5を参照されたい。
レコード数は, パワー較正表に含まれるレコード数を規定するものとする。
パワー較正表レコードは, このディスクに書込んだドライブのための一連のパワー較正表レコードとする。この表の長さは可変であるが，4バイトの倍数とする。未構造化欄のデータの記録は左揃えにし，右側は，#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バイト長の整数倍でなければならない。
このストリームの名前は
"*UDF Backup"に設定しなければならない。
このストリームは，次の内容をもつものとし，ICBに埋め込まなければならない。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 12 | バックアップ日時 | 日時スタンプ |
バックアップ日時は，このボリュームのバックアップが実行された最新の時間とする。
この節では次の非システムストリームを定義している。
| ストリーム名 | ストリーム位置 | メタデータフラグ |
|---|---|---|
| *UDF Macintosh Resource Fork | ファイル又はディレクトリ | 0 |
| *UDF OS/2 EA | ファイル又はディレクトリ | 0 |
| *UDF NT ACL | ファイル又はディレクトリ | 0 |
| *UDF UNIX ACL | ファイル又はディレクトリ | 0 |
資源フォークは明瞭なインタフェースで参照するため，UDF処理システムでは，このストリームに正式な名前を与えていない。交換のためには，名前は次のとおりに設定しなければならない。
"*UDF Macintosh Resource Fork"
ファイル識別記述子のファイル特性欄のメタデータビットは，プラットフォームファイルシステムインタフェースのクライアントに，このファイルの存在を知らせるのが望ましいことを示すため，0に設定するものとする。
OS/2で規定できる拡張属性はすべて，名前付きストリームとして記録するものとし，その名前は，次のとおりに設定しなければならない。
"*UDF OS/2 EA"
OS2EAストリームは，次に示すとおり，OS/2完全EA(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
一定のオペレーティングシステムでは，ファイルへのアクセスの制約を強化するためアクセス管理リスト(ACL)の概念をサポートしている。ACLの支援を促進するため，UDF2.0では，システムレベルの名前付きストリームの集合を規定している。この目的は，与えられたファイル対象に関連するACLを記録することとする。
UDFのACLは，3.3.5の規則に従って，名前付きストリームとして記録される。名前付きストリームACLの内容は不明瞭であり，この標準仕様書(TS)では規定しない。命名ACLの内容の解釈は，ACLが意図しているオペレーティングシステムに任されるものとする。次の名前は, ACLを識別するのに使われ，予約されなければならない。これらの名前はアプリケーション名前付きストリームに使用してはならない。
"*UDF NT ACL"この名前は，Windows NTオペレーティングシステムで，名前付きストリームACLを識別するものとする。
"*UDF UNIX ACL"この名前は，UNIXオペレーティングシステムで，名前付きストリームACLを識別するものとする。
JIS X 0607の第3部には，処理システムに依存して，利用者に提示しなければならないいろいろな識別子を含む。
これらの識別子は，CS0で記録され，利用者に表示可能にするために，ある翻訳方式を採らなければならないことがある。そのため，処理システムが前記の識別子について，OS固有の解釈を実行しなければならないとき，処理システムは4.1.2.1に記述するアルゴリズムを使用するものとする。
翻訳アルゴリズムのためのCのソースコードは，この標準仕様書(TS)の附属書に示す。
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;
}
UNIXでないオペレーティングシステム環境では，次に示す値のいずれかをこの欄の中にもつファイルに関するopen/close/read/write要求は，アクセス拒否エラーの状態とする。
ファイル種別値 - 0(Unknown), 6(ブロック装置), 7(文字装置), 9(FIFO)及び10(C_ISSOCK)
種別12(シンボリックリンク)のファイルに関するopen/close/read/write要求は，このシンボリックリンクが指し示しているファイル又はディレクトリにアクセスするものとする。
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[];
}
ほとんどのオペレーティングシステムは，正当なファイル識別子の特性に関するそれ自体の規定があるので，これは交換に伴う問題となる。そのため，すべての処理システムが，ファイル識別子翻訳の何らかの方式を実行しなければならないので，すべての処理システムが同一アルゴリズムを使用すれば，それは利用者にとって有益となる。
ファイル識別子翻訳の問題は，次の一つ以上に分類される。
次節は，この標準仕様書(TS)で扱う各特定オペレーティングシステムに対するファイル識別子の翻訳アルゴリズムを概説する。すべてのOSTA UDF適合処理システムは，このアルゴリズムを使用するものとする。このアルゴリズムは，不当なファイル識別子を読み出した場合だけに適用する。媒体中の元のファイル識別子名は，変更してはならない。このアルゴリズムは，オペレーティングシステムのファイル識別子制限に合致させるために，ファイル識別子の翻訳方式を実行する処理システムに適用するものとする。
すべてのOSTA UDF適合処理システムは，UDF翻訳アルゴリズムを利用しなければならないが，追加アルゴリズムを利用可にしてもよい。複数のアルゴリズムを利用可能にする場合，処理システムの利用者に，UDF翻訳アルゴリズムの選択方法を提供しなければならない。デフォルトの表示可能アルゴリズムは，UDFが定義するアルゴリズムであることを推奨する。
これらのアルゴリズムの主目的は，ファイルが属するディレクトリのすべてを調べずに，固有のオペレーティングシステムの制限に適合する一意のファイル名を作成することとする。
次に示すアルゴリズムのためのCのソースコードは，この標準仕様書(TS)の附属書に示してもよい。
備考 次のアルゴリズムの定義では，常に，d文字は引用符中に指定され，Unicodeの16進の数値が指定される。さらに，このアルゴリズムは，CS0の16進表示を参照する。これは，16進数で値を表すのにUnicodeの値#0030〜#0039及び#0041〜#0046を使用することに相当する。
次のアルゴリズムは，処理システムの利用者に名前の重複を報告する結果となることもある。その理由は，利用者に(ファイルの名前変更により)ディレクトリ中のどんなファイルへのアクセスも可能とする一方で，ディレクトリの内容への効率的なアクセスと論理ボリュームマウント及びファイルシステムドライバ処理システムにまたがって一貫した名前の翻訳とに関する必要性にある。
定義
ファイル識別子は，ファイル名及びファイル拡張子の二つの部分で構成するものとする。
文字"."(#002E)は，ファイルのファイル識別子に関する分離子とする。最後の"." (#002E)に続く文字が5文字以下の場合，それはファイル拡張子を構成するものとする。5文字を超える場合，ファイル拡張子は存在ししてはならない。ファイル拡張子に先行して現れ，最後の"." (#002E)を除いた文字は，ファイル名を構成するものとする。
備考 たとえOS/2，Macintosh及びUNIXが，ファイル拡張子の概念を形式的にもたないとしても，1文字から5文字の拡張子がその後に続く"." でもってファイルを終えることが，共通のファイル命名規則とする。そのため，次のアルゴリズムでは，ファイル拡張子は最大5文字までとしている。
MS-DOSオペレーティングシステム環境が，ファイルに関連するファイル識別子に制限を強いるため，上に挙げたオペレーティングシステム環境でファイル識別子を扱うために，次に示す方法を使用するものとする。
制限 ファイル識別子のファイル名要素は，8文字を超えてはならない。ファイル識別子のファイル拡張子要素は，3文字を超えてはならない。
備考 DOSを除く他のアルゴリズムはすべて，分離子‘#’(#0023)によってCRCに先行する。DOSファイル名の文字が制限されているため，CRCの分離子は使用されない。
OS/2オペレーティングシステム環境が，ファイルに関連するファイル識別子に制限を強いるため，前述のオペレーティングシステム環境でファイル識別子を扱うために，次に示す方法を使用するものとする。
ファイル拡張子がある場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する先頭の[254 - {新ファイル拡張子の長さ+ ("."用の)1} -(#CRC用の)5]個までの文字から成り，これに分離子"#"(#0023)が続き，元のCS0ﾌァイル識別子の16ビットCRCをCS0 の16進表示した4数字を続けて，さらに"."(#002E)及びこの処理のこの段階でのファイル拡張子を続けて構成するものとする。
ファイル拡張子がない場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する先頭の[254-(#CRC用の)5]個の文字から成る。これに分離子"#"(#0023)を続け，元のCS0ﾌァイル識別子の16ビットCRCをCS0 の16進表示した4数字を続けて構成する。
Macintoshオペレーティングシステム環境が，ファイルに関連するファイル識別子に制限を強いているため，前述のオペレーティングシステム環境でファイル識別子を扱うために，次に示す方法を使用するものとする。
ファイル拡張子がある場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する先頭の[31-{新ファイル拡張子の長さ+1("."用)}-5(#CRC用)]個の文字から成り，これに分離子"#"(#0023)が続き，元のCS0ﾌァイル識別子の16ビットCRCをCS0 の16進表示した4数字を続けて，さらに"."(#002E)及びこの処理のこの段階でのファイル拡張子を続けて構成するものとする。
ファイル拡張子がない場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する先頭の[31-5(#CRC用)]個の文字から成る。これに分離子"#"(#0023)を続け，元のCS0ﾌァイル識別子の16ビットCRCをCS0の16進表示した4数字を続けて構成するものとする。
Windows 95及びWindows NTオペレーティングシステム環境が，ファイルに関連するファイル識別子に制限を強いるため，前述のオペレーティングシステム環境でファイル識別子を扱うために，次に示す方法を使用するものとする。
ファイル拡張子がある場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する先頭の[MAXNameLength-{新ファイル拡張子の長さ+1("."用)}-5(#CRC用)]個の文字から成り，これに分離子"#"(#0023)が続き，元のCS0ﾌァイル識別子の16ビットCRCのCS0の16進表示した4数字を続けて，さらに"."(#002E)及びこの処理のこの段階でのファイル拡張子を続けて構成するものとする。
ファイル拡張子がない場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する 最初の[255-5(#CRC用)]個の文字から成るものとする。これに分離子"#"(#0023)を続け，元のCS0ﾌァイル識別子の16ビットCRCをCS0の16進表示した4数字を続けて構成する。
UNIXオペレーティングシステム環境による制約のため，ファイルに関連するファイル識別子に関して，前述のオペレーティングシステム環境でファイル識別子を扱うために，次の方法論を採用するものとする。
ファイル拡張子がある場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する先頭の[最大名前長-(新しいファイル拡張子長+1('.'用))-5(#CRC用)]数文字から成り，これに分離子'#'(#0023)を続け，元のCS0ファイル識別子の16ビットCRCのCS0の16進表示した4数字を続け，さらに'.'及びこの処理のこの段階でのファイル拡張子を続けて構成するものとする。
ファイル拡張子がない場合，新しいファイル識別子は，この処理のこの段階でファイル名を構成する，先頭(最大名前長-5(#CRC用))の数文字で構成するものとする。これに，分離子'#'(#0023)が続き，元のCS0ファイル識別子の16ビットのCRCをCS0の16進表示した4数字が続く。
次の表は，JIS X 0607に記述する記述子の長さに対するUDF制限を要約する。
| 記述子 | 長さ |
|---|---|
| 開始ボリューム記述子ポインタ | 512 |
| ボリューム記述子ポインタ | 512 |
| 処理システム用ボリューム記述子 | 512 |
| 区画記述子 | 512 |
| 論理ボリューム記述子 | 最大値なし |
| 未割付け空間記述子 | 最大値なし |
| 終端記述子 | 512 |
| 論理ボリューム保全記述子 | 最大値なし |
| ファイル集合記述子 | 512 |
| ファイル識別記述子 | 論理ブロック長 |
| 割付けエクステント記述子 | 24 |
| 間接エントリ | 52 |
| 終端エントリ | 36 |
| ファイルエントリ | 論理ブロック長 |
| 未割付け空間エントリ | 論理ブロック長 |
| 空間ビットマップ記述子 | 最大値なし |
| 区画保全エントリ | N/A |
この標準仕様書(TS)のはじめに定義する実体識別子の節を参照。
孤立空間が論理ボリューム中に存在してもよいが推奨はしない。それは，いくつかの論理ボリュームの修理機能によって再割り付けされる可能性があるためとする。孤立空間は，JIS X 0607で定義する処理システム用記述子以外のいずれの記述子で，直接又は間接に参照しない空間として定義する。
備考 処理システム用欄中だけに参照が存在する割付け済みのエクテントを孤立空間とみなす。
起動記述子の情報については，文献"OSTA Native Implementation Specification"を参照。
この標準仕様書(TS)の原規定に関する技術的質問は，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ウェブサイトを参照のこと。
| 実体識別子 | 記述 |
|---|---|
| “*OSTA UDF Compliant” | 論理ボリューム規定の内容，又はファイル集合の内容が，この標準仕様書(TS)で定義する適合範囲であることを示す。 |
| “*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” | 媒体で欠陥領域を扱う情報を含む。 |
| 実体識別子 | バイト値 |
|---|---|
| "*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 |
次に示す表は，実体識別子の識別子添字中のOSクラス欄及びOS識別子欄に対して現状許可する値を定義する。
OSクラス欄は，記述子を記録したオペレーティングシステムのクラスを識別する。この欄の有効な値を表6.3に示す。
| 値 | オペレーティングシステムクラス |
|---|---|
| 0 | 未定義 |
| 1 | DOS |
| 2 | OS/2 |
| 3 | Macintosh OS |
| 4 | UNIX |
| 5 | Windows 9x |
| 6 | Windows NT |
| 7-255 | 予備 |
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に連絡されたい。
/********************************************************************************** * 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); }
次に示す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は，上記のソースコードの自由使用の許可を与えている。
この節は，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階層を構成する方策とする。
次に示すサンプルソースコードの例は，この標準仕様書(TS)に記述するファイル識別子翻訳アルゴリズムを与えている。
次に示す基本アルゴリズムは，ボリューム記述子，ボリューム集合記述子，論理ボリュームID及びファイル集合IDのOS 固有の翻訳を扱うために利用してもよい。
/*************************************************************************
* 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);
}
}
/*************************************************************************
* 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
}
/*
* 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);
}
この附属書は，ユニバーサルディスクフォーマット(UDFS)の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だけを含むのが望ましい。
この節は，専用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乗とする。その結果，すべての除算は論理シフト演算で行ってよい。
備考 DVD Specification for Read-Only Discは，DVDコンソーシアムが開発した規定であり，媒体上に記録するDVD-Videoファイルの名前及びDVD-Videoディレクトリの名前を記述している。さらにDVD-Videoファイルの内容についても記述している。
これらすべての制約は，DVDプレーヤがアクセスする必要があるディレクトリ及びファイルだけに適用する。媒体中にはDVDプレーヤ向けではなく，これらの制限に適合しない，他のファイル及びディレクトリが存在してもよい。これらの他のファイル及びディレクトリを，DVDプレイヤは無視する。これにより，同一ディスク上に娯楽用の内容及びコンピュータ用の内容の両方をもつことができる。
この節は，DVDプレーヤが，UDFでフォーマットしたDVD-Videoディスクを読み出すために実行する基本的な手続きを記述する。
論理セクタ16から開始するものとするボリューム認識列中のJIS X 0607記述子を見つける。
開始位置の開始ボリューム記述子ポインタを見つけなければならない。二つの開始位置は，論理セクタ256及び論理セクタnに記録されるものとする。ここで，nはディスクの論理セクタに番号付けした最大数とする。
DVDプレーヤは，論理セクタ256だけを見ればよい。論理セクタnのコピーは冗長であり，欠陥対応のためにだけに必要とする。開始ボリューム記述子ポインタは，次の三項目を含む。
開始ボリューム記述子ポインタのバイト0〜3及び5にあるデータは，必要に応じてフォーマット検証に使用してもよい。バイト4のチェックサム及びバイト8〜11のCRCの検証は，実行すべき適切な追加検証とする。MVDS_Location及びMVDS_Lengthを，この構造から読み出す。
次の論理セクタを読み出す。
MVDS_Location から MVDS_Location+(MVDS_Length-1)/セクタ長
論理セクタ長は，DVD媒体では2048バイトとする。 この列が読み出せない場合，予備ボリューム記述子列を読み出すのが望ましい。
区画記述子は，値5のタグ識別子をもつ記述子とする。区画番号及び論理セクタ番号による区画位置が記録されるものとする。
この構造から，Partition_Location及びPartition_Lengthを得る。
論理ボリューム記述子は，値6のタグ識別子をもつ記述子とする。ファイル集合記述子の位置及び長さが論理ブロック番号で記録されるものとする。
この構造から，FSD_Location及びFSD_Lengthを得る。
ファイル集合記述子は，次に示す論理セクタ番号の論理セクタに存在する。
Partition_Location+FSD_Location から
Partition_Location+FSD_Location+(FSD_Length-1)/ブロック長
RootDir_Location及びRootDir_Lengthを，論理ブロック番号によりファイル集合記述子から読み出すものとする。
RootDir_Location及びRootDir_Lengthは，ファイルエントリの位置を定義する。このファイルエントリは，ルートディレクトリのデータ空間及び許可条件を記述する。
ルートディレクトリの位置及び長さを得る。
"VIDEO_TS"サブディレクトリを見つけるために，ルートディレクトリエクステント中のデータを解釈する。
VIDEO_TSファイル識別子記述子を見つける。その名前は，8ビットの圧縮UDFフォーマットとする。VIDEO_TSが，ディレクトリであることを検証する。
ファイル識別子記述子を読み出し，VIDEO_TSディレクトリを記述するファイルエントリの位置及び長さを得る。
前述の段階で見つけたファイルエントリは，VIDEO_TSディレクトリのデータ空間及び許可条件を含む。
VIDEO_TSディレクトリの位置及び長さを得る。
前述の段階で見つけたエクステントは，ファイル識別子記述子の集合を含む。このパスでは，エントリがファイルをポイント史VIDEO_TS.IFOという名前をもつことを検証する。
前述の段階で見つけたファイルエントリは，VIDEO_TS.IFOファイルのデータ空間及び許可条件を含む。
VIDEO_TS.IFOファイルの位置及び長さが返される。
必要ならば，他のファイルは，VIDEO_TS.IFOファイルと同じ方法で見つけることができる。
文献"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
CD媒体(CD-R及びCD-RW)は，その特徴により，特別な配慮を必要とする。CDは元々，書込み方法に影響を与える，再生専用アプリケーション用に設計された。次の指針は，交換を確実に行うために作られた。
各ファイル及びディレクトリは，1個の直接ICBで記述するものとする。そのICBは，書込み中のデータ不足を見込んで，ファイルデータの後で書込まれるのが望ましいが，これは，ファイルデータの論理ギャップを引き起こす。ICBは，後で書込むことができるが，このことは，ファイルデータのすべてのエクステントを正しく識別する。ICBは，データトラック，ファイルシステムトラック(もし存在すれば)，又は両方に書込まれるものとする。
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 マルチメディアコマンド)を参照。
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個の仮想区画を含むのが望ましい。
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拡張子を使用しなければならない。
CD-ROMドライブが読み取りを行えるように，セションは閉じられる。ディスク上の最後の完全セションは完全にJIS X 0607に従い，2個のAVDPを記録するものとする。これは，次のセションデータ表の末端に従って，データを書込むことで完成するものとする。次の例に示されてはいないが，データは複数のパケットに書込んでもよい。
| 数 | 記述 |
|---|---|
| 1 | 開始ボリューム記述子ポインタ |
| 255 | 処理システム仕様。利用者データ，ファイルシステム構造，リンク領域を含んでもよい。 |
| 1 | VAT ICB |
処理システム仕様データは，VAT及び，VAT ICBの反復コピーを含んでもよい。最後のセクタの位置を正確に報告しないドライブとの互換性が高まる。処理システムでは，セションデータの最後尾を記録するのに十分な空間が利用できることが確実にしなければならない。セションデータの最後尾を記録することにより，ボリュームはJIS X 0607に一致する。
CD-RW媒体は，任意の読み出し及びブロックの書込みができる。つまり，個々のセクタを読み取るとき，複数セクタを含むブロックで書込みが行われなければならない。CD-RWシステムでは，不良領域の予備は用意しない。書込み規則及び予備機構は定義されている。
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) ディスクは使用前に初期化するものとする。
初期化は，リードイン，利用者データ領域，リードアウトから成るものとする。これらの領域は，任意の順序で書込みをしてもよい。この物理的フォーマットには，検証パスが続いてもよい。検証パスの間に見つかる欠陥は，割付け禁止空間リストに列挙しなければならない(3.3.7.1.2を参照。)。最後にファイルシステムルート構造が記録されるものとする。これらの強制的なファイルシステム及びルート構造にはボリューム認識列，開始ボリューム記述子ポインタ，ボリューム記述子列，ファイルセット記述子，及びルートディレクトリが含まれる。
開始ボリューム記述子ポインタはセクタ256及びN-256に記録しなければならないが，この場合，Nは，番地付け可能な最後のセクタの物理番地とする。
予備の割付けは，初期化プロセスの間に行うものとする。予備割付けの長さは0でもよい。
空き空間記述子を，欠陥領域及びセクタ予備領域に割り付けられた空間を反映するように，記録しなければならない。
フォーマットは，媒体で利用可能なすべての空間を含んでよい。しかし，利用者が要求した場合，初期化時間を節約するため，部分集合を初期化してもよい。その，少量のフォーマットを，後に，完全に利用可能な空間に"成長"させてもよい。
媒体を部分的に初期化し，後に大きく成長させてもよい。この動作は次の要素から成る。
ホストでは欠陥管理動作を行うものとする。CDフォーマットは欠陥管理を含めないで定義されたので，現存の技術及びコンポーネントと互換性をもたせるには，ホストで欠陥を管理しなければならない。初期化時に不良セクタを表示し，オンラインで予備を割り当てるのが，欠陥管理の2段階とする。ホストは現在の媒体に表を保持するものとする。
CD-RW媒体は大きな書込み可能単位を必要とする。これは，各装置が，14KBオーバヘッドを受けるためとする。ファイルシステムは2KBの書込み可能単位を必要とする。書込みサイズの差は，ホストの読み出し−訂正−書込み動作で処理される。パケット全体が読み取られ，適切な部分が訂正され，パケット全体がCDに書込まれる。
パケットは，32セクタ境界に整列しなくてもよい。
ディスクは，厳密に1個のリードイン，プログラム領域，及びリードアウトで初期化するものとする。プログラム領域は，厳密に1個のトラックを含むものとする。区画は，パケット境界で開始するものとする。区画長はパケットサイズの整数倍とする。
最後のセションはUDFファイルシステムを含むものとする。事前のすべてのセションは，1個の読み出し専用区画に含まれるものとする。
いかなる制約も適用してはならない。
ボリューム認識列及び開始ボリューム記述子ポインタの位置は，ディスクの始まりに関連する位置であると，JIS X 0607で規定されている。ディスクの始まりは，VRS及びAVDPを見つける目的で，基本番地Sから決定するものとする。
'S'は，ボリュームの最後の既存のセション内に記録された，最初のデータトラックの，最初のデータセクタの物理番地とする。'S'は，複セションのJIS X 0606の記録で現在使われているもと同じ値とする。このセションの最初のトラックはデータトラックとする。
'N'はディスクに記録された最後のデータセクタの物理セクタ数とする。任意書込みモードを使用する場合，媒体は０又は１のオーディオセションで初期化し，その後に，1個のトラックを含む，書込み可能なデータセションを厳密に1個続けてもよい。他のセションの構成も可能だが，ここでは記述していない。1回に1個だけ書込み可能区画又はセションがあるものとし，このセションはディスクでは最後のセションとする。
複セションディスクを扱うために，次の記述をUDFに加える(JIS X 0607第2部参照)。
開始ボリューム記述子ポインタ(AVDP)は，S+256及びN-256の論理セクタ数に記録するものとする。セクタN-256のAVDPはセションを閉じる前に記録するものとする。セションを開放している間は，記録しなくてもよい。
UDFブリッジフォーマットにより，UDFは，別のファイルシステムを含んでいるディスクに加えることができる。UDFブリッジディスクは，最後のセションにUDFファイルシステムを含むものとする。最後のセションは，前述の"複セションと混合モード"に記述された規則に従うものとする。このディスクは，JIS X 0606，オーディオ，ベンター一意，又は，結合されたファイルシステムに基くセションを含んでもよい。UDFブリッジフォーマットにより，CD強化ディスクが作成できる。
新しい主ボリューム記述子列及び予備ボリューム記述子列は, 各追加セションに存在してもよく，前のVDSと異なってもよい。
CDの最後のセションが，有効なUDFファイルシステムを含まない場合，そのディスクはUDFディスクではない。最後のセションのUDF構造，UDF構造，及びそれらで参照されるデータだけが有効とする。
UDFセションは，他のセションのデータ又はメタデータを示すポインタ，UDFセション内だけにあるデータ又はメタデータを示すポインタ，又は両方のセションを結合した場合のデータ又はメタデータを示すポインタを含んでもよい。UDFブリッジディスクのいくつかの例を次に示す。
次の表は，媒体に記録できるUDFフォーマットに影響するUDF定義の変更がいつ行われたかを示す。各変更を示す文書変更通知(DCN)が表中に記入してある。変更UDF版数の欄には，変更を含むUDF規定の版数を示す。UDF読出し最小版数及びUDF書込み最小版数の欄は，2.2.6.4で記述する版数アクセス制御欄に関連する。
| 記述 | 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 |