図6.1 複セションUDFディスク
この標準情報(TR)は, 1997年2月にOSTA(Optical Storage Technology Association)から発行されたUniversal Disk Format Specification Revision 1.50を翻訳して, 技術的内容を変更することなく作成した標準情報(TR)(タイプII)である。
この標準情報(TR)は，JIS X 0607及びJIS X 0607 追補1の部分集合を規定する。データ交換を最大限にすること，並びにJIS X 0607を実施するためのコスト及び複雑性を最小限にすることを, その主な目的とする。
この課題を達成するために，規定範囲を定義する。規定範囲は，JIS X 0607の使用上の規則及び制限を定義する。ここで定義する規定範囲を，UDFの適用範囲とする。
この標準情報(TR)は，オペレーティングシステムごとにJIS X 0607の構造に関する次の課題に応える。
JIS X 0607の構造Xが与えられたとき，その構造Xの各欄について，指定されたオペレーティングシステムに関する次の問に回答する。
- a) その欄の読出しオペレーティングシステムが，その欄中のデータを利用可能である場合，そのオペレーティングシステムにおける何に対して，その欄は対応しなければならないか。
- b) その欄の読出しオペレーティングシステムが，その欄中のデータを制約付きで利用可能である場合，そのオペレーティングシステムにおいて，その欄をどのように解釈しなければならないか。
- c) その欄の読出しオペレーティングシステムが，その欄中のデータを利用可能でない場合，そのオペレーティングシステムにおいて，その欄をどのように解釈しなければならないか。
- d) その欄の書込みオペレーティングシステムが，その欄中のデータを利用可能である場合，そのオペレーティングシステムにおける何から，その欄は対応しなければならないか。
- e) その欄の書込みオペレーティングシステムが，その欄中のデータを利用可能でない場合，オペレーティングシステムにおいて，その欄をどのように解釈しなければならないか。
JIS X 0607の構造のいくつかに関しては，これらの課題への回答は自明であるため，その構造は，ここには含めない。
JIS X 0607を明確にするための補足として，各構造に関する付加情報を提供することがある。
この標準情報(TR)は，JIS X 0607を実装する作業を容易にする支援をする。
この標準情報(TR)は，JIS X 0607が規定する構造の扱いについての情報を与える。
この標準情報(TR)は，次に示す四つの基本的な節から成る。
この標準情報(TR)は，JIS X 0607で定義する構造の扱いに関する情報を提供し，次に示す分野をカバーしている。
各構造の欄がまず示され，次いで前述の分類に関して各欄の記述がある。各欄の記述情報で補足する。欄に関する意味が明白な場合には，構造の1個以上の欄を，記述しない場合がある。
用語遣い この標準情報(TR)では, "でなければならない(shall)"は必須の行為又は要件を示し, "してよい(may)"はオプションの行為又は要件を示し, "であることが望ましい(should)"は推奨するがオプションである行為又は要件を示す。
欄及び/又は構造に関連する特別な注釈は，"備考"と前置きして示す。
この標準情報(TR)は，JIS X 0607の第1部,第2部,第3部及び第4部への適合性を必要とする。この標準情報(TR)は，JIS X 0607の第5部への適合性はサポートしない。
備考 CD媒体の特性により, 区画はボリューム構造を含んでよい。これはJIS X 0607に違反する。追記形区画中にボリューム構造を含んでよいとするようにJIS X 0607の改訂が進められている。
ある処理システムがこの標準情報(TR)への適合性を主張するためには，その処理システムは，この標準情報(TR)で規定するすべての(必須の)要件を満たさなければならない。
適合性に関していくつかの要点を次に確認する。
JIS X 0606:1998, 情報交換用CD-ROMのボリューム構造及びファイル構造
備考 ISO 9660:1988, Volume and file structure of CD-ROM for Information Interchange が, この規格の前の版(1990年版)に対応している。
JIS S 8605-1993, コンパクトディスクディジタルオーディオシステム
備考1 IEC 908:1987, Compact disc digital audio systems が, この規格に一致している。IEC 908:1987は, 既に改訂されて, IEC 60908:1999として発行されている。
備考2 Red Book: Compact Disc Digital Audio System Description は, IEC 60908:1999に一致している。
JIS X 6281-1992, 120mm再生専用形光ディスク(CD-ROM)
備考1
ISO/IEC 10149:1995, Data interchange on read-only 120mm optical data disc (CD-ROM) の前の版(1989年版)が, この規格に一致している。
備考2 Yellow Book: Compact Disc Read Only Memory System Description が, この規格に対応している。
TR X 0025:2000, 追記形コンパクトディスク(CD-R)システム
備考 Orange Book, Recordable Compact Disc System, part-II が, この規定に一致している。
Orange Book, Recordable Compact Disc System, part-III
JIS X 0607-1996,
非逐次記録を用いる追記形及び書換形の情報交換用媒体のボリューム及びファイルの構造
備考 ISO/IEC 13346:1995, Volume and file structure of write-once and rewritable media
using non-sequential recording for information interchange が, この規格に一致している。
1.3.2.1 オーディオセッション (Audio session) 一つ又は複数のオーディオトラックを含み，データトラックを含まない。
1.3.2.2 オーディオトラック (Audio track) JIS S 8605が規定するオーディオセクタを含む設計がなされたトラック。
1.3.2.3 CD-R (CD-Recordable) 追記形CD。TR X 0025が規定する追記形コンパクトディスク。
1.3.2.4 CD-RW (CD-Rewritable) 書換形CD。Orange Book，part-IIIが規定する重ね書き可能なコンパクトディスク。
1.3.2.5 クリーンファイルシステム (Clean File System) この標準情報(TR)に適合する媒体のファイルシステム。
1.3.2.6 データトラック (Data track) JIS X 6281が規定するデータセクタを含む設計がなされたトラック。
1.3.2.7 ダーティファイルシステム (Dirty File System) クリーンファイルシステムではないファイルシステム。
1.3.2.8 固定パケット (Fixed Packet) 所定のトラックに含まれるパケットすべてが，トラック記述子ブロックに指定された長さをもつ，インクリメンタル記録方式。CDドライブに提示される番地は，TR X 0025及びOrange Book, part-IIIが規定する，番地付け方式の方式2に従って翻訳される。
1.3.2.9 ICB (Information Control Block) JIS X 0607における制御ノード。
1.3.2.10 論理ブロック番地 (Logical Block Address) JIS X 0607で定義された, 区画の開始位置からの相対的な番地。
1.3.2.11 媒体ブロック番地 (Media Block Address) 装置によって実行されるすべてのマッピングの前の媒体に書かれたままのセクタの番地。
1.3.2.12 パケット (Packet) 隣接するセクタの整数倍である記録可能単位のことで，利用者データセクタから構成される
1.3.2.13 パケットサイズ (Packet Size) パケットの利用者データセクタ数。
1.3.2.14 物理番地 (Physical Address) 装置インタフェース上で, 媒体をアクセスするときに用いられる番地。
1.3.2.15 ランダムアクセスファイルシステム (Random Access File System) 任意に書込みができる媒体のためのファイルシステムであり，追記形又は書換形。
1.3.2.16 順次ファイルシステム (Sequential File System) 順次に書き込まれた媒体のためのファイルシステム。例えばCD-R。セッション (Session) ボリュームのトラックは，Orange Book第2部が規定とおり，一つ又は複数のセッションに編成しなければならない。一つのセッションは，一つ又は複数のトラックの列とし，そのトラック数は連続した昇順の列を形成しなければならない。
1.3.2.17 セション (Session) TR X 0025で規定されるとおり, ボリューム中に含まれるトラックは一つ又は複数のセションに記録される。1セションは一つ又は連続した複数のトラックからなり, そのトラックの番号は, 連続した昇順となっている。
1.3.2.18 トラック (Track) ボリュームのセクタは，一つ又は複数のトラックに編成されなければならない。一つのトラックはセクタの列とし，そのセクタ数は，連続する昇順の列でなければならない。セクタは複数のトラックに属してはならない。 備考 トラック間に間隙がある場合もある。つまり，トラックの最後のセクタが，次のトラックの，最初のセクタの直後にくる必要はない。
1.3.2.19 UDF (Iniversal Disk Format) ユニバーサルディスクフォーマット
1.3.2.20 可変パケット (Variable Packet) 所定のトラックにおける各パケットが，ホストが決定した長さをもつ，増加記録方式。CDドライブに提示される番地は，TR X 0025及びOrange Book, part-IIIにおける方式1の番地付けで規定するとおりとする。
1.3.2.21 VAT ICB (Virtual Allocation Table ICB) VATを含むファイルを記述する，ファイルエントリICB。
1.3.2.22 仮想番地 (Virtual Address) 仮想割付け表エントリによって記述する番地。
1.3.2.23 VAT (Virtual Allocation Table) 仮想割付け表(VAT)は, それぞれの仮想番地に論理ブロック番地を提供する。仮想割付け表は, 逐次追記形の媒体で用いられる。
1.3.3.1 してよい (May) オプションの行為又は機能を示す。
1.3.3.2 オプションの (Optional) 実装しても，しなくてもよい機能を示す。実装する場合，その機能は規定どおりに実装しなければならない。
1.3.3.3 でなければならない (Shall) 必須であってこの標準情報(TR)に適合していることを主張するために実装しなければならない行為又は機能を示す。
1.3.3.4 望ましい (Should) オプションではあるが，その実装が強く推奨される行為又は機能を示す。
1.3.3.5 予備の (Reserved) 予備欄は，将来の使用のために確保され，ゼロに設定しなければならない。予備の値は, 将来の使用のために確保され，使用してはならない。
次の表2.1は，この標準情報(TR)が定義する基本制約及び基本要件のいくつかを要約している。これらの制約及び要件は，追加の制約及び要件とともに，この標準情報(TR)の以降の節で詳細に記述する。
| 項目 | 制約及び要件 |
|---|---|
| 論理セクタ長 | 特定のボリュームに関する論理セクタ長は，この特定のボリュームの物理セクタ長と同じとする。 |
| 論理ブロック長 | 論理ボリュームに関する論理ブロック長は，この特定の論理ボリュームが存在するボリューム又はボリューム集合の論理セクタ長に設定しなければならない。 |
| ボリューム集合 | 同一ボリューム集合中のすべての媒体は，同じ物理セクタ長をもつものとする。書換形/上書き可能形の媒体及び追記形の媒体は，同一ボリューム集合に混在してはならない｡ |
| ボリューム空間の最初の32Kバイト | ボリューム空間の最初の32768バイトは，JIS X 0607の構造の記録に使用してはならない。この領域は，未割付け空間記述子又は他のいかなるJIS X 0607の記述子も参照してはならない。この領域は，元のオペレーティングシステムでの自由使用に任されている。 |
| ボリューム認識列 | JIS X 0607の第2部の規定に従ってボリューム認識列を記録しなければならない。 |
| 日時表示 | すべての日時表示は，現地時で記録しなければならない。時間帯は，時間帯の概念をサポートするオペレーティングシステムに従って記録しなければならない。 |
| 実体識別子 | 実体識別子は，この標準情報(TR)に従って記録しなければならない。この規定で特記しない限り，実体識別子は，処理システムを一意に識別する値を含まなければならない。 |
| 記述子CRC | CRCは，空間ビットマップ記述子を除くすべての記述子に関して, 利用可能で，計算されなければならない。 |
| ファイル名の長さ | 最大255バイトとする。 |
| パス長 | 最大1023バイトとする。 |
| エクステント長 | 最大エクステント長は，[230-(論理ブロック長)]バイトとする。 |
| 基本ボリューム記述子 | ボリュームごとにただ一つの最新の基本ボリューム記述子を記録しなければならない。 |
| 開始ボリューム記述子ポインタ | ボリュームの最大セクタ番号をNとするとき，256, N-256又はNの3位置の少なくとも2箇所に記録しなければならない。 |
| 区画記述子 | 再生専用形，書換形, 上書き可能形及び追記形の区画アクセス種別を利用可能とする。次に示す一つの例外を除き，ボリュームごとにただ一つの種別1の最新の区画記述子を記録しなければならない。単一ボリュームで構成するボリューム集合において，一つの区画が再生専用のアクセス種別をもち，他区画が書換形又は上書き可能形のアクセス種別をもつ場合だけ，ボリュームは二つの最新の区画記述子とともに，二つの区画を含んでもよい。このボリュームの論理ボリュームは，両方の区画の内容で構成する。 |
| 論理ボリューム記述子 |
ボリューム集合ごとにただ一つの最新のボリューム記述子を記録する。 論理ボリューム識別子欄は，空にしてはならず，論理ボリュームの識別のための識別子を含むことが望ましい。特に，この規定に適合するボリュームを作成するソフトウェアは，この欄に固定の値又は無意味な値を設定してはならない。同一であることを意図する重複ディスクは，この欄が同一の値でもよい。この欄は，ジュークボックス中に複数の媒体が存在するときの，論理ボリュームの識別のために，特に重要となる。この名前は，典型的には，利用者に表示するものとする。 |
| 論理ボリューム保全記述子 | 記録しなければならない。 |
| 未割付け空間記述子 | 未割付け空間記述子を記録する。 |
| ファイル集合記述子 | 書換形又は上書き可能形の媒体中の論理ボリュームごとに一つだけのファイル集合記述子を記録する。追記形の媒体においては，この標準情報(TR)で定義する制約に従って複数のファイル集合記述子を記録してもよい。 |
| ICBタグ | 方策種別4又は方策種別4096だけを記録しなければならない｡ |
| ファイル識別記述子 | ファイル識別記述子の長さの合計は，一つの論理ブロック長を超えてはならない。 |
| ファイルエントリ | ファイルエントリの長さの合計は，一つの論理ブロック長を超えてはならない。 |
| 割付け記述子 | 短割付け記述子及び長割付け記述子だけを記録できる。 |
| 割付けエクステント記述子 | 一つの割付けエクステントの長さは，論理ブロック長を超えてはならない。 |
| 未割付け空間エントリ | 未割付け空間エントリの長さの合計は，論理ブロック長を超えてはならない。 |
| 空間ビットマップ記述子 | CRCは必要でない。 |
| 区画保全エントリ | 記録してはならない。 |
| ボリューム記述列エクステント | 主ボリューム記述子列エクステント及び予備ボリューム記述子列エクステントの両方とも，最小長16個の論理セクタで構成しなければならない。 |
| レコード構造 | JIS X 0607の第5部で定義するレコード構造ファイルは, 作成してはならない。 |
参考 この規定における第n部(n=1〜5)の表記は, JIS X 0607の第n部の規定内容への対応を示す。
この標準情報(TR)で定義する構造に関して，UDFで使用する文字集合は，CS0文字集合とする。OSTAのCS0文字集合は，表2.2に定義する。
OSTAのCS0は，#FEFF及びFFFEを除く, Unicode Standard Version 1.1が規定するd文字から成り，次に定義するOSTA圧縮Unicodeフォーマットで記録される。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 1 | 圧縮識別子 | Uint8 |
| 1 | ?? | 圧縮ビット列 | バイト |
圧縮識別子は，圧縮ビット列欄の圧縮に使用する圧縮アルゴリズムを識別する。表2.3に示すアルゴリズムが, 現在利用できる。
| 値 | 意味 |
|---|---|
| 0〜7 | 予備 |
| 8 | 圧縮ビット列中の1文字が8ビットであることを示す。 |
| 9〜15 | 予備 |
| 16 | 圧縮ビット列中の1文字が16ビットであることを示す。 |
| 17〜255 | 予備 |
圧縮識別子の値が8又は16のとき，その値は，圧縮ビット列欄で定義するd文字のビット数を規定しなければならない。圧縮ビット列欄中の圧縮識別子のビット数の各列は，OSTA圧縮Unicodeのd文字を表さなければならない。符号化される文字のビットは，最上位ビットから最下位ビットまで，圧縮ビット列に加える。符号化される文字のビットは，符号化先の着目しているバイトの最上位ビットの位置から圧縮ビット列に加えていかなければならない。
備考 この符号化によって，16の圧縮識別子で書込まれた文字は，ビッグエンディアンフォーマットで効率的に書き込まれる。
Uint16として解釈されるOSTA圧縮Unicodeのd文字の値は，Unicode 1.1の規定の対応するd文字の値を定義する。OSTA圧縮Unicode及びUnicode 1.1を変換するCのソースコードの例については，OSTA圧縮Unicodeに関する附属書を参照されたい。
Unicodeのバイト順マーク#FEFF及び#FFFEは，使用してはならない。
struct Charspec{
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"
この標準情報(TR)と同様に，JIS X 0607は，通常は相対バイト位置を0から定義する。JIS X 0607の7.2.12では，dstringは相対位置を1から定義している。これは混乱を招くことがあるので，次に相対位置を0から定義する場合を示す。
7.2.12 固定長文字欄
長さnのdstringは，d文字(1/7.2参照)を記録するnバイトの欄とする。文字の記録に使用するバイトの数は，バイトn-1にUint8(1/7.1.1参照)で記録する。ここで，nはこの欄の長さとする。文字は欄の先頭バイトから記録し，記録した文字の後からバイトn-2までのバイト位置に，すべて#00を設定する。
符号化するd文字の数が0の場合，dstringの長さは0とする。
備考 長さ0の列の場合を除いて，dstringの長さは圧縮識別子(2.1.1)を含む。長さ0の列は，dstring欄にすべて0を設定することによって記録する。
struct timestamp{ /*ISO 133461/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{ /* ISO 13346 1/7.4 */
Uint8 Flags;
char Identifier[23];
char IdentifierSuffix[8];
}
UDFは，実体識別子を次に示す三つの種別に分類する。
以降の節で，これらの異なる種別に基づいて実体識別子のフォーマット及び使用方法を示す。
この標準情報(TR)では，特記しない限り，この欄には，処理システムを一意に識別する識別子を設定しなければならない。この方法は，異なる処理システム間で交換する媒体中に記録した構造が，どの処理システムによるものかの識別を可能にする。
処理システムが，他の処理システムで書き込んだ媒体中に存在する構造を更新する場合，現状の処理システムは，現状の処理システムを一意に識別する値を識別子欄に設定しなければならない。
表2.4は，JIS X 0607及びこの標準情報(TR)で定義する実体識別子欄を要約したものであり，設定しなければならない値を示す。
| 記述子 | 欄 | 識別子値 | 添字種別 |
|---|---|---|---|
| 基本ボリューム記述子 | 処理システム識別子 | "*Developer ID" | 処理システム識別子添字 |
| 処理システム用 ボリューム記述子 | 処理システム識別子 | "*Developer ID" | 処理システム識別子添字 |
| 処理システム用 ボリューム記述子 | UDF識別子 | *UDF LV Info | UDF識別子添字 |
| 区画記述子 | 処理システム識別子 | "*Developer ID" | 処理システム識別子添字 |
| 論理ボリューム記述子 | 処理システム識別子 | "*Developer ID" | 処理システム識別子添字 |
| 論理ボリューム記述子 | 範囲識別子 | "*OSTA UDF Compliant" | 範囲識別子添字 |
| ファイル集合記述子 | 範囲識別子 | "*OSTA UDF Compliant" | 範囲識別子添字 |
| ファイル識別記述子 | 処理システム識別子 | "*Developer ID" | 処理システム識別子添字 (オプション) |
| ファイルエントリ | 処理システム識別子 | "*Developer ID" | 処理システム識別子添字 |
| UDF拡張属性 | UDF識別子 | 附属書参照 | UDF識別子添字 |
| 非UDF拡張属性 | 処理システム識別子 | "*Developer ID" | 処理システム識別子添字 |
| 装置仕様拡張属性 | 処理システム識別子 | "*Developer ID" | 処理システム識別子添字 |
| 論理ボリューム保全記述子 | 処理システム識別子 | "*Developer ID" | 処理システム識別子添字 |
| 区画保全エントリ | 処理システム識別子 | N/A | N/A |
| 仮想区画マップ | 区画種別識別子 | *UDF Virtual Partition | UDF識別子添字 |
| 予備区画マップ | 区画種別識別子 | *UDF Sparable Partition | UDF識別子添字 |
| 仮想割付け表 | 実体識別子 | *UDF Virtual Alloc Tbl | UDF識別子添字 |
| 予備表 | 予備識別子 | *UDF Sparing Table | UDF識別子添字 |
実体識別子の表の識別子値欄で示した"*Developer ID"は，現状の処理システムを一意に識別する実体識別子を示す。規定した値は，新しい記述子を作成するときに使用しなければならない。規定した値は，規定した実体識別子欄の適用範囲内で何かを更新するときに，存在する記述子にも使用しなければならない。
備考 "*Developer ID"のために選択された値は，処理システムに関する社名及び製品名を識別できるだけの情報を含むことが望ましい。例えば，DataOneというUDF製品をもつXYZという会社は，Developer IDとして"*XYZ Data One"を選択してよい。Developer IDの添字においても，DataOne製品の現在の版数を記録することを選択してよい。この情報は，異なる会社の複数の製品がメディアに記録していた場合，どの処理システムがメディアの一部に不適切な構造を書き込んだのかを決定する際，非常に助けになる。
実体識別子の表の添字種別欄は，相当する実体識別子で使用する添字のフォーマットを定義する。これらの異なる添字種別は，次の節で定義する。
備考 この標準情報(TR)(附属書6.1)で定義するすべての識別子は，UDF識別子としてOSTAが登録しなければならない。
識別子欄のフォーマットは，識別子の種別に依存する。
この標準情報(TR)(附属書6.1)で規定するOSTA範囲実体識別子に関しては，識別子添字欄を次に示す構成とする。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 2 | UDF版数 | Uint16(=#0150) |
| 2 | 1 | 範囲フラグ | Uint8 |
| 3 | 5 | 予備 | バイト(=#00) |
UDF版数欄は，この標準情報(TR)の版数1.50を示す値150を設定する。この欄は，この標準情報(TR)の改訂版に加えられた変更を，処理システムが検出することを可能にする。OSTA範囲識別子は，論理ボリューム記述子及びファイル集合記述子だけに使用する。範囲フラグ欄は，次に示すビットフラグを定義する。
| RBP | 意味 |
|---|---|
| 0 | ハード書込み保護 |
| 1 | ソフト書込み保護 |
| 2〜7 | 予備 |
ソフト書込み保護フラグは，利用者が設定可能なフラグであり，このフラグが存在する記述子の適用範囲で，ボリューム構造又はファイルシステム構造が書込み保護されていることを示す。ソフト書込み保護フラグの値がONEの場合，利用者の書込み保護を示さなければならない。このフラグは，利用者が設定及び解除してもよい。ハード書込み保護フラグは，処理システムが設定可能なフラグであり，このフラグが存在する記述子の適用範囲で永久的な書込み保護を示さなければならない。ハード書込み保護フラグの値がONEの場合，永久的な書込み保護を示さなければならない。このフラグは，一度設定した場合解除してはならない。ハード書込み保護フラグは，ソフト書込み保護フラグに優先する。
このフラグは，論理ボリューム記述子及びファイル集合記述子だけで用いられる。論理ボリューム記述子中のフラグは，ファイル集合記述子中のフラグに優先する。
UDF(附属書6.1)で定義する処理システム用実体識別子に対しては，識別子添字欄は，次にに示す構成とする。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 2 | UDF版数 | Uint16(=#0150) |
| 2 | 1 | オペレーティングシステムクラス | Uint8 |
| 3 | 1 | オペレーティングシステム識別子 | Uint8 |
| 4 | 4 | 予備 | バイト(=#00) |
オペレーティングシステムクラス及びオペレーティングシステム識別子欄の内容は，オペレーティングシステム識別子に関する附属書に記述する。
UDFで定義しない実体識別子を使用する処理システムに関して，識別子添字欄は，表2.8に示す構成とする。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 1 | オペレーティングシステムクラス | Uint8 |
| 1 | 1 | オペレーティングシステム識別子 | Uint8 |
| 2 | 6 | 処理システム用領域 | バイト |
備考 オペレーティングシステムクラス欄及びオペレーティングシステム識別子欄の意図した使用並びに重要性を理解することが重要になる。これらの欄の主な目的は，UDFボリューム中で問題を検出したときに，誤りを取り除く支援をすることとする。この欄は，利用者に提供可能な有効な情報も提供する。これらの二つの欄を正しく設定した場合，処理システムに次の情報を提供する。
struct tag{ /* ISO 13346 3/7.2 */
Uint16 TagIdentifier;
Uint16 DescriptorVersion;
Uint8 TagChecksum;
byte Reserved;
Uint16 TagSerialNumber;
Uint16 DescriptorCRC;
Uint16 DescriptorCRCLength;
Uint32 TagLocation;
}
タグ通し番号は，ボリュームの再初期化時には，以前に記録した値と異なる値を設定しなければならない。タグ通し番号=((基本ボリューム記述子のタグ通し番号)+1)であることを推奨する。
CRCは，各記述子で利用可能であり，計算されなければならない。この欄の値は，(記述子の大きさ)−(記述子タグの長さ)を設定しなければならない。記述子を読み出すときは，CRCを検証するのが望ましい。
struct PrimaryVolumeDescriptor{/* ISO 13346 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{ /* ISO 133463/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{ /* ISO 13346 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"に指定しなければならない。
実体識別子の節で記述したとおり，実体識別子の識別子添字欄には，論理ボリュームの内容が互換性をもつこの標準情報(TR)の版数を含む。この欄の適切な扱いに関する詳細情報は，2.1.5を参照のこと。
備考 実体識別子の識別子添字欄は，ソフト書込み保護フラグ及びハード書込み保護フラグを含む。2.1.4.3を参照のこと。
この欄の適切な扱いに関する詳細情報は，実体識別子の節を参照のこと。
この欄の値は，論理ボリューム保全記述子のために必要となる。書換形/上書き可能形媒体に関しては，最小値8Kバイトを設定しなければならない。
備考 追記形媒体に対しては，この欄は，十分な長さのエクステントを設定するのが望ましい。論理ボリューム保全記述子は，最新論理ボリューム記述子と同一のボリュームに存在しなければならないため，論理ボリューム保全記述子が存在する追記形媒体が一杯になった場合は，ボリューム集合に新しいボリュームを追加しなければならない。
交換の目的として，区画マップは，この標準情報(TR)(2.2.8及び2.2.9)に記述されているとおり, 種別2を除き，区画マップ種別1に限定しなければならない。
struct UnallocatedSpaceDesc{ /* ISO 13346 3/10.8 */
struct tag DescriptorTag;
Uint32 VolumeDescriptorSequenceNumber;
Uint32 NumberofAllocationDescriptors;
exted_ad AllocationDescriptors[??];
}
使用可能なボリューム空間がない場合でも，この記述子を記録しなければならない。
struct LogicalVolumeIntegrityDesc{ /* ISO 13346 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のオプション値は使用してはならない。
論理ボリューム保全記述子の処理システム用領域は，表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{
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は，ファイル種別0のファイルエントリICBによって識別しなければならない。このICBは，記録された最後の有効データセクタとする。エラー修復計画はファイル種別0をもつICBを見つけること及び表の最後の実体識別子の内容を調べることで，最後の有効なVATを見つけることができる。
このファイルは，小さいときは，記述するICBに埋め込むことができる。大きくなると，ICBに先行するセクタに記録できる。セクタは，隣接する必要はないが，必要に応じて表の新しい部分にだけ書込みができる。これによって，多くのディレクトリをもつディスクでも，僅かな増加分の更新が可能になる。それぞれのセクタは512ディレクトリまでのエントリをもつことができる。
VATが小さいとき(ディスク上の少数ディレクトリ)，VATは，埋め込みVATで新しいファイルICBを書込むことにより更新される。VATが大きくなりすぎてICBに合わなくなると，VATで一つのセクタを書込み，ICBでほかのセクタを書込むことが必要になる。この点を越えると，VATのために複数のセクタが必要になる。しかし，複数のエクステントが利用可能になるため，VATの更新は，すべてのVATを示すポインタでICBを更新し書込む必要のあるセクタだけを，書込むだけでよい。
仮想割付け表は，特定の情報を求める要求を，適切な論理位置に導き直すのに使う。この表による遠回しな方法は，直接的な上書き能力の体裁を与える。例えば，ルートディレクトリを記述するセクタは仮想セクタ1として参照できる。仮想セクタは，仮想区画マップエントリによって識別する区画に含まれる。ディスクを更新する過程でルートディレクトリが変わるかもしれない。変わる場合，ルートディレクトリを記述する新しいセクタが書込まれ，論理ブロック番地は，仮想セクタ1に対応する論理ブロック番地として記録される。仮想セクタ1を参照するものは，たとえ，新しい論理ブロック番地に存在していても，現存するうちで最新の仮想セクタ１を示すため，変わる必要はない。
仮想番地付けの使用によって，要求された構造が効果的な上書きを行うことが可能になる。この構造は，参照するすべてのポインタが，仮想番地だけでできるとき，書換え可能になる。書換え構造が書き込まれると，仮想の参照は変わる必要がなくなる。VATへの適切なエントリは，対応する仮想番地の新しい論理ブロック番地を反映するように変えられ，その後あらゆる仮想の参照は新しい構造を示す。ディレクトリICBのとおり，更新が必要なすべての構造は，仮想番地で参照しなければならない。各構造が更新されると，VAT ICB内の対応するエントリが更新されるものとする。
VATは，Uint32エントリの連続としてファイルに記録するものとする。各エントリは，VATが位置する物理区画にセクタでオフセットにならなければならない。最初のエントリは，仮想区画セクタ0であり，2番目のエントリは仮想区画セクタ1とし，以降同様とする。Uint32エントリの後ろには実体識別子及び事前のVAT ICBの位置を示すUint32エントリが続く。
事前のVAT ICBの入力により，前の状態のようなファイルシステムを一覧できる。この欄が#FFFFFFFFである場合，それらのICBは指定されない。
| オフセット | 名前 | 内容 |
|---|---|---|
| 0 | 仮想セクタ0のLBA | Uint32 |
| 4 | 仮想セクタ1のLBA | Uint32 |
| 4 | 仮想セクタ2のLBA | Uint32 |
| ... | ... | Uint32 |
| 2048 | 仮想セクタ512のLBA | Uint32 |
| ... | ... | Uint32 |
| N*4 | 実体識別子 | EntityID |
| N*4+32 | VAT ICB前位置 | Uint32 |
#FFFFFFFFのエントリは，仮想セクタが現在使用されていないことを示している。LBN指定は区画マップエントリで識別される区画に位置する。表のエントリの数は，ICBのVATファイルサイズから決定できる。
エントリ数(N)=(FileSize-36)/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{ /* ISO 13346 4/7.2 */
Uint16 TagIdentifier;
Uint16 DescriptorVersion;
Uint8 TagChecksum;
byte Reserved;
Uint16 TagSerialNumber;
Uint16 DescriptorCRC;
Uint16 DescriptorCRCLength;
Uint32 TagLocation;
}
タグ通し番号は，ボリュームの再初期化時には，以前に記録した値と異なる値を設定しなければならない。この欄の意図する使用方法は，障害回復とする。第4部のすべての記述子のタグ通し番号は，関連するファイル集合記述子に使用した通し番号と同一であるのが望ましい。
特記しない限り，CRCは，各記述子で利用可能であり，計算されなければならない。この欄の値は，(記述子の大きさ)-(記述子タグの長さ) に設定するものとする。記述子を読み出すときは，CRCを検証するのが望ましい。
struct FileSetDescriptor{ /* ISO 13346 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;
byte Reserved[48];
}
書換形/上書き可能形媒体中には，一つだけファイル集合記述子を記録しなければならない。追記形媒体中には，複数のファイル集合記述子を記録してもよい。
複数のファイル集合に関するUDF規定を，次に示す。
追記形媒体のファイル集合中では，すべてのファイル及びディレクトリをICB方策種別4で記録する場合，そのファイル集合記述子の範囲識別子にはハード書込み保護を設定しなければならない。
追記形媒体中の複数のファイル集合の意図する目的は，媒体中に複数のアーカイブをサポートする機能を利用可能にすることとする。例えば，一つのファイル集合は，特定の時点で作成した情報集合のバックアップを表現する。
後続のファイル集合は，その後作成した同一情報集合の他のバックアップとして表現する。
処理システムは，規定する現状の交換水準に関連する制限を実施する。
"*OSTA UDF Compliant"に設定しなければならない。
実体識別子の節で記述したとおり，実体識別子の識別子添字欄には，論理ボリュームの内容が互換性をもつ本規定の版数を含む。この欄の適切な扱いに関する詳細情報は，実体識別子の節を参照のこと。
備考 実体識別子の識別子添字欄は，ソフト書込み保護フラグ及びハード書込み保護フラグを含む。
struct PartitionHeaderDescriptor{{ /* ISO 13346 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{ /* ISO 13346 4/14.4 */
struct tag DescriptorTag;
Uint16 FileVersionNumber;
Uint8 FileCharacteristics;
Uint8 LengthofFileIdentifier;
struct long_ad ICB;
Uint16 LengthofImplementationUse;
byte ImplementationUse[??];
char FileIdentifier[??];
byte Padding[??];
}
ファイル識別記述子は，一つの論理ブロックの長さに制限しなければならない。
備考 この欄の適切な扱いに関する詳細情報は，実体識別子の節を参照のこと。
この欄は，特定のファイル識別記述子を最後に作成又は更新した処理システムを識別することを処理システムに許可する。
struct icbtag{ /* ISO 13346 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{ /* ISO 13346 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[??];
}
備考 ファイルエントリの全総長は，一つの論理ブロック長を超えてはならない。
実体識別子の節を参照のこと。
ファイル集合のルートディレクトリに関して，この値は0を指定するものとする。
論理ボリューム中のすべてのファイル及びディレクトリに関して，この値が維持され一意であることが要求される。これは，拡張属性空間で定義されたファイルエントリ記述子を含む。拡張属性空間のファイルエントリは, 添付されるファイルと同じ一意IDをもたなければならない。
備考 一意IDの値1〜15は, Macintoshの実装用に予約する必要がある。
struct UnallocatedSpaceEntry{ /* ISO 13346 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{ /* ISO 13346 4/14.11 */
struct Tag DescriptorTag;
Uint32 NumberOfBits;
Uint32 NumberOfBytes;
byte Bitmap[??];
}
空間ビットマップ記述子に関する記述子タグの記述子CRC欄の計算及び保守は，オプションとする。CRCをメンテナンスできない場合，記述子CRC欄及び記述子CRC長欄の両方を0に設定する。
struct PartitionIntegrityEntry{ /* ISO 13346 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でなければならない。
struct long_ad{ /* ISO 13346 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{ /* ISO 13346 4/14.5 */
struct tag DescriptorTag;
Uint32 PreviousAllocationExtentLocation;
Uint32 LengthOfAllocationDescriptors;
}
備考 割付け記述子エクステントは，最大長1論理ブロックとする。
struct PathComponent{ /* ISO 13346 4/14.16.1 */
Uint8 ComponentType;
Uint8 LengthofComponentIdentifier;
Uint16 ComponentFileVersionNumber;
char ComponentIdentifier[];
}
JIS X 0607は，ファイルシステム以外の割付けのために使用不可能な領域又は媒体上の欠陥領域を記述する機構を提供しない。割付け禁止空間リストが, ファイルシステムによって使用不可能な空間を記述する方法を提供する。割付け禁止空間リストは，欠陥管理を行わない媒体システム(例えばCD-RW)だけに記録されるものとする。
割付け禁止空間リストは，フォーマット時に生成されなければならない。割付け禁止空間リストが示す全空間もまた，空き空間マップに割り付けられるものしてマーク付けされなければならない。割付け禁止空間リストは，ルートディレクトリのファイルとして記録されなければならない。"Non-Allocatable Space"(#4E,#6F,#6E,#2D,#41,#6C,#6C,#6F,#61,#74,#61,#62,#6C,#65,#20,#70,#61,#63,#65)というファイル名を使うものとする。このファイルは，Hidden(１に設定されたファイル特性の0ビット)及びSystem(１に設定されたICBフラグ欄の10ビット)の属性をもつとしてマーク付けされなければならない。名前は，任意の決められたワード長で記録してよい。このファイルの情報長はzeroとする。このファイルは，割付けエクステントで識別されるすべての割付け禁止セクタをもたなければならない。割付けエクステントは，各エクステントは割付けられるが，記録されないことを示す。このリストは，フォーマット時に見つかる欠陥セクタ，及びフォーマット時に予備として割り付けられる空間を含むものとする。
レコード構造ファイルは，作成してはならない。これらが媒体中に存在し，処理システムが利用可能でない場合は，内容を解釈しないバイト列として扱うものとする。
struct timestamp{ /*ISO 13346 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{ /*ISO 13346 4/14.15*/
Uint64 UniqeID,
bytes reserved[24]
}
この欄は，次の段階で使用するのが望ましい，一意IDの値を含む。
備考 Macintoshシステムとの互換性のために，実装は, この値をInt32の最大値(231-1)より小さく保つことが望ましい。
struct FileIdentifierDescriptor{ /*ISO 13346 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の第4部8.6で規定するとおり，ルートディレクトリの親ディレクトリは，ルートディレクトリとする。
いろいろなオペレーティングシステムでのファイル特性の使用法を次節で記述する。
UNIXで，隠しファイルを普通の隠しファイルでないものとして処理することを除けば，これらのビットは3.3.1.1.1の規定と同様に処理するものとする。
struct icbtag{ /*ISO 13346 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{ /*ISO 13346 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
セキュリティ情報を扱う許可条件の概念は，オペレーティングシステム間で完全には移植可能でない。この標準情報(TR)では，次に示す基本的な課題に言及することによって，許可条件ビットを処理する処理システム間で一貫性を保持する。
a) 利用者，グループ及びその他
一般に，利用者ID及びグループIDを利用可能にしないオペレーティングシステムでは，許可条件ビットを処理するとき，次に示すアルゴリズムを使用する。
b) 許可条件処理(Processing Permisstions)
この標準情報(TR)で扱うオペレーティングシステムにおいて，許可条件ビットの処理法を記述する表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の処理システムではディレクトリのアクセス可能性を決定する際，読み出しビットの状態を無視してもよい。
備考 ファイル又はサブディレクトリを削除するには，ファイル又はサブディレクトリの削除許可条件ビットが設定されており，ファイル又はサブディレクトリを含むディレクトリには，書込み許可条件ビット及び実行許可条件ビットの両方が設定されていなければならない。
c) デフォルト許可値(Default Permission Values)次の表では，この標準情報(TR)で扱うオペレーティングシステムに関して，新しいファイルを作成するとき，オペレーティングシステムが利用可能な許可条件ビットに直接配置しない許可条件ビットに，どのようなデフォルト値を使用するのが望ましいかを記述している。
| 許可 | ファイル/ディレクトリ | 記述 | 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では，ファイル又はディレクトリに書込みの表示が出たら(書込み許可条件設定)，ファイルは削除可能と考えられ，削除許可条件ビットを設定するのが望ましい。ファイルが再生専用の場合，削除許可条件ビットを設定するのは望ましくない。これは，ファイル作成とファイルの属性変更にも適用する。
備考 いくつかのオペレーティングシステム(例えばMacintosh)に関しては，この値はInt32の最大値(231-1)より小さくする必要がある。Macintoshオペレーティングシステムでは，この値はMacintoshのディレクトリID又はファイルIDを表すために使用する。そのために，処理システムはInt32の最大値(231-1)より小さい値であることが望ましい。値1〜15は，Macintosh用に確保するものとする。
拡張属性は，実行処理のためにファイルエントリのこの欄に記録するのが望ましい。他の拡張属性は，拡張属性ICB欄で指示するICBに記録するのが望ましい。拡張属性の節では，この欄に記録するのが望ましい拡張属性について規定する。
長さの変更が可能ないくつかの長拡張属性(EAs)を扱うために，次に示す規則をEA空間に適用する。
struct ExtendedAttributedHeaderDescriptor{ /*ISO 13346 4/14.10.1*/
struct tag DescriptorTag;
Uint32 ImplementationAttributesLocation;
Uint32 ApplicationAttributesLocation;
}
前述の処理システム拡張位置欄及び応用プログラム属性位置欄に関連する属性が存在しない場合，この欄の値は，拡張属性空間の後のバイトを示すものとする。
struct AltematePermissionsAttribute{ /*ISO 13346 4/14.10.4*/
Uint32 AttributeType;
Uint8 AttributeSubtype;
byte Reserved[3];
Uint32 AttributeLength;
Uint16 OwnerIdentification;
Uint16 GroupIdentification;
Uint16 Permission;
}
この構造は記録してはならない。
struct FileTimeExtendedAttribute{ /*ISO 13346 4/14.10.5*/
Uint32 AttributeType;
Uint8 AttributeSubtype;
byte Reserved[3];
Uint32 AttributeLength;
Uint32 DataLength;
Uint32 FileTimeExistence;
byte FileTimes;
}
)
この欄は，ファイル作成日時が記録されたことだけを示すために設定するものとする。
この構造を記録する必要はない。
ファイル日時拡張属性が存在しない場合，Macintosh処理システムは，このファイル作成日時を表すためにファイルエントリの変更日時欄を使用するものとする。
この構造を記録する必要はない。
struct DeviceSpecificationExtendedAttribute{ /*ISO 13346 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{ /*ISO 13346 4/14.10.8 */
Uint32 AttributeType;
Uint8 AttributeSubtype;
byte Reserved[3];
Uint32 AttributeLength;
Uint32 ImplementationUseLength; /* (=IU_L) */
struct EntityID ImplementationIdentifier;
byte ImplementationUse[IU_L];
}
属性長欄(Attribute Length)は，全体の拡張属性の長さを指定する。処理システム用拡張属性の使用を定義する可変長の拡張属性に関して，属性長欄には，処理システム用(Implementation Use)欄の最後及び処理システム用拡張属性の最後との間に埋め込み空間を残すのに，十分な大きさを指定するのが望ましい。
次の節は，オペレーティングシステム固有の拡張属性を記録するために，いろいろなオペレーティングシステムで処理システム用拡張属性を使用する方法を記述する。
次の節に定義する構造は，ヘッダチェックサム欄を含む。この欄は，処理システム用拡張属性ヘッダの16ビットチェックサムを表す。 属性種別から処理システム識別子までの欄を，チェックサムで保護するデータとして表す。ヘッダチェックサム欄は，拡張属性空間の障害回復の支援として使う。ヘッダチェックサムのためのCのソースコードを附属書に示してもよい。
備考 すべての適合する処理システムでは，媒体中の既存の拡張属性を保存するものとする。処理システムは，動作中のオペレーティングシステムに関する拡張属性を作成し，利用可能にするものとする。例えば，Macintosh処理システムでは，媒体中に存在するOS/2拡張属性を保存するものとする。また，この標準情報(TR)に規定するすべてのMacintosh拡張属性を作成し，利用可能にするものとする。
この拡張属性は，拡張属性空間で未使用な空間を示すために使用するものとする。この拡張属性は，処理システム用拡張属性として記録しなければならない。その処理システム用拡張属性の処理システム識別子は,
"*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は，制限のない個数の拡張属性を利用可能にする。これらの拡張属性は，次に示す二つの処理システム用拡張属性の使用により利用可能とする。
この拡張属性は，OS/2で定義可能なすべての拡張属性を含み，処理システム識別子に
"*UDF OS/2 EA"を設定する処理システム用拡張属性として記録するものとする。
この拡張属性の処理システム用領域は，表3.5に示す構成とする。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 2 | ヘッダチェックサム | Uint16 |
| 2 | IU_L-2 | OS/2拡張属性 | FEA |
OS2拡張属性欄は，表3.6に示すOS/2の全拡張属性(Full EAs:FEA)の表を含む。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 1 | フラグ | Uint8 |
| 1 | 1 | 名前の長さ(=L_N) | Uint8 |
| 2 | 2 | 値の長さ(=L_V) | Uint16 |
| 4 | L_N | 名前 | bytes |
| 4+L_N | L_V | 値 | bytes |
全拡張属性 ( FEA ) の完全な記述については，次に示すIBMの文献を参照のこと。
"Installable File System for OS/2 Version 2.0"
OS/2 File Systems Department，PSPC Boca Raton, Florida，Feburary 17, 1992
この拡張属性は，OS/2拡張属性情報の長さを規定する。この値は，ディレクトリ操作でOS/2に通知する必要があるため，効率上の理由から，ファイルエントリの拡張属性欄に記録するのが望ましい。この拡張属性は，処理システム識別子に
"*UDF OS/2 EALength"を設定する処理システム用拡張属性として記録しなければならない。
この拡張属性の処理システム用領域は，表3.7に示す構成とする。
| 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構造ではリトルエンディアンで記録する。
この拡張属性は，規定する一意IDのファイルエントリを調査するために使用する表を含む。この表は，処理システム識別子に
"*UDF Mac UniqueIDtable"を設定する処理システム用拡張属性として記録するものとする。
この拡張属性の処理システム用領域は，表3.17〜表3.19に示す構成とする。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 2 | ヘッダチェックサム | Uint16 |
| 2 | 2 | 埋込み (=0) | Uint16 |
| 4 | 4 | 一意IDマップ数 (=N_DID) | Uint32 |
| 8 | N_DID x 8 | 一意IDマップ | UniqueIDMap |
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 8 | ファイルのエントリ位置 | small ad |
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 2 | エクステント長 | Uint16 |
| 2 | 6 | エクステント位置 | lb_addr (4/7.1) |
この一意ID表は，規定するMacintoshディレクトリID又はファイルID (一意ID)に関して，これに相当するファイル エントリを調査するために使用する。例えば，MacintoshディレクトリID又はファイルID がiの場合，これに相当 するファイルエントリ位置は，一意ID表中の（i−2）の一意IDマップにある。一意IDが0から始まるのに対して， MacintoshディレクトリID又はファイルIDは2で始まるため，一意IDは，相当するディレクトリID又はファイルID から2を減算した値となる。Macintoshのルートディレクトリは，常に値2のディレクトリIDであるので，このルート ファイルエントリの一意IDは，値0である。
ファイルエントリ位置のエクステント長欄の値が0の場合，これに相当する一意IDは未使用になる。
Macintosh一意ID表の拡張属性は，ルートディレクトリの拡張属性として記録するものとする。
Macintosh一意ID表は，Macintoshを利用可能にする処理システムだけが作成及び更新を行う。Macintosh一意ID表を 利用可能にしない処理システムが論理ボリュームを更新した時，論理ボリュームは，次に示す食い違いを生じる。
Macintoshは，ファイル名を参照しないで，媒体中のファイルに直接位置づけをするのに一意IDを使用する。 これは，Macintoshでない処理システムが，最初にファイルを作成したときだけに行われる。したがって ，Macintoshを利用可能にしない処理システムが論理ボリュームに追加した新たなファイルは，常にファイル名 による参照が最初に行われ，一意IDによる参照は最初には行われない。ファイル名によるファイルへの最初の アクセス時に，Macintosh用の処理システムは，そのファイルの一意IDがMacintosh一意ID表にないことを検出し， その表を正しい状態に更新することが可能である。
二つめの問題は，解決が少し困難である。この問題は，Macintosh用の処理システムが，媒体中のファイルへの参照 を，一意IDにより与えられた時に発生する。Macintosh用の処理システムは，一意IDが参照するファイルが存在する ことを確認する必要がある。次の手順を実施できる。
これらの二つの確認によっても捕らえることができない唯一の例は，Macintoshでないシステムがファイルを削除し， ファイルエントリに関連する論理ブロックが，新たなファイルに再割付けされ，新たなファイルはそのブロックを， 割付け済みで未記録のエクステントとして使用している場合である。
この拡張属性は，関連ファイルに対してMacintoshのリソースフォークデータを含む。リソースフォークデータは，処理システム識別子欄に
"*UDF Mac ResourceFork"を設定する処理システム用拡張属性として記録するものとする。 この拡張属性の処理システム用領域は，表3.20 に示す構成とする。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 2 | ヘッダチェックサム | Uint16 |
| 2 | IU_L-2 | リソースフォークデータ | bytes |
Macintoshリソースフォークの拡張属性は，論理ボリューム中のリソースフォークが1バイト以上のすべての ファイルに拡張属性として記録するものとする。
Macintoshリソースフォークの拡張属性を参照するMacintoshファインダ情報の二つの欄は，次のとおりに定義する。
struct ApplicationUseExtendedAttribute{ /*ISO 13346 4/14.10.9 */
Uint32 AttributeType; /* 65536 */
Uint8 AttributeSubtype;
byte Reserved[3];
Uint32 AttributeLength;
Uint32 ApplicationUseLength; /* (=AU_L) */
struct EntityID ApplicationIdentifier;
byte ApplicationUse[IU_L];
}
属性長欄(Attribute Length)は，全体の拡張属性の長さを指定する。アプリケーション用拡張属性の使用を定義する可変長の拡張属性に対して，属性長欄には，アプリケーション用(Application Use)欄の最後及びアプリケーション用拡張属性の最後との間に埋め込み空間を残すのに，十分な大きさを指定するのが望ましい。
次の節に定義する構造は，ヘッダチェックサム欄を含む。この欄は，アプリケーション用拡張属性ヘッダの16ビットチェックサムを表す。 属性種別からアプリケーション識別子までの欄を，チェックサムで保護するデータとして表す。ヘッダチェックサム欄は，拡張属性空間の障害回復の支援として使う。ヘッダチェックサムのためのCのソースコードを附属書に示してもよい。
備考 すべての適合する処理システムでは，媒体中の既存の拡張属性を保存しなければならない。処理システムは，動作中のオペレーティングシステムに対する拡張属性を作成し，利用可能にしなければならない。例えば，Macintosh処理システムでは，媒体中に存在するOS/2拡張属性を保存しなければならない。この標準情報(TR)に規定するすべてのMacintosh拡張属性をも作成し，利用可能にしなければならない。
この拡張属性は，拡張属性空間でアプリケーション用拡張属性に確保された未使用な空間を示すために使用するものとする。この拡張属性は，アプリケーション識別子に
"*UDF FreeAppEASpace"を設定するアプリケーション用拡張属性として記録しなければならない。
この拡張属性のアプリケーション用領域は，次に示す構成とする。
| RBP | 長さ | 名前 | 内容 |
|---|---|---|---|
| 0 | 2 | ヘッダチェックサム | Uint16 |
| 2 | IU_L-1 | 空きEA空間 | バイト |
この拡張属性は，拡張属性空間のすべてを再度書き込むことなく，処理システムが他の拡張属性を縮小又は拡大することを可能にする。FreeAppEASpaceの拡張属性は上書きしてもよく，上書きを必要とする処理システムがその空間を再利用してもよい。
JIS X 0607の第3部には，処理システムに依存して，利用者に提示しなければならないいろいろな識別子を含む。
これらの識別子は，CS0で記録され，利用者に表示可能にするために，ある翻訳方式を採らなければならないことがある。そのため，処理システムが前記の識別子について，OS固有の解釈を実行しなければならないとき，処理システムは4.1.2.1に記述するアルゴリズムを使用するものとする。
翻訳アルゴリズムのためのCのソースコードは，この標準情報(TR)の附属書に示す。
Struct icbtag { /* ISO 133464/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{ /* ISO 133464/14.4 */
struct tag DescriptorTag;
Uint16 FileVersionNumber;
Uint8 FileCharacteristics;
Uint8 LengthofFileIdentifier;
struct long_ad ICB;
Uint16 LengthofImplementationUse;
byte ImplementationUse[??];
char FileIdentifier[??];
byte Padding[??];
}
ほとんどのオペレーティングシステムは，正当なファイル識別子の特性に関するそれ自体の規定があるので，これは交換に伴う問題となる。そのため，すべての処理システムが，ファイル識別子翻訳の何らかの方式を実行しなければならないので，すべての処理システムが同一アルゴリズムを使用すれば，それは利用者にとって有益となる。
ファイル識別子翻訳の問題は，次の一つ以上に分類される。
次節は，この標準情報(TR)で扱う各特定オペレーティングシステムに対するファイル識別子の翻訳アルゴリズムを概説する。すべてのOSTA UDF適合処理システムは，このアルゴリズムを使用するものとする。このアルゴリズムは，不当なファイル識別子を読み出した場合だけに適用する。媒体中の元のファイル識別子名は，変更してはならない。このアルゴリズムは，オペレーティングシステムのファイル識別子制限に合致させるために，ファイル識別子の翻訳方式を実行する処理システムに適用するものとする。
すべてのOSTA UDF適合処理システムは，UDF翻訳アルゴリズムを利用しなければならないが，追加アルゴリズムを利用可にしてもよい。複数のアルゴリズムを利用可能にする場合，処理システムの利用者に，UDF翻訳アルゴリズムの選択方法を提供しなければならない。デフォルトの表示可能アルゴリズムは，UDFが定義するアルゴリズムであることを推奨する。
これらのアルゴリズムの主目的は，ファイルが属するディレクトリのすべてを調べずに，固有のオペレーティングシステムの制限に適合する一意のファイル名を作成することとする。
次に示すアルゴリズムのためのCのソースコードは，この標準情報(TR)の附属書に示してもよい。
備考 次のアルゴリズムの定義では，常に，d文字は引用符中に指定され，Unicodeの16進の数値が指定される。さらに，このアルゴリズムは，CS0の16進表示を参照する。これは，16進数で値を表すのにUnicodeの値#0030〜#0039及び#0041〜#0046を使用することに相当する。
次のアルゴリズムは，処理システムの利用者に名前の重複を報告する結果となることもある。その理由は，利用者に(ファイルの名前変更により)ディレクトリ中のどんなファイルへのアクセスも可能とする一方で，ディレクトリの内容への効率的なアクセスと論理ボリュームマウント及びファイルシステムドライバ処理システムにまたがって一貫した名前の翻訳とに関する必要性にある。
定義
ファイル識別子は，ファイル名及びファイル拡張子の二つの部分で構成するものとする。
文字"."(#002E)は，ファイルのファイル識別子に関する分離子とする。最後の"." (#002E)に続く文字が5文字以下の場合，それはファイル拡張子を構成するものとする。5文字を超える場合，ファイル拡張子は存在ししてはならない。ファイル拡張子に先行して現れ，最後の"." (#002E)を除いた文字は，ファイル名を構成するものとする。
備考 たとえOS/2，Macintosh及びUNIXが，ファイル拡張子の概念を形式的にもたないとしても，1文字から5文字の拡張子がその後に続く"." でもってファイルを終えることが，共通のファイル命名規則とする。そのため，次のアルゴリズムでは，ファイル拡張子は最大5文字までとしている。
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 |
この標準情報(TR)のはじめに定義する実体識別子の節を参照。
孤立空間が論理ボリューム中に存在してもよいが推奨はしない。それは，いくつかの論理ボリュームの修理機能によって再割り付けされる可能性があるためとする。孤立空間は，JIS X 0607で定義する処理システム用記述子以外のいずれの記述子で，直接又は間接に参照しない空間として定義する。
備考 処理システム用欄中だけに参照が存在する割付け済みのエクテントを孤立空間とみなす。
起動記述子の情報については，文献"OSTA Native Implementation Specification"を参照。
この標準情報(TR)の原規定に関する技術的質問は，e-mailでinfo@osta.org.のOSTA Technical Committeeまで送られたい。また技術的質問は，1-805-962-1542でOSTA Technical Committeeの受付けへファクスしてもよい。
OSTAへの連絡は，次に示す住所宛でも可能とする。
Technical Committee Chairman OSTA 311 East Carrillo Street Santa Barbara, CA 93101 (805)963-3853
追加の情報については，www.osta.org のOSTAウェブサイトを参照のこと。
| 実体識別子 | 記述 |
|---|---|
| “*OSTA UDF Compliant” | 論理ボリューム規定の内容，又はファイル集合の内容が，この標準情報(TR)で定義する適合範囲であることを示す。 |
| “*UDF LV Info” | 付加的な論理ボリューム識別情報を含む。 |
| “*UDF FreeEASpace” | 処理システム用拡張属性空間中の未使用の空き空間を含む。 |
| “*UDF FreeAppEASpace” | アプリケーション用拡張属性空間中に未使用の空き空間を含む。 |
| “*UDF DVD CGMS Info” | DVD 著作権管理情報を含む。 |
| “*UDF OS/2 EA” | OS/2拡張属性情報を含む。 |
| “*UDF OS/2 EALength” | OS/2拡張属性長を含む。 |
| “*UDF Mac Volume Info” | Macintosh ボリューム情報を含む。 |
| “*UDF Mac FinderInfo” | Macintosh ファインダ情報を含む。 |
| “*UDF Mac UniqueIDTable” | 1個の一意IDと1個のファイルエントリとの対応に使用するMacintoshの一意ID表を含む。 |
| “*UDF Mac ResourceFork” | 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 EA" | #2A,#55,#44,#46,#41,#20,#45,#41 |
| "*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 Mac UniqueIDTable" | #2A,#55,#44,#46,#20,#4D,#61,#63,#20,#55,#6E,#69,#71,#75,#65,#49,#44,#54,#61, #62,#6C,#65 |
| "*UDF Mac ResourceFork" | #2A,#55,#44,#46,#20,#4D,#61,#63,#20,#52,#65,#73,#6F,#75,#72,#63,#65,#46,#6F, #72,#6B |
| "*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に連絡されたい。 現在，Windows95，WindowsNT及びNetWareはすべてこの標準情報(TR)で利用可能にしているわけではないが，OSTAはこれらのオペレーティングシステムでの作業を開始している。
/********************************************************************************** * 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;
}
#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階層を構成する方策とする。
次に示すサンプルソースコードの例は，この標準情報(TR)に記述するファイル識別子翻訳アルゴリズムを与えている。
次に示す基本アルゴリズムは，ボリューム記述子，ボリューム集合記述子，論理ボリューム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. */
byte *fidName, /* (Input) Bytes as read from media */
int fidNameLen) /* (Input) Number of bytes in fidName. */
{
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 = cksum(fidfName, fidNameLen);
/* 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 cksum(unsigned char *s, 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. */
byte *fidName, /* (Input) Bytes as read from media */
int fidNameLen) /* (Input) Number of bytes in fidName. */
{
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 = cksum(fidName, fidNameLen);
/* 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);
}
この附属書は，ユニバーサルディスクフォーマットの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は元々，書込み方法に影響を与える，再生専用アプリケーション用に設計された。次の指針は，交換を確実に行うために作られた。
VATは，未完成媒体の場合は，読み出しトラック情報(READ TRACK INFORMATION)を，又，完成媒体の場合は，読み出しTOC(READ TOC)又は，読み出しCD記録容量(READ CD RECORDED CAPACITY)を使用して位置を決めてもよい。X3T10-1048D(SCSI-3 マルチメディアコマンド)を参照。
各ファイル及びディレクトリは，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) ディスクは使用前に初期化するものとする。
初期化は，リードイン，利用者データ領域，リードアウトから成るものとする。これらの領域は，任意の順序で書込みをしてもよい。この物理的フォーマットには，検証パスが続いてもよい。検証パスの間に見つかる欠陥は，割付け禁止空間リストに列挙しなければならない(2.3.13を参照。)。最後にファイルシステムルート構造が記録されるものとする。これらの強制的なファイルシステム及びルート構造にはボリューム認識列，開始ボリューム記述子ポインタ，ボリューム記述子列，ファイルセット記述子，及びルートディレクトリが含まれる。
開始ボリューム記述子ポインタはセクタ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強化ディスクが作成できる。
UDFセションは，他のセションのデータを示すポインタ，UDFセション内だけにあるデータを示すポインタ，又は両方のセションを結合した場合のデータ又はメタデータを示すポインタを含んでもよい。UDFブリッジディスクのいくつかの例を次に示す。
次の表は，媒体に記録できるUDFフォーマットに影響するUDF定義の変更がいつ行われたかを示す。各変更を示す文書変更通知(DCN)が表中に記入してある。変更UDF版数の欄には，変更を含むUDF規定の版数を示す。UDF読出し最小版数及びUDF書込み最小版数の欄は，DCN 2-015で記述する版数アクセス制御欄に関連する。
| 記述 | 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.50 | 1.50 |
| CD媒体の推薦 | 2-031 | 1.50 | 1.50 | 1.50 |