標準情報(TR)  TR X 0035:2000


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

Universal Disk Format (UDF) 2.00



序文

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


1. 一般

1.0 適用範囲

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

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

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

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

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

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

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


1.1 構成

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

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

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

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

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

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


1.2 適合性

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

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

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


1.3 参照

1.3.1 引用規定

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

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

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

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

Orange Book, Recordable Compact Disc System, part-III

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

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

1.3.2 定義

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.3.3 用語遣い

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

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

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

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

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


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

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

表2.1 基本制約及び基本要件
項目制約及び要件
論理セクタ長 特定のボリュームに関する論理セクタ長は,この特定のボリュームの物理セクタ長と同じとする。
論理ブロック長 論理ボリュームに関する論理ブロック長は,この特定の論理ボリュームが存在するボリューム又はボリューム集合の論理セクタ長に設定しなければならない。
ボリューム集合 同一ボリューム集合中のすべての媒体は,同じ物理セクタ長をもつものとする。書換形/上書き可能形の媒体及び追記形の媒体は,同一ボリューム集合に混在してはならない。
ボリューム空間の最初の32Kバイト ボリューム空間の最初の32768バイトは,JIS X 0607の構造の記録に使用してはならない。この領域は,未割付け空間記述子又は他のいかなるJIS X 0607の記述子も参照してはならない。この領域は,元のオペレーティングシステムでの自由使用に任されている。
ボリューム認識列 JIS X 0607の第2部の規定に従ってボリューム認識列を記録しなければならない。
日時表示 すべての日時表示は,現地時で記録しなければならない。時間帯は,時間帯の概念をサポートするオペレーティングシステムに従って記録しなければならない。
実体識別子 実体識別子は,この標準情報(TR)に従って記録しなければならない。この規定で特記しない限り,実体識別子は,処理システムを一意に識別する値を含まなければならない。
記述子CRC CRCは,空間ビットマップ記述子を除くすべての記述子に関して, 利用可能で,計算されなければならない。
ファイル名の長さ 最大255バイトとする。
パス長 最大1023バイトとする。
エクステント長 最大エクステント長は,[230-(論理ブロック長)]バイトとする。仮想区画における最大エクステント長は論理ブロックサイズとする。
基本ボリューム記述子 ボリュームごとにただ一つの最新の基本ボリューム記述子を記録しなければならない。
開始ボリューム記述子ポインタ ボリュームの最大セクタ番号をNとするとき,256, N-256又はNの3位置の少なくとも2箇所に記録しなければならない。
区画記述子 再生専用形,書換形/上書き可能形及び追記形の区画アクセス種別を利用可能とする。次に示す一つの例外を除き,ボリュームごとにただ一つの種別1の最新の区画記述子を記録しなければならない。単一ボリュームで構成するボリューム集合において,一つの区画が再生専用のアクセス種別をもち,他区画が書換形/上書き可能形のアクセス種別をもつ場合だけ,ボリュームは二つの最新の区画記述子とともに,二つの区画を含んでもよい。このボリュームの論理ボリュームは,両方の区画の内容で構成する。
論理ボリューム記述子

ボリューム集合ごとにただ一つの最新のボリューム記述子を記録する。

論理ボリューム識別子欄は,空にしてはならず,論理ボリュームの識別のための識別子を含むことが望ましい。特に,この規定に適合するボリュームを作成するソフトウェアは,この欄に固定の値又は無意味な値を設定してはならない。同一であることを意図する重複ディスクは,この欄が同一の値でもよい。この欄は,ジュークボックス中に複数の媒体が存在するときの,論理ボリュームの識別のために,特に重要となる。この名前は,典型的には,利用者に表示するものとする。

論理ボリューム保全記述子 記録しなければならない。LVIDのエクステントは,エクステント長で終了してもよい。
未割付け空間記述子 ボリュームごとに一つだけの最新の未割付け空間記述子を記録する。
ファイル集合記述子 書換形/上書き可能形の媒体中の論理ボリュームごとに一つだけのファイル集合記述子を記録する。追記形の媒体においては,この標準情報(TR)で定義する制約に従って複数のファイル集合記述子を記録してもよい。ファイル集合記述子のファイル集合識別子欄は,利用者に対して論理ボリュームを識別するために,別名として使用できる名前を使用してもよい。詳細は,2.3.2.7を参照。FSDエクステントは,エクステント長で終了してもよい。
ICBタグ 方策種別4又は方策種別4096だけを記録しなければならない。
ファイル識別記述子 ファイル識別記述子の長さの合計は,一つの論理ブロック長を超えてはならない。
ファイルエントリ ファイルエントリの長さの合計は,一つの論理ブロック長を超えてはならない。
割付け記述子 短割付け記述子及び長割付け記述子だけを記録できる。
割付けエクステント記述子 一つの割付けエクステントの長さは,論理ブロック長を超えてはならない。
未割付け空間エントリ 未割付け空間エントリの長さの合計は,論理ブロック長を超えてはならない。
空間ビットマップ記述子 CRCは必要でない。
区画保全エントリ 記録してはならない。
ボリューム記述列エクステント 主ボリューム記述子列エクステント及び予備ボリューム記述子列エクステントの両方とも,最小長16個の論理セクタで構成しなければならない。VDSエクステントはエクステント長で終了してもよい。
レコード構造 JIS X 0607の第5部で定義するレコード構造ファイルは, 作成してはならない。


2.1 第1部 一般

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

2.1.1 文字集合

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

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

表2.2 OSTA圧縮Unicodeフォーマット
RBP長さ名前内容
01圧縮識別子Uint8
1??圧縮ビット列バイト


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

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

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

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

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

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

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

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

2.1.2 OSTA CS0文字集合

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

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

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

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

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

"OSTA Compressed Unicode"

2.1.3 Dストリング(dstring)

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

7.2.12 固定長文字欄

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

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

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

2.1.4 日時表示(Timestamp)

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

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

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

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

2.1.5 実体識別子(Entity Identifier)

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

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

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

2.1.5.1 フラグ(Uint18 Flags)

2.1.5.2 識別子(char Identifier)

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

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

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

表2.4 実体識別子
記述子識別子値添字種別
基本ボリューム記述子 処理システム識別子 "*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識別子添字


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

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

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

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

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

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

2.1.5.3 識別子添字(IdentifierSuffix)

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

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

表2.5 範囲識別子添字欄フォーマット
RBP長さ名前内容
02UDF版数Uint16(=#0200)
21範囲フラグUint8
35予備バイト(=#00)

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

表2.6 範囲フラグ
RBP意味
0ハード書込み保護
1ソフト書込み保護
2〜7予備

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

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

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

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

表2.7 UDF識別子添字
RBP長さ名前内容
02UDF版数Uint16(=#0200)
21オペレーティングシステムクラスUint8
31オペレーティングシステム識別子Uint8
44予備バイト(=#00)

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

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

表2.8 処理システム識別子添字
RBP長さ名前内容
01オペレーティングシステムクラスUint8
11オペレーティングシステム識別子Uint8
26処理システム用領域バイト

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


2.2 第3部 ボリューム構造

2.2.1 記述子タグ(Descriptor Tag)

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

2.2.1.1 タグ通し番号(Uint16 TagSerialNumber)

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

2.2.1.2 記述子CRC長(Uint16 DescriptorCRCLength)

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

2.2.1.3 タグの位置(Uint32 TagLocation)

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

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

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

2.2.2.1 交換水準(Uint16 InterchangeLevel)

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

2.2.2.2 最大交換水準(Uint16 MaximumInterchangeLevel)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.4.3 範囲識別子(struct EntityID DomainIdentifier)

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

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

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

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

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

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

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

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

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

2.2.4.7 区画マップ(byte PartitionMaps)

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

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

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

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

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

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

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

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

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

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

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

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

2.2.6.3 サイズ表(Uint32 SizeTable)

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

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

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

表2.9 処理システム用フォーマット
RBP長さ名前内容
032処理システム識別子EntityID
324ファイル数Uint32
364ディレクトリ数Uint32
402UDF読出し最小版数Uint16
422UDF書込み最小版数Uint16
442UDF書込み最大版数Uint16
46??処理システム用バイト

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.8 仮想区画マップ

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

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

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

表2.10 仮想区画に関する種別2区画マップの配置
RBP長さ名前内容
01区画マップ種別Uint8=2
11区画マップ長Uint8=64
22予備#00バイト
432区画種別識別子EntityID
362ボリューム列数Uint16
382区画数Uint16
4024予備#00バイト

2.2.9 予備区画マップ

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

表2.11 予備区画に関する種別2区画マップの配置
RBP長さ名前内容
01区画マップ種別Uint8=2
11区画マップ長Uint8=64
22予備#00バイト
432区画種別識別子EntityID
362ボリューム列番号Uint16
382区画番号Uint16
402パケット長Uint16=32
421予備表数(N_ST)Uint8
431予備#00バイト
444各予備表の大きさUint32
484*N_ST予備表の位置Uint32
48+4*N_ST16-4*N_STパッド#00バイト

2.2.10 仮想割付け表

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

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

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

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

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

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

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

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

表2.12 仮想割付け表構造
オフセット長さ名前内容
02ヘッダの長さ(=L_HD)Uint16
22処理システム用の長さ(=L_IU)Uint16
4128論理ボリューム記述子dstring
1324VAT ICB前位置Uint32
1364FID識別ファイル数Uint32
1404ディレクトリ識別の非親FID数Uint32
1442UDF最小書込み版Uint16
1462UDF最小読取り版Uint16
1482UDF最大書込み版Uint16
1502予備#00バイト
152L_IU処理システム用バイト
152+L_IU4VATエントリ0Uint32
156+L_IU4VATエントリ1Uint32
    
情報 長さ-44VATエントリnUint32

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

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

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

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

e) ファイルを識別するFIDの数 ボリュームでファイル数を識別し,ハードリンクを含む。ファイル数には,ディレクトリビットが設定されない階層のあらゆるFIDが含まれる。1に設定された削除ビットをもつ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において対応する欄の代わりに処理システムで使用しなければならない。 処理システム用−長さが0でない場合,処理システム用領域の残りの使用を識別する実体識別子から始める。

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

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

2.2.11 予備表

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

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

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

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

表2.13 予備表配置
BP長さ名前内容
016記述子タグタグ=0
1632予備識別子EntityID
482再割付け表長(=RT_L)Uint16
502予備#00バイト
524列番号Uint32
568*RT_Lマップエントリマップエントリ

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

表2.14 マップエントリ記述
RBP長さ名前内容
04元の位置Uint32
44マップ位置Uint32


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

2.3.1 記述子タグ(Descriptor Tag)

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

2.3.1.1 タグ通し番号(Uint16 TagSerialNumber)

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

2.3.1.2 記述子CRC長(Uint16 DescriptorCRCLength)

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

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

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

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

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

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

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

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

2.3.2.1 交換水準(Uint16 InterchangeLevel)

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

2.3.2.2 最大交換水準(Uint16 MaximumInterchangeLevel)

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

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

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

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

2.3.2.7 範囲識別子(struct EntityID DomainIdentifier)

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

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

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

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

2.3.3.1 区画保全表(struct short_ad PartitionIntegrityTable)

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

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

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

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

2.3.4.1 ファイル版数(Uint16 FileVersionNumber)

2.3.4.2 ファイル特性(File Characteristics)

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

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

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

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

2.3.4.3 structlong_ad ICB

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

表2.15 UDF一意ID
RBP長さ名前内容
02予備バイト(=#00)
24UDF一意IDUint32

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

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

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

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

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

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

2.3.5 ICBタグ(ICB Tag)

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

2.3.5.1 方策種別(Uint16 StrategyType)

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

2.3.5.2 ファイル種別(Uint8 FileType)

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

2.3.5.3 親ICB位置(ParentICBLocation)

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

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

2.3.5.4 フラグ(Uint16 Flags)

a) ビット0〜2

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

b) ビット3(分類)

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

d) ビット9(連続性)

e) ビット11(変換)

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

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

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

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

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

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

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

2.3.6.3 レコード長(Uint32 RecordLength)

2.3.6.4 情報長(Uint64 InformationLength)

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

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

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

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

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

2.3.6.7 一意ID(Uint64 UniqueID)

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

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

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

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

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

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

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

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

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

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

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

2.3.8.1 記述子タグ(struct Tag DescriptorTag)

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

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

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

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

2.3.10 割付け記述子(Allocation Descriptor)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.12 パス名(Pathname)

2.3.12.1 パス要素(Path Component)

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

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


2.4 第5部 レコード構造

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


3. システム依存要件

3.1 第1部 一般

3.1.1 日時表示 (Timestamp)

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

3.1.1.1 1/100秒(Uint8 Centisecond)

3.1.1.2 100マイクロ秒(Uint8 HundredsofMicrosecond)

3.1.1.3 マイクロ秒(Uint8 Microceconds)


3.2 第3部 ボリューム構造

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

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

3.2.1.1 一意ID(Uint64 UniquID)

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

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

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

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

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

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


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

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

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

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

3.3.1.1 ファイル特性(Uint8 FileChacteristics)

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

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

3.3.1.1.2 UNIX

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

3.3.2 ICBタグ

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

3.3.2.1 フラグ(Uint16 Flags)

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

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

b) ビット8(Sticky)

c) ビット10(System)

3.3.2.1.2 Macintosh

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

b) ビット8(Sticky)

c) ビット10(System)

3.3.2.1.3 UNIX

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

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

b) ビット10(System)

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

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

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

3.3.3.1 利用者ID(Uint32 Uid)

3.3.3.2 グループID(Uint32 Gid)

3.3.3.3 許可条件(Uint32 Permissions)

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

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

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

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

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

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

表3.1 許可条件
許可ファイル/ディレクトリ記述DOSOS/2Win95WinNTMacOSUNIX
読出しファイルファイルを読み出してもよい。11111U
読出しディレクトリディレクトリが実行の表示がある場合だけ,読み出してもよい。11111U
書込みファイルファイルの内容を修正してもよい。UUUUUU
書込みディレクトリディレクトリが実行の表示がある場合だけ,ファイル又は,サブディレクトリは,名前を変更したり,加えたり,削除してもよい。UUUUUU
実行ファイルファイルは実行してもよい。00000U
実行ディレクトリディレクトリの許可条件は,変更してもよい。11111U
属性ファイルファイルの許可条件は変更してもよい。11111備考1
属性ディレクトリディレクトリの許可条件は変更してもよい。11111備考1
削除ファイルファイルは削除してもよい。備考2備考2備考2備考2備考2備考2
削除ディレクトリディレクトリは削除してもよい。備考2備考2備考2備考2備考2備考2
U - 利用者指定,1 - 設定,0 - 除去

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

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

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

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

表3.2 各OSの許可条件ビット処理
許可ファイル/ディレクトリ記述DOSOS/2Win95WinNTMacOSUNIX
読出しファイルファイルを読み出してもよい。EEEEEE
読出しディレクトリディレクトリを読み出してもよい。EEEEEE
書込みファイルファイルの内容を更新してもよい。EEEEEE
書込みディレクトリファイル又はディレクトリを作成,削除又は名前変更してもよい。EEEEEE
実行ファイルファイルを実行してもよい。IIIIIE
実行ディレクトリファイル又はサブディレクトリを規定するために,ディレクトリを検索してもよい。EEEEEE
属性ファイルファイルの許可条件を変更してもよい。EEEEEE
属性ディレクトリディレクトリの許可条件を変更してもよい。EEEEEE
削除ファイルファイルを削除してもよい。EEEEEE
削除ディレクトリディレクトリを削除してもよい。EEEEEE
E - 実施する, I - 無視する

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

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

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

3.3.3.4 一意ID(Uint64 UniqueID)

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

3.3.3.5 拡張属性 (byte Extended Attributes)

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

3.3.4 拡張属性(Extended Attributes)

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

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

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

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

3.3.4.2 代替許可条件(Alternate Permissions)

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

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

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

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

3.3.4.3.1 ファイル日時(byte FileTimes)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3.4.5.1.1 空きEA空間(FreaaEAspace)

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

"*UDF FreeEASpace"
に設定する。

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

表3.3 空きEA空間のフォーマット
RBP長さ名前内容
02ヘッダチェックサムUint16
2IU_L-1空きEA空間バイト

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

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

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

"*UDF DVD CGMS Info"
に設定する。

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

表3.4 DVD CGMS Infoのフォーマット
RBP長さ名前内容
02ヘッダチェックサムUint16
21CGMS情報バイト
31データ構造種別Uint8
44保護システム情報バイト

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

3.3.4.5.2 MS-DOS,Windows95,WindowsNT

3.3.4.5.3 OS/2

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

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

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

"*UDF OS/2 EALength"
を設定する処理システム用拡張属性として記録しなければならない。

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

表3.5 OS/2拡張属性長フォーマット
RBP長さ名前内容
02ヘッダチェックサムUint16
24OS/2拡張属性長Uint32

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

3.3.4.5.4 Macintosh OS

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

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

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

"*UDF Mac VolumeInfo"
を設定する処理システム用拡張属性として記録しなければならない。

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

表 3.6 Macintoshボリューム情報フォーマット
RBP長さ名前内容
02ヘッダチェックサムUint16
212最後の更新日時timestamp
1412最後のバックアップ日時timestamp
2632ボリュームファインダ情報Uint32

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

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

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

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

"*UDF Mac FinderInfo"
を設定する処理システム用拡張属性として記録しなければならない。

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

表3.7 ディレクトリに対するMacintoshファインダ情報フォーマット
RBP長さ名前内容
02ヘッダチェックサムUint16
22埋込み(=0)Uint16
44親ディレクトリIDUint32
816ディレクトリ情報UDFDInfo
2416ディレクトリ拡張情報UDFDXInfo

表3.8 ファイルに対するMacintoshファインダ情報フォーマット
RBP長さ名前内容
02ヘッダチェックサムUint16
22埋込み(=0)Uint16
44親ディレクトリIDUint32
816ファイル情報UDFFInfo
2416ファイルの拡張情報UDFFXInfo
404リソースフォークデータ長Uint32
444リソースフォーク割付け長Uint32

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

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

表3.9 UDFPointフォーマット(ボリュームI, 139ページ)
RBP長さ名前内容
02VInt16
22HInt16

表3.10 UDFRectフォーマット(ボリュームI, 141ページ)
RBP長さ名前内容
02TopInt16
22LeftInt16
42BottomInt16
62RightInt16

表3.11 UDFDInfoフォーマット(ボリュームIV, 105ページ)
RBP長さ名前内容
08FrRectUDFRect
82FrFlagsInt16
104FrLocationUDFPoint
142FrViewInt16

表3.12 UDFDXInfoフォーマット(ボリュームIV, 106ページ)
RBP長さ名前内容
04FrScrollUDFPoint
44FrOpenChainInt32
81FrScriptUint8
91FrXflagsUint8
102FrCommentInt16
124FrPutAwayInt32

表3.13 UDFFInfoフォーマット(ボリュームII, 84ページ)
RBP長さ名前内容
04FdTypeUint32
44FdCreatorUint32
82FdFlagsUint16
104FdLocationUDFPoint
142FdFldrInt16

表3.14 UDFFXInfoフォーマット(ボリュームII, 105ページ)
RBP長さ名前内容
02FdIconIDInt16
26FdUnusedバイト
81FdScriptInt8
91FdXFlagsInt8
102FdCommentInt16
124FdPutAwayInt32

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

3.3.4.5.5 UNIX

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

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

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

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

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

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

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

"*UDF FreeAppEASpace"
を設定するアプリケーション用拡張属性として記録しなければならない。

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

表3.15 FreeAppEASpaceのフォーマット
RBP長さ名前内容
02ヘッダチェックサムUint16
2IU_L-1空きEA空間バイト

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

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

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

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

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

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

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

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

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

制約

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"*UDF Unique ID Mapping Data"
に設定するものとする。

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

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

表3.17 UDF一意IDマッピングデータ
RBP長さ名前内容
032処理システム識別子実体ID
324フラグUint32
364マッピングエントリカウント(=MEC)Uint32
408予備バイト(=#00)
4816*MECマッピングエントリIDマッピングエントリ

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

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

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

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

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

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

表3.18 UDF一意IDマッピングエントリ
RBP長さ名前内容
04UDF一意IDUint32
44親論理ブロック番号Uint32
84対象論理ブロック番号Uint32
122親区画参照数Uint16
142対象区画参照数Uint16

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

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

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

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

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

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

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

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

"*UDF Non-Allocatable Space"

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

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

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

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

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

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

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

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

"*UDF Power Cal Table"

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

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

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

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

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

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

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

表3.20 パワー較正表記録レイアウト
RBP長さ名前内容
02レコード長Uint16[1/7.1.3]
22ドライブ一意領域長[DUA_L]Uint16[1/7.1.3]
432ベンダIDバイト
3616製品IDバイト
524ファームウェア改訂レベルバイト
5616連続番号/装置一意IDバイト
728ホストIDバイト
8012生成日時スタンプ日時スタンプ[1/7.3]
9212更新日時スタンプ日時スタンプ[1/7.3]
1042速度Uint16[1/7.1.3]
1066パワー較正値バイト
112[DUA_L]ドライブ一意領域バイト

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

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

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

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

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

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

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

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

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

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

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

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

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

このストリームの名前は

"*UDF Backup"
に設定しなければならない。

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

表3.21 UDFバックアップ日時
RBP長さ名前内容
012バックアップ日時日時スタンプ

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

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

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

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

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

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

"*UDF Macintosh Resource Fork"

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

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

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

"*UDF OS/2 EA"

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

表3.23 FEAフォーマット
RBP長さ名前内容
01FlagsUint8
11Length of Name(=L_N)Uint8
22Length of Value(=L_V)Uint16
4L_NNameバイト
4+L_NL_VValueバイト

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

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

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

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

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

"*UDF NT ACL"
この名前は,Windows NTオペレーティングシステムで,名前付きストリームACLを識別するものとする。
"*UDF UNIX ACL"
この名前は,UNIXオペレーティングシステムで,名前付きストリームACLを識別するものとする。


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

4.1 第3部 ボリューム構造

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

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

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


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

4.2.1 ICBタグ(ICB Tag)

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

4.2.1.1 ファイル種別(FileType)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

定義

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

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

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

4.2.2.1.1 MS-DOS

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

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

4.2.2.1.2 OS/2

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

4.2.2.1.3 Macintosh

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

4.2.2.1.4 Windows 95及びWindows NT

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

4.2.2.1.5 UNIX

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


5. 参考

5.1 記述子長

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

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

N/A:規定しない


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

5.2.1 実体識別子(Entity Identifier)

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

5.2.2 孤立空間(Orhan Space)

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

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


5.3 起動記述子

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


5.4 技術的問合わせ

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

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

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

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


6. 附属書

6.1 UDF実体識別記述子


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


6.2 UDF実体識別値


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


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

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

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

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

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

表6.4 OS識別子の値
OSクラスOS識別子識別されるオペレーティングシステム
0任意の値未定義
10DOS/Windows 3.x
20OS/2
30Macintosh OS System 7
40UNIX-Generic
41UNIX-IBM AIX
42UNIX-SUN OS/Solaris
43UNIX-HP/UX
44UNIX-Silicon Graphics Irix
45UNIX-Linux
46UNIX-MKLinux
47UNIX-FreeBSD
50Windows 95
60Windows NT

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

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


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


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


6.5 CRC計算


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

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

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

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

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

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


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


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

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

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

         図6.1 ICB番地の規定

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


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

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

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

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

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

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

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


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


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


6.9 DVD-ROMに対する要件

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


6.10 CD媒体に関する勧告

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

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

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

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

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

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

6.10.1.1 要求事項

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

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

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

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

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

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

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

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

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

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

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

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

6.10.1.3 セションデータの末端

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

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

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

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

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

6.10.2.1 要求事項

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

b) 書込みは,モード1又はモード2,フォーム1セクタを使用して行うものとする。1枚のディスクではモード1又はモード2フォーム1を使用するものとする。

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

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

d) ホストでは,2Kセクタの書込みを明確に行えるように,読み出し/訂正/書込みを実行するものとする。

e) パケット長はディスクのフォーマット時に設定するものとする。パケット長は32セクタ(64KB)とする。

f) ホストでは,割付け禁止空間リストを使用して,ディスクに欠陥リストを保守するものとする。(3.3.7.1.2を参照。)

g) 予備は,予備可能区画及び予備表を介してホストが管理するものとする。

h) ディスクは使用前に初期化するものとする。

6.10.2.2 初期化

初期化は,リードイン,利用者データ領域,リードアウトから成るものとする。これらの領域は,任意の順序で書込みをしてもよい。この物理的フォーマットには,検証パスが続いてもよい。検証パスの間に見つかる欠陥は,割付け禁止空間リストに列挙しなければならない(3.3.7.1.2を参照。)。最後にファイルシステムルート構造が記録されるものとする。これらの強制的なファイルシステム及びルート構造にはボリューム認識列,開始ボリューム記述子ポインタ,ボリューム記述子列,ファイルセット記述子,及びルートディレクトリが含まれる。

開始ボリューム記述子ポインタはセクタ256及びN-256に記録しなければならないが,この場合,Nは,番地付け可能な最後のセクタの物理番地とする。

予備の割付けは,初期化プロセスの間に行うものとする。予備割付けの長さは0でもよい。

空き空間記述子を,欠陥領域及びセクタ予備領域に割り付けられた空間を反映するように,記録しなければならない。

フォーマットは,媒体で利用可能なすべての空間を含んでよい。しかし,利用者が要求した場合,初期化時間を節約するため,部分集合を初期化してもよい。その,少量のフォーマットを,後に,完全に利用可能な空間に"成長"させてもよい。

6.10.2.3 成長するフォーマット

媒体を部分的に初期化し,後に大きく成長させてもよい。この動作は次の要素から成る。

6.10.2.4 ホストベースの欠陥管理

ホストでは欠陥管理動作を行うものとする。CDフォーマットは欠陥管理を含めないで定義されたので,現存の技術及びコンポーネントと互換性をもたせるには,ホストで欠陥を管理しなければならない。初期化時に不良セクタを表示し,オンラインで予備を割り当てるのが,欠陥管理の2段階とする。ホストは現在の媒体に表を保持するものとする。

6.10.2.5 読み出し訂正書込み動作

CD-RW媒体は大きな書込み可能単位を必要とする。これは,各装置が,14KBオーバヘッドを受けるためとする。ファイルシステムは2KBの書込み可能単位を必要とする。書込みサイズの差は,ホストの読み出し−訂正−書込み動作で処理される。パケット全体が読み取られ,適切な部分が訂正され,パケット全体がCDに書込まれる。

パケットは,32セクタ境界に整列しなくてもよい。

6.10.2.6 適合のレベル

6.10.2.6.1 レベル1

ディスクは,厳密に1個のリードイン,プログラム領域,及びリードアウトで初期化するものとする。プログラム領域は,厳密に1個のトラックを含むものとする。区画は,パケット境界で開始するものとする。区画長はパケットサイズの整数倍とする。

6.10.2.6.2 レベル2

最後のセションはUDFファイルシステムを含むものとする。事前のすべてのセションは,1個の読み出し専用区画に含まれるものとする。

6.10.2.6.3 レベル3

いかなる制約も適用してはならない。

6.10.3 複セション及び混合モード

ボリューム認識列及び開始ボリューム記述子ポインタの位置は,ディスクの始まりに関連する位置であると,JIS X 0607で規定されている。ディスクの始まりは,VRS及びAVDPを見つける目的で,基本番地Sから決定するものとする。

'S'は,ボリュームの最後の既存のセション内に記録された,最初のデータトラックの,最初のデータセクタの物理番地とする。'S'は,複セションのJIS X 0606の記録で現在使われているもと同じ値とする。このセションの最初のトラックはデータトラックとする。

'N'はディスクに記録された最後のデータセクタの物理セクタ数とする。任意書込みモードを使用する場合,媒体は0又は1のオーディオセションで初期化し,その後に,1個のトラックを含む,書込み可能なデータセションを厳密に1個続けてもよい。他のセションの構成も可能だが,ここでは記述していない。1回に1個だけ書込み可能区画又はセションがあるものとし,このセションはディスクでは最後のセションとする。

6.10.3.1 ボリューム認識列

複セションディスクを扱うために,次の記述をUDFに加える(JIS X 0607第2部参照)。

6.10.3.2 開始ボリューム記述子ポインタ

開始ボリューム記述子ポインタ(AVDP)は,S+256及びN-256の論理セクタ数に記録するものとする。セクタN-256のAVDPはセションを閉じる前に記録するものとする。セションを開放している間は,記録しなくてもよい。

6.10.3.3 UDFブリッジフォーマット

UDFブリッジフォーマットにより,UDFは,別のファイルシステムを含んでいるディスクに加えることができる。UDFブリッジディスクは,最後のセションにUDFファイルシステムを含むものとする。最後のセションは,前述の"複セションと混合モード"に記述された規則に従うものとする。このディスクは,JIS X 0606,オーディオ,ベンター一意,又は,結合されたファイルシステムに基くセションを含んでもよい。UDFブリッジフォーマットにより,CD強化ディスクが作成できる。

新しい主ボリューム記述子列及び予備ボリューム記述子列は, 各追加セションに存在してもよく,前のVDSと異なってもよい。

CDの最後のセションが,有効なUDFファイルシステムを含まない場合,そのディスクはUDFディスクではない。最後のセションのUDF構造,UDF構造,及びそれらで参照されるデータだけが有効とする。

UDFセションは,他のセションのデータ又はメタデータを示すポインタ,UDFセション内だけにあるデータ又はメタデータを示すポインタ,又は両方のセションを結合した場合のデータ又はメタデータを示すポインタを含んでもよい。UDFブリッジディスクのいくつかの例を次に示す。


図6.1 複セションUDFディスク


図6.2 CD強化ディスク


図6.3 JIS X 0606のUDFへの変換


図6.4 異種フォーマットのUDFへの変換


6.11 UDF媒体フォーマット改訂履歴

次の表は,媒体に記録できるUDFフォーマットに影響するUDF定義の変更がいつ行われたかを示す。各変更を示す文書変更通知(DCN)が表中に記入してある。変更UDF版数の欄には,変更を含むUDF規定の版数を示す。UDF読出し最小版数及びUDF書込み最小版数の欄は,2.2.6.4で記述する版数アクセス制御欄に関連する。

表6.6 改訂履歴
記述DCN変更UDF版数UDF読出し最小版数UDF書込み最小版数
割付けエクステント記述子2-0021.021.021.02
パス要素ファイル版数2-0031.021.021.02
親ディレクトリエントリ2-0041.021.021.02
装置仕様拡張属性2-0051.021.011.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