exFAT ファイル システムの仕様

  • [アーティクル]

1 Introduction (はじめに)

exFAT ファイル システムは、ファイル システムの FAT ファミリの FAT32 の後継システムです。 この仕様では、exFAT ファイル システムについて説明し、exFAT ファイル システムを実装するために必要なすべての情報を提供します。

1.1 設計目標

exFAT ファイル システムには、3 つの中心的な設計目標があります (以下の一覧を参照)。

  1. FAT ベースのファイル システムのシンプルさを維持します。

    FAT ベースのファイル システムの 2 つの強みは、相対的なシンプルさと実装の容易さです。 前任者の精神の中で、実装者はexFATを比較的シンプルで簡単に実装する必要があります。

  2. 非常に大きなファイルとストレージ デバイスを有効にします。

    exFAT ファイル システムでは、64 ビットを使用してファイル サイズが記述されるため、非常に大きなファイルに依存するアプリケーションが可能になります。 exFAT ファイル システムでは、32 MB のクラスターも使用でき、非常に大きなストレージ デバイスを効果的に実現できます。

  3. 将来のイノベーションのための拡張性を組み込みます。

    exFAT ファイル システムは、その設計に拡張性を組み込み、ファイル システムがストレージのイノベーションと使用状況の変化に対応できるようにします。

1.2 特定の用語

この仕様のコンテキストでは、特定の用語 ( 表 1 を参照) は、exFAT ファイル システムの設計と実装に固有の意味を持ちます。

表 1 非常に具体的な意味を持つ用語の定義

用語 定義
Shall この仕様では、"shall" という用語を使用して、必須の動作を記述します。
推奨 この仕様では、"should" という用語を使用して、強く推奨される動作を記述しますが、必須ではありません。
May この仕様では、"may" という用語を使用して、省略可能な動作を記述します。
Mandatory この用語は、実装が変更し、この仕様で説明されているように解釈するフィールドまたは構造体を記述します。
オプション この用語は、実装でサポートされるフィールドまたは構造体を表します。 実装で特定の省略可能なフィールドまたは構造体がサポートされている場合は、この仕様で説明されているように、フィールドまたは構造体を変更し、解釈する必要があります。
未定義。 この用語は、実装が必要に応じて変更する可能性があるフィールドまたは構造体の内容 (つまり、周囲のフィールドまたは構造体を設定する場合はゼロにクリア) を記述し、特定の意味を保持するように解釈しません。
予約されています。

この用語では、実装するフィールドまたは構造体の内容について説明します。

  1. ゼロに初期化し、任意の目的で使用しないでください。

  2. チェックサムを計算する場合を除き、解釈しないでください

  3. 周囲のフィールドまたは構造体を変更する操作全体を保持する

1.3 一般的な頭字語の全文

この仕様では、パーソナル コンピューター業界で一般的に使用される頭字語を使用します ( 表 2 を参照)。

表 2 一般的な頭字語の全文

頭字語 [フルテキスト]
ASCII 米国標準コード情報交換
BIOS 基本的な入力出力システム
CPU 中央処理装置
exFAT 拡張可能なファイル割り当てテーブル
FAT ファイルの割り当てテーブル
FAT12 ファイル割り当てテーブル、12 ビット クラスター インデックス
FAT16 ファイル割り当てテーブル、16 ビット クラスター インデックス
FAT32 ファイル割り当てテーブル、32 ビット クラスター インデックス
GPT GUID パーティション テーブル
GUID グローバル一意識別子 ( セクション 10.1 を参照)
INT 割り込み
MBR マスター ブート レコード
texFAT トランザクション セーフな exFAT
UTC 協定世界時

1.4 既定のフィールドと構造体の修飾子

この仕様のフィールドと構造体には、仕様に特に注意がない限り、次の修飾子があります (以下の一覧を参照)。

  1. 符号なし

  2. 10 進表記を使用して値を記述します。特に特に記載されていません。この仕様では、修正後の文字 "h" を使用して 16 進数を示し、GUID を中かっこで囲みます

  3. リトル エンディアン形式

  4. 文字列に null 終端文字は必要ありません

1.5 Windows CEと TexFAT

TexFAT は、基本ファイル システムの上にトランザクション セーフな操作セマンティクスを追加する exFAT の拡張機能です。 TexFAT は、Windows CEによって使用されます。 TexFAT では、トランザクションで使用するために 2 つの FAT と割り当てビットマップを使用する必要があります。 また、パディング記述子やセキュリティ記述子など、いくつかの追加の構造体も定義します。

2 ボリューム構造

ボリュームとは、ユーザー データを格納および取得するために必要なすべてのファイル システム構造とデータ領域のセットです。 すべての exFAT ボリュームには、4 つのリージョンが含まれています ( 表 3 を参照)。

表 3 ボリューム構造

サブリージョン名

Offset

(セクター)

[サイズ]

(セクター)

 コメント
メイン ブートリージョン
メイン ブート セクター 0 1 このサブリージョンは必須であり、 セクション 3.1 ではその内容が定義されています。
メイン拡張ブート セクター 1 8 このサブリージョンは必須であり、 セクション 3.2) はその内容を定義します。
主要な OEM パラメーター 9 1 このサブリージョンは必須であり、 セクション 3.3 ではその内容が定義されています。
メイン予約済み 10 1 このサブリージョンは必須であり、その内容は予約されています。
メイン ブート チェックサム 11 1 このサブリージョンは必須であり、 セクション 3.4 ではその内容が定義されています。
バックアップ ブートリージョン
バックアップ ブート セクター 12 1 このサブリージョンは必須であり、 セクション 3.1 ではその内容が定義されています。
拡張ブート セクターのバックアップ 13 8 このサブリージョンは必須であり、 セクション 3.2 ではその内容が定義されています。
OEM パラメーターのバックアップ 21 1 このサブリージョンは必須であり、 セクション 3.3 ではその内容が定義されています。
バックアップ予約済み 22 1 このサブリージョンは必須であり、その内容は予約されています。
バックアップ ブート チェックサム 23 1 このサブリージョンは必須であり、 セクション 3.4 ではその内容が定義されています。
FAT リージョン
FAT の配置 24 FatOffset – 24

このサブリージョンは必須であり、その内容 (存在する場合) は未定義です。

注: メインブートセクターとバックアップブートセクターの両方に FatOffset フィールドが含まれています。
最初の FAT FatOffset FatLength

このサブリージョンは必須であり、 セクション 4.1 ではその内容が定義されています。

注: メイン ブート セクターとバックアップ ブート セクターには、どちらも FatOffset フィールドと FatLength フィールドが含まれています。
2 番目の FAT FatOffset + FatLength FatLength * (NumberOfFats – 1)

このサブリージョンは必須であり、 セクション 4.1 ではその内容が定義されます (存在する場合)。

注: Main ブート セクターとバックアップ ブート セクターには、どちらも FatOffset、FatLength、および NumberOfFats フィールドが含まれています。 NumberOfFats フィールドは、値 1 と 2 のみを保持できます。
データ領域
クラスター ヒープの配置 FatOffset + FatLength * NumberOfFats ClusterHeapOffset – (FatOffset + FatLength * NumberOfFats)

このサブリージョンは必須であり、その内容 (存在する場合) は未定義です。

注: Main ブート セクターとバックアップ ブート セクターには、どちらも FatOffset、FatLength、NumberOfFats、ClusterHeapOffset フィールドが含まれています。 NumberOfFats フィールドの有効な値は 1 と 2 です。
クラスター ヒープ ClusterHeapOffset ClusterCount * 2SectorsPerClusterShift

このサブリージョンは必須であり、 セクション 5.1 ではその内容が定義されています。

注: Main ブート セクターとバックアップ ブート セクターには、どちらも ClusterHeapOffset、ClusterCount、および SectorsPerClusterShift フィールドが含まれています。
余分な領域 ClusterHeapOffset + ClusterCount * 2SectorsPerClusterShift VolumeLength – (ClusterHeapOffset + ClusterCount * 2SectorsPerClusterShift)

このサブリージョンは必須であり、その内容 (存在する場合) は未定義です。

注: メイン ブート セクターとバックアップ ブート セクターには、どちらも ClusterHeapOffset、ClusterCount、SectorsPerClusterShift、VolumeLength フィールドが含まれています。

3 メインブートリージョンとバックアップブートリージョン

Main Boot リージョンには、次を実行するための実装を有効にするために必要なすべてのブートストラップ命令、情報の識別、およびファイル システム パラメーターが用意されています。

  1. exFAT ボリュームからコンピューター システムをブート ストラップします。

  2. ボリューム上のファイル システムを exFAT として識別します。

  3. exFAT ファイル システム構造の場所を検出します。

バックアップ ブート リージョンは、メイン ブート リージョンのバックアップです。 これは、メイン ブート 領域が不整合な状態にある場合の exFAT ボリュームの回復を支援します。 ブートストラップの手順の更新など、まれな状況を除き、実装ではバックアップ ブート リージョンの内容を変更しないでください。

3.1 メインおよびバックアップブートセクターサブリージョン

メイン ブート セクターには、exFAT ボリュームからのブート ストラップ用のコードと、ボリューム構造を記述する基本的な exFAT パラメーターが含 まれています (表 4 を参照)。 BIOS、MBR、またはその他のブートストラップエージェントは、このセクターを検査し、そこに含まれるブートストラップ命令を読み込んで実行することができます。

バックアップ ブート セクターはメイン ブート セクターのバックアップであり、同じ構造です ( 表 4 を参照)。 バックアップ ブート セクターは、復旧操作を支援する場合があります。ただし、実装では、VolumeFlags フィールドと PercentInUse フィールドの内容が古いものとして扱われます。

メイン ブート セクターまたはバックアップ ブート セクターのコンテンツを使用する前に、実装では、それぞれのブート チェックサムを検証し、すべてのフィールドが有効な値の範囲内であることを確認することで、その内容を確認する必要があります。

初期フォーマット操作ではメイン ブート セクターとバックアップ ブート セクターの両方の内容が初期化されますが、実装では、必要に応じてこれらのセクターを更新する (また、それぞれのブート チェックサムも更新する) 場合があります。 ただし、実装では、それぞれのブート チェックサムを更新せずに VolumeFlags フィールドまたは PercentInUse フィールドを更新できます (チェックサムではこれら 2 つのフィールドは特に除外されます)。

表 4 メインとバックアップのブート セクターの構造

フィールド名

Offset

(バイト)

[サイズ]

(バイト)

 コメント
JumpBoot 0 3 このフィールドは必須であり、 セクション3.1.1 はその内容を定義します。
FileSystemName 3 8 このフィールドは必須であり、 セクション3.1.2 はその内容を定義します。
MustBeZero 11 53 このフィールドは必須であり、 セクション 3.1.3 ではその内容を定義します。
PartitionOffset 64 8 このフィールドは必須であり、 セクション 3.1.4 ではその内容を定義します。
VolumeLength 72 8 このフィールドは必須であり、 セクション 3.1.5 ではその内容を定義します。
FatOffset 80 4 このフィールドは必須であり、 セクション 3.1.6 ではその内容を定義します。
FatLength 84 4 このフィールドは必須であり、 セクション 3.1.7 ではその内容を定義します。
ClusterHeapOffset 88 4 このフィールドは必須であり、 セクション 3.1.8 ではその内容を定義します。
ClusterCount 92 4 このフィールドは必須であり、 セクション 3.1.9 ではその内容を定義します。
FirstClusterOfRootDirectory 96 4 このフィールドは必須であり、 セクション 3.1.10 ではその内容を定義します。
VolumeSerialNumber 100 4 このフィールドは必須であり、 セクション 3.1.11 ではその内容を定義します。
FileSystemRevision 104 2 このフィールドは必須であり、 セクション 3.1.12 ではその内容を定義します。
VolumeFlags 106 2 このフィールドは必須であり、 セクション 3.1.13 ではその内容を定義します。
BytesPerSectorShift 108 1 このフィールドは必須であり、 セクション 3.1.14 ではその内容を定義します。
SectorsPerClusterShift 109 1 このフィールドは必須であり、 セクション 3.1.15 ではその内容を定義します。
NumberOfFats 110 1 このフィールドは必須であり、 セクション 3.1.16 ではその内容を定義します。
DriveSelect 111 1 このフィールドは必須であり、 セクション 3.1.17 ではその内容を定義します。
PercentInUse 112 1 このフィールドは必須であり、 セクション 3.1.18 ではその内容が定義されています。
予約されています。 113 7 このフィールドは必須であり、その内容は予約されています。
ブートコード 120 390 このフィールドは必須であり、 セクション 3.1.19 ではその内容を定義します。
BootSignature 510 2 このフィールドは必須であり、 セクション 3.1.20 ではその内容を定義します。
ExcessSpace 512 2BytesPerSectorShift – 512

このフィールドは必須であり、その内容 (存在する場合) は未定義です。

注: メインブートセクターとバックアップブートセクターの両方に BytesPerSectorShift フィールドが含まれています。

3.1.1 JumpBoot フィールド

JumpBoot フィールドには、パーソナル コンピューターで一般的な CPU のジャンプ命令が含まれている必要があります。これを実行すると、ブート コード フィールドでブートストラップ命令を実行するために CPU が "ジャンプ" されます。

このフィールドの有効な値は、EBh 76h 90h です (下位バイトから高位バイトの順)。

3.1.2 FileSystemName フィールド

FileSystemName フィールドには、ボリューム上のファイル システムの名前が含まれている必要があります。

このフィールドの有効な値は、ASCII 文字の "EXFAT" で、末尾に 3 つの空白が含まれます。

3.1.3 MustBeZero フィールド

MustBeZero フィールドは、パックされた BIOS パラメーター ブロックが FAT12/16/32 ボリュームで消費するバイト範囲に直接対応する必要があります。

このフィールドの有効な値は 0 です。これは、FAT12/16/32 実装が誤って exFAT ボリュームをマウントするのを防ぐのに役立ちます。

3.1.4 PartitionOffset フィールド

PartitionOffset フィールドは、指定された exFAT ボリュームをホストするパーティションのメディア相対セクター オフセットを記述する必要があります。 このフィールドは、パーソナル コンピューターで拡張 INT 13h を使用してボリュームからのブートストラップを支援します。

このフィールドに指定できる値はすべて有効です。ただし、値 0 は実装がこのフィールドを無視する必要があることを示します。

3.1.5 VolumeLength フィールド

VolumeLength フィールドは、セクター内の指定された exFAT ボリュームのサイズを記述する必要があります。

このフィールドの有効な値の範囲は次のようになります。

  • 最小ボリュームが 1 MB 以下であることを保証する少なくとも2 20/ 2BytesPerSectorShift

  • 最大 264 - 1、このフィールドが記述できる最大値。

    ただし、余分な領域のサブ領域のサイズが 0 の場合、このフィールドの最大値は ClusterHeapOffset + (232 - 11) * 2SectorsPerClusterShift です。

3.1.6 FatOffset フィールド

FatOffset フィールドは、最初の FAT のボリューム相対セクター オフセットを記述する必要があります。 このフィールドを使用すると、最初の FAT を基になるストレージ メディアの特性に合わせて実装できます。

このフィールドの有効な値の範囲は次のようになります。

  • メイン ブートリージョンとバックアップ ブート リージョンが消費するセクターを占める少なくとも 24 個

  • ClusterHeapOffset - (FatLength * NumberOfFats) は、クラスター ヒープが消費するセクターを考慮します。

3.1.7 FatLength フィールド

FatLength フィールドは、各 FAT テーブルの長さをセクター単位で記述する必要があります (ボリュームには最大 2 つの FAT が含まれる場合があります)。

このフィールドの有効な値の範囲は次のようになります。

  • 少なくとも (ClusterCount + 2) *2 2/2BytesPerSectorShiftが最も近い整数に切り上げられ、各 FAT にクラスター ヒープ内のすべてのクラスターを記述するための十分な領域が確保されます

  • 最大で (ClusterHeapOffset - FatOffset) / NumberOfFats は最も近い整数に切り捨て、クラスター ヒープの前に FAT が存在することを保証します

このフィールドは、第2のFATが存在する場合、基になる記憶媒体の特性に整合するように(前述したように)その下限を超える値を含んでいてもよい。 FAT 自体が必要とする内容を超えるスペースの内容 (存在する場合) は未定義です。

3.1.8 ClusterHeapOffset フィールド

ClusterHeapOffset フィールドは、クラスター ヒープのボリューム相対セクター オフセットを記述する必要があります。 このフィールドを使用すると、実装でクラスター ヒープを基になるストレージ メディアの特性に合わせて調整できます。

このフィールドの有効な値の範囲は次のようになります。

  • 少なくとも FatOffset + FatLength * NumberOfFats。

  • 最大 232- 1 または VolumeLength - (ClusterCount * 2SectorsPerClusterShift) のどちらか小さい方の計算

3.1.9 ClusterCount フィールド

ClusterCount フィールドには、クラスター ヒープに含まれるクラスターの数を記述する必要があります。

このフィールドの有効な値は、次の値より小さくする必要があります。

  • (VolumeLength - ClusterHeapOffset) / 2SectorsPerClusterShiftは、最も近い整数に切り捨てられます。これは、クラスター ヒープの先頭とボリュームの末尾の間に収まるクラスターの数です。

  • 232- 11。これは FAT が記述できるクラスターの最大数です。

ClusterCount フィールドの値によって、FAT の最小サイズが決まります。 非常に大きな FAT を回避するために、実装ではクラスター サイズを増やすことによってクラスター ヒープ内のクラスターの数を制御できます (SectorsPerClusterShift フィールドを使用)。 この仕様では、クラスター ヒープ内の 2 つ以上の 24 ~ 2 個のクラスターを推奨しています。 ただし、実装では、クラスター ヒープ内の最大 2 つの32 ~ 11 個のクラスターを持つボリュームを処理できる必要があります。

3.1.10 FirstClusterOfRootDirectory フィールド

FirstClusterOfRootDirectory フィールドには、ルート ディレクトリの最初のクラスターのクラスター インデックスが含まれている必要があります。 実装では、ルート ディレクトリの最初のクラスターを、割り当てビットマップとアップケース テーブルが使用するクラスターの後の最初の非不良クラスターに配置するようにあらゆる努力を行う必要があります。

このフィールドの有効な値の範囲は次のようになります。

  • 少なくとも 2、クラスター ヒープ内の最初のクラスターのインデックス

  • 最大 ClusterCount + 1、クラスター ヒープ内の最後のクラスターのインデックス

3.1.11 VolumeSerialNumber フィールド

VolumeSerialNumber フィールドには、一意のシリアル番号が含まれている必要があります。 これにより、異なる exFAT ボリュームを区別するための実装が支援されます。 実装では、exFAT ボリュームを書式設定する日時を組み合わせてシリアル番号を生成する必要があります。 日付と時刻を組み合わせてシリアル番号を形成するメカニズムは、実装固有です。

このフィールドに使用できる値はすべて有効です。

3.1.12 FileSystemRevision フィールド

FileSystemRevision フィールドは、指定されたボリューム上の exFAT 構造体のメジャー リビジョン番号とマイナー リビジョン番号を記述する必要があります。

上位バイトはメジャー リビジョン番号、下位バイトはマイナー リビジョン番号です。 たとえば、高位バイトに値 01h が含まれており、下位バイトに値 05h が含まれている場合、FileSystemRevision フィールドにはリビジョン番号 1.05 が記述されます。 同様に、上位バイトに値 0Ah が含まれており、下位バイトに値 0Fh が含まれている場合は、FileSystemRevision フィールドにリビジョン番号 10.15 が記述されます。

このフィールドの有効な値の範囲は次のようになります。

  • 下位バイトの場合は少なくとも 0、上位バイトの場合は 1

  • 下位バイトの場合は最大 99、上位バイトの場合は 99

この仕様で説明する exFAT のリビジョン番号は 1.00 です。 この仕様の実装では、メジャー リビジョン番号 1 の exFAT ボリュームをマウントし、その他のメジャー リビジョン番号で exFAT ボリュームをマウントすることはできません。 実装では、マイナー リビジョン番号を尊重し、操作を実行したり、指定されたマイナー リビジョン番号の対応する仕様に記載されていないファイル システム構造を作成したりすることはできません。

3.1.13 VolumeFlags フィールド

VolumeFlags フィールドには、exFAT ボリューム上のさまざまなファイル システム構造の状態を示すフラグが含まれている必要があります ( 表 5 を参照)。

それぞれの Main Boot または Backup Boot リージョンのチェックサムを計算する場合、実装にはこのフィールドは含まれません。 バックアップ ブート セクターを参照する場合、実装では、このフィールドを古いフィールドとして扱う必要があります。

表 5 VolumeFlags フィールド構造

フィールド名

Offset

(ビット)

[サイズ]

(ビット)

 コメント
ActiveFat 0 1 このフィールドは必須であり、 セクション3.1.13.1 はその内容を定義します。
VolumeDirty 1 1 このフィールドは必須であり、 セクション 3.1.13.2 ではその内容が定義されています。
MediaFailure 2 1 このフィールドは必須であり、 セクション 3.1.13.3 ではその内容が定義されています。
ClearToZero 3 1 このフィールドは必須であり、 セクション3.1.13.4 はその内容を定義します。
予約済み 4 12 このフィールドは必須であり、その内容は予約されています。
3.1.13.1 ActiveFat フィールド

ActiveFat フィールドでは、アクティブな FAT と割り当てビットマップ (および実装で使用する) を次のように記述する必要があります。

  • 0 は、最初の FAT と最初の割り当てビットマップがアクティブであることを意味します。

  • 1 は、2 番目の FAT と 2 番目の割り当てビットマップがアクティブであり、NumberOfFats フィールドに値 2 が含まれている場合にのみ可能であることを意味します。

実装では、非アクティブな FAT と割り当てビットマップは古いと見なす必要があります。 アクティブな FAT ビットマップと割り当てビットマップを切り替えるのは、TexFAT 対応の実装のみです ( セクション 7.1 を参照)。

3.1.13.2 VolumeDirty フィールド

VolumeDirty フィールドでは、ボリュームがダーティかどうかを次のように記述する必要があります。

  • 0 は、ボリュームが一貫性のある状態である可能性を意味します。

  • 1 は、ボリュームが一貫性のない状態である可能性を意味します

実装では、解決されないファイル システム メタデータの不整合が発生した場合に、このフィールドの値を 1 に設定する必要があります。 ボリュームのマウント時にこのフィールドの値が 1 の場合、ファイル システムメタデータの不整合を解決する実装のみが、このフィールドの値を 0 にクリアできます。 このような実装では、ファイル システムが一貫した状態であることを確認した後にのみ、このフィールドの値を 0 にクリアする必要があります。

ボリュームのマウント時にこのフィールドの値が 0 の場合、実装では、ファイル システム メタデータを更新する前にこのフィールドを 1 に設定し、その後、 セクション 8.1 で説明されている推奨される書き込み順序と同様に、このフィールドを 0 にクリアする必要があります。

3.1.13.3 MediaFailure フィールド

MediaFailure フィールドでは、実装でメディアエラーが検出されたかどうかを次のように記述する必要があります。

  • 0 は、ホスト メディアがエラーを報告していないか、既知のエラーが FAT に既に "不良" クラスターとして記録されていることを意味します

  • 1 は、ホスティング メディアがエラーを報告したことを意味します (つまり、読み取りまたは書き込み操作が失敗しました)

実装では、次の場合にこのフィールドを 1 に設定する必要があります。

  1. ホスティング メディアが、ボリューム内の任意のリージョンへのアクセス試行に失敗する

  2. 実装では、アクセス再試行アルゴリズムが使い果たされました (存在する場合)

ボリュームのマウント時に、このフィールドの値が 1 の場合、ボリューム全体でメディア障害をスキャンし、すべての障害を FAT 内の "不良" クラスターとして記録する実装 (またはそれ以外の場合はメディアエラーの解決) によって、このフィールドの値が 0 にクリアされる可能性があります。

3.1.13.4 ClearToZero フィールド

ClearToZero フィールドは、この仕様では重要な意味を持っていません。

このフィールドの有効な値は次のとおりです。

  • 特定の意味を持たない 0

  • 1。つまり、実装では、ファイル システムの構造、ディレクトリ、またはファイルを変更する前に、このフィールドを 0 にクリアする必要があります

3.1.14 BytesPerSectorShift フィールド

BytesPerSectorShift フィールドは、ログ2 (N) として表されるセクターあたりのバイト数を記述する必要があります。N はセクターあたりのバイト数です。 たとえば、セクターあたり 512 バイトの場合、このフィールドの値は 9 です。

このフィールドの有効な値の範囲は次のようになります。

  • 少なくとも 9 (セクター サイズは 512 バイト)、exFAT ボリュームで可能な最小セクターです

  • 最大 12 (セクター サイズは 4096 バイト) です。これは、パーソナル コンピューターで一般的な CPU のメモリ ページ サイズです。

3.1.15 SectorsPerClusterShift フィールド

SectorsPerClusterShift フィールドは、ログ2(N) として表されるクラスターごとのセクターを記述する必要があります。N はクラスターあたりのセクター数です。 たとえば、クラスターあたり 8 セクターの場合、このフィールドの値は 3 です。

このフィールドの有効な値の範囲は次のようになります。

  • 可能な最小クラスターである少なくとも 0 (クラスターあたり 1 セクター)

  • 最大 25 - BytesPerSectorShift。クラスター サイズは 32 MB に評価されます

3.1.16 NumberOfFats フィールド

NumberOfFats フィールドには、ボリュームに含まれる FAT と割り当てビットマップの数を記述する必要があります。

このフィールドの有効な値の範囲は次のようになります。

  • 1:ボリュームに最初の FAT と最初の割り当てビットマップのみが含まれていることを示します

  • 2 は、ボリュームに最初の FAT、2 番目の FAT、最初の割り当てビットマップ、および第 2 の割り当てビットマップが含まれていることを示します。この値は TexFAT ボリュームでのみ有効です

3.1.17 DriveSelect フィールド

DriveSelect フィールドには、拡張 INT 13h ドライブ番号が含まれている必要があります。これは、パーソナル コンピューターで拡張 INT 13h を使用して、このボリュームからのブートストラップを支援します。

このフィールドに使用できる値はすべて有効です。 以前の FAT ベースのファイル システムの同様のフィールドには、多くの場合、値 80h が含まれていました。

3.1.18 PercentInUse フィールド

PercentInUse フィールドには、割り当てられているクラスター ヒープ内のクラスターの割合を記述する必要があります。

このフィールドの有効な値の範囲は次のようになります。

  • 0 から 100 の範囲 (クラスター ヒープ内の割り当てられたクラスターの割合) は、最も近い整数に切り捨てられます

  • クラスター ヒープ内の割り当てられたクラスターの割合を示す FFh が正確に使用できない

実装では、クラスター ヒープ内のクラスターの割り当ての変更を反映するように、このフィールドの値を変更するか、FFh に変更する必要があります。

それぞれの Main Boot または Backup Boot リージョンのチェックサムを計算する場合、実装にはこのフィールドは含まれません。 バックアップ ブート セクターを参照する場合、実装では、このフィールドを古いフィールドとして扱う必要があります。

3.1.19 BootCode フィールド

BootCode フィールドには、ブートストラップ命令が含まれている必要があります。 実装では、コンピューター システムのブート ストラップに必要な CPU 命令をこのフィールドに設定できます。 ブートストラップ命令を提供しない実装では、フォーマット操作の一環として、このフィールドの各バイトを F4h (パーソナル コンピューターで一般的な CPU の停止命令) に初期化する必要があります。

3.1.20 BootSignature フィールド

BootSignature フィールドは、特定のセクターの意図がブート セクターであるかどうかを記述する必要があります。

このフィールドの有効な値は AA55h です。 このフィールドの他の値は、それぞれのブート セクターを無効にします。 実装では、それぞれのブート セクター内の他のフィールドに応じて、前にこのフィールドの内容を確認する必要があります。

メインおよびバックアップの拡張ブートセクターサブリージョン

メイン拡張ブート セクターの各セクターは同じ構造を持ちます。ただし、各セクターは個別のブート・ストラップ命令を保持できます (表 6 を参照)。 メイン ブート セクターのブートストラップ命令、代替 BIOS 実装、埋め込みシステムのファームウェアなどのブートストラップ エージェントは、これらのセクターを読み込み、含まれている命令を実行することがあります。

バックアップ拡張ブート セクターは、メイン拡張ブート セクターのバックアップであり、同じ構造です ( 表 6 を参照)。

Main または Backup Extended Boot Sector の命令を実行する前に、実装では、各セクターの ExtendedBootSignature フィールドに所定の値が含まれていることを確認して、その内容を確認する必要があります。

初期フォーマット操作では、Main と Backup の両方の拡張ブート セクターの内容が初期化されますが、実装では、必要に応じてこれらのセクターを更新 (およびそれぞれのブート チェックサムも更新する必要があります) 可能性があります。

表 6 拡張ブート セクター構造

フィールド名

Offset

(バイト)

[サイズ]

(バイト)

 コメント
ExtendedBootCode 0 2BytesPerSectorShift – 4

このフィールドは必須であり、 セクション 3.2.1 ではその内容が定義されます。

注: Main ブート セクターとバックアップ ブート セクターの両方に BytesPerSectorShift フィールドが含まれています。
ExtendedBootSignature 2BytesPerSectorShift – 4 4

このフィールドは必須であり、 セクション3.2.2 はその内容を定義します。

注: Main ブート セクターとバックアップ ブート セクターの両方に BytesPerSectorShift フィールドが含まれています。

3.2.1 ExtendedBootCode フィールド

ExtendedBootCode フィールドには、ブート・ストラップ命令が含まれている必要があります。 実装では、コンピューター システムのブート ストラップに必要な CPU 命令をこのフィールドに設定できます。 ブートストラップ命令を提供しない実装では、フォーマット操作の一環として、このフィールドの各バイトを 00h に初期化する必要があります。

3.2.2 ExtendedBootSignature フィールド

ExtendedBootSignature フィールドは、特定のセクターの意図が拡張ブート セクターであるかどうかを記述する必要があります。

このフィールドの有効な値は AA550000h です。 このフィールドのその他の値は、それぞれのメイン ブート セクターまたはバックアップ拡張ブート セクターを無効にします。 実装では、それぞれの拡張ブート セクター内の他のフィールドに応じて、前にこのフィールドの内容を確認する必要があります。

主要およびバックアップのOEMパラメータサブリージョン

メイン OEM パラメーター サブリージョンには、製造元固有の情報を含む可能性がある 10 個のパラメーター構造が含まれています ( 表 7 を参照)。 10 個の各パラメーター構造は、ジェネリック パラメーター テンプレートから派生します ( セクション 3.3.2 を参照)。 製造元は、ジェネリック パラメーター テンプレートから独自のカスタム パラメーター構造を派生させる場合があります。 この仕様自体では、Null パラメーター ( セクション 3.3.3 を参照) と Flash パラメーター ( セクション 3.3.4 を参照) の 2 つのパラメーター構造が定義されています。

バックアップ OEM パラメーターは、メイン OEM パラメーターのバックアップであり、同じ構造を持ちます ( 表 7 を参照)。

Main または Backup OEM パラメーターの内容を使用する前に、実装はそれぞれのブート チェックサムを検証して、その内容を検証する必要があります。

製造元は、Main および Backup OEM パラメーターに独自のカスタム パラメーター構造 (存在する場合) とその他のパラメーター構造を設定する必要があります。 後続のフォーマット操作では、メインおよびバックアップ OEM パラメーターの内容を保持する必要があります。

実装では、必要に応じて Main および Backup OEM パラメーターを更新できます (また、それぞれのブート チェックサムも更新する必要があります)。

表 7 OEM パラメーターの構造

フィールド名

Offset

(バイト)

[サイズ]

(バイト)

 コメント
Parameters[0] 0 48 このフィールドは必須であり、 セクション3.3.1 はその内容を定義します。

.

.

.

.

.

.

.

.

.

.

.

.
Parameters[9] 432 48 このフィールドは必須であり、 セクション 3.3.1 では その内容を定義します。
予約済み 480 2BytesPerSectorShift – 480

このフィールドは必須であり、その内容は予約されています。

注: メインブートセクターとバックアップブートセクターの両方に BytesPerSectorShift フィールドが含まれています。

3.3.1 Parameters[0] ...Parameters[9]

この配列の各 Parameters フィールドには、ジェネリック パラメーター テンプレートから派生するパラメーター構造が含まれています ( セクション 3.3.2 を参照)。 使用されていない Parameters フィールドは、Null Parameters 構造体を含むものとして記述する必要があります ( セクション 3.3.3 を参照)。

3.3.2 ジェネリック パラメーター テンプレート

ジェネリック パラメーター テンプレートは、パラメーター構造の基本定義を提供します ( 表 8 を参照)。 すべてのパラメーター構造は、このテンプレートから派生します。 この汎用パラメーター テンプレートのサポートは必須です。

表 8 ジェネリック パラメーター テンプレート

フィールド名

Offset

(バイト)

[サイズ]

(バイト)

 コメント
ParametersGuid 0 16 このフィールドは必須であり、 セクション 3.3.2.1 ではその内容を定義します。
CustomDefined 16 32 このフィールドは必須であり、このテンプレートから派生する構造体は、その内容を定義します。
3.3.2.1 ParametersGuid フィールド

ParametersGuid フィールドは、指定されたパラメーター構造の残りの部分のレイアウトを決定する GUID を記述する必要があります。

このフィールドに指定できる値はすべて有効です。ただし、製造元は、GuidGen.exeなどの GUID 生成ツールを使用して、このテンプレートからカスタム パラメーター構造を派生させるときに GUID を選択する必要があります。

3.3.3 Null パラメーター

Null Parameters 構造体は、ジェネリック パラメーター テンプレート ( セクション 3.3.2 を参照) から派生し、未使用の Parameters フィールドを記述する必要があります ( 表 9 を参照)。 OEM パラメーター構造を作成または更新する場合、実装では、使用されていないパラメーター フィールドに Null パラメーター構造体を設定する必要があります。 また、OEM パラメーター構造を作成または更新する場合、実装では、配列の末尾に Null パラメーター構造を統合する必要があります。これにより、他のすべての Parameters 構造体は OEM Parameters 構造体の先頭に残ります。

Null パラメーター構造体のサポートは必須です。

表 9 Null パラメーター構造体

フィールド名

Offset

(バイト)

[サイズ]

(バイト)

 コメント
ParametersGuid 0 16 このフィールドは必須であり、 セクション 3.3.3.1 ではその内容を定義します。
予約済み 16 32 このフィールドは必須であり、その内容は予約されています。
3.3.3.1 ParametersGuid フィールド

ParametersGuid フィールドは、汎用パラメーター テンプレートによって提供される定義に準拠する必要があります ( セクション 3.3.2.1 を参照)。

このフィールドの有効な値は、GUID 表記で指定します {00000000-0000-0000-0000-000000000000}。

3.3.4 フラッシュパラメータ

Flash Parameter 構造体は、汎用パラメーター テンプレート ( セクション 3.3.2 を参照) から派生し、フラッシュ メディアのパラメーターを含みます ( 表 10 を参照)。 フラッシュ ベースのストレージ デバイスの製造元は、パラメーター フィールド (好ましくは Parameters[0] フィールド) にこのパラメーター構造を設定できます。 実装では、Flash Parameters 構造体の情報を使用して、読み取り/書き込み中のアクセス操作を最適化し、メディアのフォーマットを制限するファイル システム構造のアラインメントを行う場合があります。

Flash Parameters 構造体のサポートは省略可能です。

表 10 フラッシュ パラメータの構造

フィールド名

Offset

(バイト)

[サイズ]

(バイト)

 コメント
ParametersGuid 0 16 このフィールドは必須であり、 セクション 3.3.4.1 ではその内容を定義します。
EraseBlockSize 16 4 このフィールドは必須であり、 セクション 3.3.4.2 ではその内容を定義します。
PageSize 20 4 このフィールドは必須であり、 セクション 3.3.4.3 ではその内容を定義します。
SpareSectors 24 4 このフィールドは必須であり、 セクション 3.3.4.4 では その内容を定義します。
RandomAccessTime 28 4 このフィールドは必須であり、 セクション 3.3.4.5 ではその内容を定義します。
ProgrammingTime 32 4 このフィールドは必須であり、 セクション 3.3.4.6 ではその内容を定義します。
ReadCycle 36 4 このフィールドは必須であり、 セクション 3.3.4.7 ではその内容を定義します。
WriteCycle 40 4 このフィールドは必須であり、 セクション3.3.4.8 はその内容を定義します。
予約済み 44 4 このフィールドは必須であり、その内容は予約されています。

ParametersGuid フィールドを除くすべての Flash パラメーター フィールドで使用できるすべての値が有効です。 ただし、値 0 は、フィールドが実際には無意味であることを示します (実装では、指定されたフィールドは無視されます)。

3.3.4.1 ParametersGuid フィールド

ParametersGuid フィールドは、汎用パラメーター テンプレートで提供されている定義に準拠する必要があります ( セクション 3.3.2.1 を参照)。

このフィールドの有効な値 (GUID 表記) は {0A0C7E46-3399-4021-90C8-FA6D389C4BA2} です。

3.3.4.2 EraseBlockSize フィールド

EraseBlockSize フィールドは、フラッシュ メディアの消去ブロックのサイズをバイト単位で記述する必要があります。

3.3.4.3 PageSize フィールド

PageSize フィールドは、フラッシュ メディアのページのサイズをバイト単位で記述する必要があります。

3.3.4.4 SpareSectors フィールド

SpareSectors フィールドは、フラッシュ メディアが内部のスペーリング操作で使用できるセクターの数を記述する必要があります。

3.3.4.5 RandomAccessTime フィールド

RandomAccessTime フィールドは、フラッシュ メディアの平均ランダム アクセス時間をナノ秒単位で記述する必要があります。

3.3.4.6 ProgrammingTime フィールド

ProgrammingTime フィールドでは、フラッシュ メディアの平均プログラミング時間をナノ秒単位で記述する必要があります。

3.3.4.7 ReadCycle フィールド

ReadCycle フィールドでは、フラッシュ メディアの平均読み取りサイクル時間をナノ秒単位で記述する必要があります。

3.3.4.8 WriteCycle フィールド

WriteCycle フィールドでは、平均書き込みサイクル時間をナノ秒単位で記述する必要があります。

3.4 メインおよびバックアップブートチェックサムサブリージョン

メイン ブート チェックサムとバックアップ ブート チェックサムにはそれぞれ、それぞれのブート リージョン内の他のすべてのサブリージョンのコンテンツの 4 バイト チェックサムの繰り返しパターンが含まれています。 チェックサム計算には、それぞれのブート セクターに VolumeFlags フィールドと PercentInUse フィールドは含まれません ( 図 1 を参照)。 4 バイト チェックサムの繰り返しパターンは、サブリージョンの先頭から末尾まで、それぞれのブート チェックサム サブリージョンを満たします。

Main または Backup Boot リージョンのいずれかの他のサブリージョンのコンテンツを使用する前に、実装では、それぞれのブート チェックサムを検証して、その内容を確認する必要があります。

初期フォーマット操作では、メイン ブート チェックサムとバックアップ ブート チェックサムの両方に繰り返しチェックサム パターンが設定されますが、実装では、それぞれのブート リージョン内の他のセクターの内容が変更されると、これらのセクターを更新する必要があります。

図 1 ブート チェックサムの計算

UInt32 BootChecksum
(
    UCHAR  * Sectors,        // points to an in-memory copy of the 11 sectors
    USHORT   BytesPerSector
)
{
    UInt32 NumberOfBytes = (UInt32)BytesPerSector * 11;
    UInt32 Checksum = 0;
    UInt32 Index;

    for (Index = 0; Index < NumberOfBytes; Index++)
    {
        if ((Index == 106) || (Index == 107) || (Index == 112))
        {
            continue;
        }
        Checksum = ((Checksum&1) ? 0x80000000 : 0) + (Checksum>>1) + (UInt32)Sectors[Index];
    }

    return Checksum;
}

4 ファイルの割り当てテーブル領域

ファイル割り当てテーブル (FAT) 領域には、1 つは最初の FAT サブ領域に、もう 1 つは第 2 FAT サブリージョンの最大 2 つの FAT が含まれる場合があります。 NumberOfFats フィールドには、このリージョンに含まれる FAT の数が記述されています。 NumberOfFats フィールドの有効な値は 1 と 2 です。 したがって、最初の FAT サブ領域には常に FAT が含まれます。 NumberOfFats フィールドが 2 の場合、2 番目の FAT サブ領域にも FAT が含まれます。

VolumeFlags フィールドの ActiveFat フィールドには、アクティブな FAT が記述されています。 メイン ブート セクターの VolumeFlags フィールドのみが最新です。 実装では、アクティブでない FAT を古い FAT として扱う必要があります。 非アクティブな FAT の使用と、FAT 間の切り替えは実装固有です。

4.1 第 1 および第 2 の FAT サブリージョン

FAT では、クラスター ヒープ内のクラスター チェーンについて説明する必要があります ( 表 11 を参照)。 クラスター チェーンは、ファイル、ディレクトリ、およびその他のファイル システム構造の内容を記録するための領域を提供する一連のクラスターです。 FAT は、クラスター チェーンをクラスター インデックスの一覧として表します。 最初の 2 つのエントリを除き、FAT 内のすべてのエントリは 1 つのクラスターを表します。

表 11 ファイル割り当てテーブルの構造

フィールド名

Offset

(バイト)

[サイズ]

(バイト)

 コメント
FatEntry[0] 0 4 このフィールドは必須であり、 セクション4.1.1 はその内容を定義します。
FatEntry[1] 4 4 このフィールドは必須であり、 セクション 4.1.2 ではその内容が定義されています。
FatEntry[2] 8 4 このフィールドは必須であり、 セクション4.1.3 はその内容を定義します。

.

.

.

.

.

.

.

.

.

.

.

.
FatEntry[ClusterCount+1] (ClusterCount + 1) * 4 4

このフィールドは必須であり、 セクション4.1.3 はその内容を定義します。

ClusterCount + 1 は FFFFFFF6h を超えてはいけません。

注: メイン ブート セクターとバックアップ ブート セクターの両方に ClusterCount フィールドが含まれています。
ExcessSpace (ClusterCount + 2) * 4 (FatLength * 2BytesPerSectorShift) – ((ClusterCount + 2) * 4)

このフィールドは必須であり、その内容 (存在する場合) は未定義です。

注: メイン ブート セクターとバックアップ ブート セクターには、どちらも ClusterCount、FatLength、BytesPerSectorShift フィールドが含まれています。

4.1.1 FatEntry[0] フィールド

FatEntry[0] フィールドは、最初のバイト (最下位バイト) のメディアの種類を記述し、残りの 3 バイトに FFh を含む必要があります。

メディアの種類 (最初のバイト) は F8h にする必要があります。

4.1.2 FatEntry[1] フィールド

FatEntry[1] フィールドは、履歴の優先順位によってのみ存在し、関心のあるものは何も記述しません。

このフィールドの有効な値は FFFFFFFFh です。 実装では、このフィールドを所定の値に初期化するものとし、このフィールドを任意の目的で使用しないでください。 実装では、このフィールドを解釈しないでください。また、周囲のフィールドを変更する操作全体でその内容を保持する必要があります。

4.1.3 FatEntry[2] ...FatEntry[ClusterCount+1] フィールド

この配列内の各 FatEntry フィールドは、クラスター ヒープ内のクラスターを表す必要があります。 FatEntry[2] はクラスター ヒープ内の最初のクラスターを表し、[ClusterCount+1] はクラスター ヒープ内の最後のクラスターを表します。

これらのフィールドの有効な値の範囲は次のようになります。

  • 2 と ClusterCount + 1 の間(包括的に、指定されたクラスター チェーン内の次の FatEntry を指します)。指定された FatEntry は、指定されたクラスター チェーン内の FatEntry の前に存在する FatEntry を指すものではありません。

  • 指定された FatEntry の対応するクラスターを "bad" としてマークする FFFFFFF7h とまったく同じ

  • 正確に FFFFFFFFh。指定された FatEntry の対応するクラスターをクラスター チェーンの最後のクラスターとしてマークします。これは、特定のクラスター チェーンの最後の FatEntry の唯一の有効な値です

5 データ領域

データ領域にはクラスター ヒープが含まれており、ファイル システムの構造、ディレクトリ、ファイルの管理領域を提供します。

5.1 クラスター ヒープ サブリージョン

クラスター ヒープの構造は非常に単純です ( 表 12 を参照)。SectorsPerClusterShift フィールドが定義するように、連続する各セクターでは 1 つのクラスターが記述されます。 重要なのは、クラスター ヒープの最初のクラスターにはインデックス 2 があり、FatEntry[2] のインデックスに直接対応します。

exFAT ボリュームでは、割り当てビットマップ ( セクション 7.1.5 を参照) は、すべてのクラスターの割り当て状態のレコードを保持します。 これは、FAT がクラスター ヒープ内のすべてのクラスターの割り当て状態の記録を保持していた exFAT の先行タスク (FAT12、FAT16、FAT32) とは大きく異なります。

表 12 クラスター ヒープ構造

フィールド名

Offset

(セクター)

[サイズ]

(セクター)

 コメント
Cluster[2] ClusterHeapOffset 2SectorsPerClusterShift

このフィールドは必須であり、 セクション 5.1.1 ではその内容を定義します。

注: メインブートセクターとバックアップブートセクターの両方に ClusterHeapOffset フィールドと SectorsPerClusterShift フィールドが含まれています。

.

.

.

.

.

.

.

.

.

.

.

.
Cluster[ClusterCount+1] ClusterHeapOffset + (ClusterCount – 1) * 2SectorsPerClusterShift 2SectorsPerClusterShift

このフィールドは必須であり、 セクション 5.1.1 ではその内容を定義します。

注: メイン ブート セクターとバックアップ ブート セクターには、どちらも ClusterCount、ClusterHeapOffset、SectorsPerClusterShift フィールドが含まれています。

5.1.1 Cluster[2] ...Cluster[ClusterCount+1] フィールド

この配列の各クラスター フィールドは連続した一連のセクターであり、そのサイズは SectorsPerClusterShift フィールドによって定義されます。

6 ディレクトリ構造

exFAT ファイル システムでは、ディレクトリ ツリーアプローチを使用して、クラスター ヒープに存在するファイル システムの構造とファイルを管理します。 ディレクトリには、ディレクトリ ツリー内の親と子の間に一対多のリレーションシップがあります。

FirstClusterOfRootDirectory フィールドが参照するディレクトリは、ディレクトリ ツリーのルートです。 他のすべてのディレクトリは、1 つのリンクされた方法でルート ディレクトリから派生します。

各ディレクトリは、一連のディレクトリ エントリで構成されます ( 表 13 を参照)。

1 つ以上のディレクトリ エントリが、ファイル システム構造、サブディレクトリ、ファイルなど、関心のあるものを記述するディレクトリ エントリ セットに結合されます。

表 13 ディレクトリ構造

フィールド名

Offset

(バイト)

[サイズ]

(バイト)

 コメント
DirectoryEntry[0] 0 32 このフィールドは必須であり、 セクション 6.1 ではその内容を定義します。

.

.

.

.

.

.

.

.

.

.

.

.
DirectoryEntry[N–1] (N – 1) * 32 32

このフィールドは必須であり、 セクション 6.1 ではその内容を定義します。

N (DirectoryEntry フィールドの数) は、指定されたディレクトリを含むクラスター チェーンのサイズ (バイト単位) を DirectoryEntry フィールドのサイズ (32 バイト) で割った値です。

6.1 DirectoryEntry[0] ...DirectoryEntry[N--1]

この配列の各 DirectoryEntry フィールドは、汎用 DirectoryEntry テンプレートから派生します ( セクション 6.2 を参照)。

6.2 汎用 DirectoryEntry テンプレート

汎用 DirectoryEntry テンプレートは、ディレクトリ エントリの基本定義を提供します ( 表 14 を参照)。 すべてのディレクトリ エントリ構造はこのテンプレートから派生し、Microsoft が定義したディレクトリ エントリ構造のみが有効です (exFAT には、 セクション 7.8 および セクション 7.9 で定義されている場合を除き、製造元が定義したディレクトリ エントリ構造のプロビジョニングはありません)。 汎用 DirectoryEntry テンプレートを解釈する機能は必須です。

表 14 汎用 DirectoryEntry テンプレート

フィールド名

Offset

(バイト)

[サイズ]

(バイト)

 コメント
EntryType 0 1 このフィールドは必須であり、 セクション 6.2.1 ではその内容を定義します。
CustomDefined 1 19 このフィールドは必須であり、このテンプレートから派生する構造体は、その内容を定義できます。
FirstCluster 20 4 このフィールドは必須であり、 セクション 6.2.2 ではその内容を定義します。
DataLength 24 8 このフィールドは必須であり、 セクション 6.2.3 ではその内容を定義します。

6.2.1 EntryType フィールド

EntryType フィールドには、フィールドの値が定義する 3 つの使用法モードがあります (下記の一覧を参照)。

  • 00h。ディレクトリの末尾マーカーであり、次の条件が適用されます。

    • 指定された DirectoryEntry 内の他のすべてのフィールドは、実際には予約されています

    • 指定されたディレクトリ内の後続のすべてのディレクトリ エントリも、ディレクトリの末尾マーカーです

    • ディレクトリの末尾マーカーは、ディレクトリ エントリ セットの外部でのみ有効です

    • 実装では、必要に応じてディレクトリの末尾マーカーが上書きされる可能性があります

  • 01h から 7Fh までの範囲で、未使用のディレクトリエントリ マーカーであり、次の条件が適用されます。

    • 指定された DirectoryEntry 内の他のすべてのフィールドは、実際には未定義です

    • 未使用のディレクトリ エントリは、ディレクトリ エントリ セットの外部でのみ有効です

    • 実装では、必要に応じて未使用のディレクトリ エントリが上書きされる可能性があります

    • この値の範囲は、値 0 を含む InUse フィールド ( セクション 6.2.1.4 を参照) に対応します

  • 81h から FFh までの範囲で、通常のディレクトリ エントリであり、次の条件が適用されます。

    • EntryType フィールドの内容 ( 表 15 を参照) によって、DirectoryEntry 構造体の残りの部分のレイアウトが決まります

    • この値の範囲と、この値の範囲のみが、ディレクトリ エントリ セット内で有効です

    • この値の範囲は、値 1 を含む InUse フィールド ( セクション 6.2.1.4 を参照) に直接対応します

InUse フィールドの変更 ( セクション 6.2.1.4 を参照) によってディレクトリの末尾マーカーが誤って発生するのを防ぐために、値 80h は無効です。

表 15 汎用 EntryType フィールド構造

フィールド名

Offset

(ビット)

[サイズ]

(ビット)

 コメント
TypeCode 0 5 このフィールドは必須であり、 セクション 6.2.1.1 ではその内容を定義します。
TypeImportance 5 1 このフィールドは必須であり、 セクション6.2.1.2 ではその内容を定義します。
TypeCategory 6 1 このフィールドは必須であり、 セクション6.2.1.3 はその内容を定義します。
InUse 7 1 このフィールドは必須であり、 セクション6.2.1.4 はその内容を定義します。
6.2.1.1 TypeCode フィールド

TypeCode フィールドは、指定されたディレクトリ エントリの特定の型を部分的に記述します。 このフィールドに加えて、TypeImportance フィールドと TypeCategory フィールド ( セクション 6.2.1.2 と セクション 6.2.1.3 を参照) は、指定されたディレクトリ エントリの種類を一意に識別します。

TypeImportance フィールドと TypeCategory フィールドの両方に値 0 が含まれている場合を除き、このフィールドのすべての使用可能な値が有効です。その場合、このフィールドの値 0 は無効です。

6.2.1.2 TypeImportance フィールド

TypeImportance フィールドは、指定されたディレクトリ エントリの重要性を記述する必要があります。

このフィールドの有効な値は次のようになります。

  • 0 は、指定されたディレクトリ エントリが重要であることを意味します (重要なプライマリ ディレクトリエントリとクリティカル セカンダリ ディレクトリ エントリについては、 セクション 6.3.1.2.1 と セクション 6.4.1.2.1 を参照)。

  • 1:指定されたディレクトリエントリが無害であることを意味します(良性のプライマリディレクトリエントリと無害なセカンダリディレクトリエントリについては、セクション6.3.1.2.2とセクション6.4.1.2.2を参照してください)

6.2.1.3 TypeCategory フィールド

TypeCategory フィールドは、指定されたディレクトリ エントリのカテゴリを記述する必要があります。

このフィールドの有効な値は次のようになります。

  • 0。指定されたディレクトリ エントリがプライマリであることを意味します ( セクション 6.3 を参照)

  • 1 は、指定されたディレクトリ エントリがセカンダリであることを意味します ( セクション 6.4 を参照)

6.2.1.4 InUse フィールド

InUse フィールドは、指定されたディレクトリ エントリが使用中かどうかを記述する必要があります。

このフィールドの有効な値は次のようになります。

  • 0。指定されたディレクトリ エントリが使用されていないことを意味します。これは、指定された構造が実際には未使用のディレクトリエントリであることを意味します

  • 1。指定されたディレクトリ エントリが使用中であることを意味します。これは、指定された構造が通常のディレクトリ エントリであることを意味します

6.2.2 FirstCluster フィールド

FirstCluster フィールドには、指定されたディレクトリ エントリに関連付けられているクラスター ヒープ内の割り当ての最初のクラスターのインデックスが含まれている必要があります。

このフィールドの有効な値の範囲は次のようになります。

  • 正確に 0。つまり、クラスターの割り当てが存在しません

  • 有効なクラスター インデックスの範囲である、2 と ClusterCount + 1 の間

クラスターの割り当てが派生構造と互換性がない場合、このテンプレートから派生した構造体は、FirstCluster フィールドと DataLength フィールドの両方を再定義できます。

6.2.3 DataLength フィールド

DataLength フィールドは、関連付けられたクラスター割り当てに含まれるデータのサイズ (バイト単位) を示します。

このフィールドの有効な値の範囲は次のとおりです。

  • 少なくとも 0。FirstCluster フィールドに値 0 が含まれている場合、このフィールドの有効な値は 0 のみです。

  • 最大 ClusterCount * 2SectorsPerClusterShift* 2BytesPerSectorShift

このテンプレートから派生する構造体は、派生構造に対してクラスターの割り当てが不可能な場合、FirstCluster フィールドと DataLength フィールドの両方を再定義できます。

6.3 汎用プライマリ DirectoryEntry テンプレート

ディレクトリー項目セット内の最初のディレクトリー項目は、1 次ディレクトリー項目でなければなりません。 ディレクトリ エントリ セット内の後続のすべてのディレクトリ エントリ (存在する場合) は、セカンダリ ディレクトリ エントリである必要があります ( セクション 6.4 を参照)。

汎用プライマリ DirectoryEntry テンプレートを解釈する機能は必須です。

すべてのプライマリ ディレクトリ エントリ構造は、Generic Primary DirectoryEntry テンプレート ( 表 16 を参照) から派生します。これは Generic DirectoryEntry テンプレートから派生します ( セクション 6.2 を参照)。

表 16 汎用プライマリ DirectoryEntry テンプレート

フィールド名

Offset

(バイト)

[サイズ]

(バイト)

 コメント
EntryType 0 1 このフィールドは必須であり、 セクション6.3.1 はその内容を定義します。
SecondaryCount 1 1 このフィールドは必須であり、 セクション6.3.2 はその内容を定義します。
SetChecksum 2 2 このフィールドは必須であり、 セクション6.3.3 はその内容を定義します。
GeneralPrimaryFlags 4 2 このフィールドは必須であり、 セクション6.3.4 はその内容を定義します。
CustomDefined 6 14 このフィールドは必須であり、このテンプレートから派生する構造体は、その内容を定義します。
FirstCluster 20 4 このフィールドは必須であり、 セクション6.3.5 はその内容を定義します。
DataLength 24 8 このフィールドは必須であり、 セクション6.3.6 はその内容を定義します。

6.3.1 EntryType フィールド

EntryType フィールドは、Generic DirectoryEntry テンプレートで提供される定義に準拠するものとします ( セクション 6.2.1 を参照)。

6.3.1.1 TypeCode フィールド

TypeCode フィールドは、Generic DirectoryEntry テンプレートで提供される定義に準拠するものとします ( セクション 6.2.1.1 を参照)。

6.3.1.2 TypeImportance フィールド

TypeImportance フィールドは、Generic DirectoryEntry テンプレートで提供される定義に準拠する必要があります ( セクション 6.2.1.2 を参照)。

6.3.1.2.1 重要なプライマリ ディレクトリ エントリ

重要なプライマリ ディレクトリ エントリには、exFAT ボリュームの適切な管理に不可欠な情報が含まれています。 ルート ディレクトリにのみ重要なプライマリ ディレクトリ エントリが含まれています (ファイル ディレクトリ エントリは例外です。 セクション 7.4 を参照)。

重要なプライマリ ディレクトリ エントリの定義は、主要な exFAT リビジョン番号に関連付けられます。 実装では、すべての重要なプライマリ ディレクトリ エントリがサポートされ、この仕様で定義されている重要なプライマリ ディレクトリ エントリ構造のみを記録する必要があります。

6.3.1.2.2 良性のプライマリ ディレクトリ エントリ

無害なプライマリ ディレクトリ エントリには、exFAT ボリュームの管理に役立つ可能性のある追加情報が含まれています。 任意のディレクトリに、無害なプライマリ ディレクトリ エントリが含まれている可能性があります。

無害なプライマリ ディレクトリ エントリの定義は、マイナー exFAT リビジョン番号に関連付けられます。 この仕様またはそれ以降の仕様で定義される無害なプライマリ ディレクトリ エントリのサポートは省略可能です。 認識されない無害なプライマリ ディレクトリ エントリでは、ディレクトリ エントリ セット全体が認識されない (該当するディレクトリ エントリ テンプレートの定義を超えて) レンダリングされます。

6.3.1.3 TypeCategory フィールド

TypeCategory フィールドは、Generic DirectoryEntry テンプレートで提供されている定義に準拠する必要があります ( セクション 6.2.1.3 を参照)。

このテンプレートの場合、このフィールドの有効な値は 0 になります。

6.3.1.4 InUse フィールド

InUse フィールドは、汎用 DirectoryEntry テンプレートで指定されている定義に準拠している必要があります ( セクション 6.2.1.4 を参照)。

6.3.2 SecondaryCount フィールド

SecondaryCount フィールドは、指定されたプライマリ ディレクトリ エントリの直後にあるセカンダリ ディレクトリ エントリの数を記述する必要があります。 これらのセカンダリ ディレクトリ エントリは、指定されたプライマリ ディレクトリ エントリと共に、ディレクトリ エントリ セットで構成されます。

このフィールドの有効な値の範囲は次のようになります。

  • 少なくとも 0。これは、このプライマリ ディレクトリ エントリがディレクトリ エントリ セット内の唯一のエントリであることを意味します

  • 最大 255 個。つまり、次の 255 個のディレクトリ エントリとこのプライマリ ディレクトリ エントリがディレクトリ エントリ セットで構成されます

このテンプレートから派生する重要なプライマリ ディレクトリエントリ構造は、SecondaryCount フィールドと SetChecksum フィールドの両方を再定義できます。

6.3.3 SetChecksum フィールド

SetChecksum フィールドには、指定されたディレクトリ エントリ セット内のすべてのディレクトリ エントリのチェックサムが含まれている必要があります。 ただし、チェックサムではこのフィールドは除外されます ( 図 2 を参照)。 実装では、指定されたディレクトリ エントリ セット内の他のディレクトリ エントリを使用する前に、このフィールドの内容が有効であることを確認する必要があります。

このテンプレートから派生する重要なプライマリ ディレクトリエントリ構造は、SecondaryCount フィールドと SetChecksum フィールドの両方を再定義できます。

図 2 EntrySetChecksum の計算

UInt16 EntrySetChecksum
(
    UCHAR * Entries,       // points to an in-memory copy of the directory entry set
    UCHAR   SecondaryCount
)
{
    UInt16 NumberOfBytes = ((UInt16)SecondaryCount + 1) * 32;
    UInt16 Checksum = 0;
    UInt16 Index;

    for (Index = 0; Index < NumberOfBytes; Index++)
    {
        if ((Index == 2) || (Index == 3))
        {
            continue;
        }
        Checksum = ((Checksum&1) ? 0x8000 : 0) + (Checksum>>1) +  (UInt16)Entries[Index];
    }
    return Checksum;
}

6.3.4 GeneralPrimaryFlags フィールド

GeneralPrimaryFlags フィールドにはフラグが含まれています ( 表 17 を参照)。

このテンプレートから派生する重要なプライマリ ディレクトリ エントリ構造によって、このフィールドが再定義される可能性があります。

表 17 汎用 GeneralPrimaryFlags フィールド構造体

フィールド名

Offset

(ビット)

[サイズ]

(ビット)

 コメント
AllocationPossible 0 1 このフィールドは必須であり、 セクション 6.3.4.1 ではその内容を定義します。
NoFatChain 1 1 このフィールドは必須であり、 セクション 6.3.4.2 ではその内容を定義します。
CustomDefined 2 14 このフィールドは必須であり、このテンプレートから派生する構造でこのフィールドを定義できます。
6.3.4.1 AllocationPossible フィールド

AllocationPossible フィールドは、指定されたディレクトリ エントリに対してクラスター ヒープ内の割り当てが可能かどうかを示す必要があります。

このフィールドの有効な値は次のようになります。

  • 0 は、クラスターの関連付けられた割り当てが不可能であり、FirstCluster フィールドと DataLength フィールドが実際には未定義であることを意味します (このテンプレートから派生した構造体はこれらのフィールドを再定義する可能性があります)。

  • 1 は、クラスターの関連付けられた割り当てが可能であり、FirstCluster フィールドと DataLength フィールドが定義されているとおりであることを意味します。

6.3.4.2 NoFatChain フィールド

NoFatChain フィールドは、アクティブな FAT が特定の割り当てのクラスター チェーンを記述しているかどうかを示す必要があります。

このフィールドの有効な値は次のようになります。

  • 0 は、割り当てのクラスター チェーンに対応する FAT エントリが有効であり、実装がそれらを解釈することを意味します。AllocationPossible フィールドに値 0 が含まれている場合、または AllocationPossible フィールドに値 1 が含まれており、FirstCluster フィールドに値 0 が含まれている場合、このフィールドの有効な値は 0 のみです。

  • 1 は、関連付けられた割り当てが 1 つの連続した一連のクラスターであることを意味します。クラスターの対応する FAT エントリは無効であり、実装ではそれらを解釈しません。実装では、関連する割り当てのサイズを計算するために次の式を使用できます。DataLength / (2SectorsPerClusterShift* 2BytesPerSectorShift) は、最も近い整数に切り上げられます

このテンプレートから派生した重要なプライマリ ディレクトリ エントリ構造が GeneralPrimaryFlags フィールドを再定義する場合、関連付けられている割り当てのクラスター チェーンに対応する FAT エントリが有効になります。

6.3.5 FirstCluster フィールド

FirstCluster フィールドは、汎用 DirectoryEntry テンプレートで指定された定義に準拠する必要があります ( セクション 6.2.2 を参照)。

NoFatChain ビットが 1 の場合、FirstCluster はクラスター ヒープ内の有効なクラスターを指す必要があります。

このテンプレートから派生する重要なプライマリ ディレクトリ エントリ構造は、FirstCluster フィールドと DataLength フィールドを再定義できます。 このテンプレートから派生する他の構造体では、AllocationPossible フィールドに値 0 が含まれている場合にのみ、FirstCluster フィールドと DataLength フィールドを再定義できます。

6.3.6 DataLength フィールド

DataLength フィールドは、汎用 DirectoryEntry テンプレートで指定された定義に準拠する必要があります ( セクション 6.2.3 を参照)。

NoFatChain ビットが 1 の場合、DataLength は 0 にすることはできません。 FirstCluster フィールドが 0 の場合、DataLength も 0 である必要があります。

このテンプレートから派生する重要なプライマリ ディレクトリ エントリ構造は、FirstCluster フィールドと DataLength フィールドを再定義できます。 このテンプレートから派生する他の構造体では、AllocationPossible フィールドに値 0 が含まれている場合にのみ、FirstCluster フィールドと DataLength フィールドを再定義できます。

6.4 汎用セカンダリ ディレクトリエントリ テンプレート

セカンダリ ディレクトリ エントリの中心的な目的は、ディレクトリ エントリ セットに関する追加情報を提供することです。 汎用セカンダリ DirectoryEntry テンプレートを解釈する機能は必須です。

重要なセカンダリ ディレクトリ エントリと無害なセカンダリ ディレクトリ エントリの両方の定義は、マイナー exFAT リビジョン番号に関連付けられます。 この仕様または後続の仕様で定義されている、重要または無害なセカンダリ ディレクトリ エントリのサポートは省略可能です。

すべてのセカンダリ ディレクトリ エントリ構造は、汎用セカンダリ DirectoryEntry テンプレート ( 表 18 を参照) から派生します。これは、汎用 DirectoryEntry テンプレートから派生します ( セクション 6.2 を参照)。

表 18 汎用セカンダリ DirectoryEntry テンプレート

フィールド名

Offset

(バイト)

[サイズ]

(バイト)

 コメント
EntryType 0 1 このフィールドは必須であり、 セクション 6.4.1 ではその内容を定義します。
GeneralSecondaryFlags 1 1 このフィールドは必須であり、 セクション 6.4.2 ではその内容が定義されています。
CustomDefined 2 18 このフィールドは必須であり、このテンプレートから派生する構造体は、その内容を定義します。
FirstCluster 20 4 このフィールドは必須であり、 セクション 6.4.3 ではその内容を定義します。
DataLength 24 8 このフィールドは必須であり、 セクション 6.4.4 ではその内容を定義します。

6.4.1 EntryType フィールド

EntryType フィールドは、汎用 DirectoryEntry テンプレートで指定された定義に準拠する必要があります ( セクション 6.2.1 を参照)

6.4.1.1 TypeCode フィールド

TypeCode フィールドは、汎用 DirectoryEntry テンプレートで指定された定義に準拠している必要があります ( セクション 6.2.1.1 を参照)。

6.4.1.2 TypeImportance フィールド

TypeImportance フィールドは、汎用 DirectoryEntry テンプレートで指定された定義に準拠している必要があります ( セクション 6.2.1.2 を参照)。

6.4.1.2.1 重要なセカンダリ ディレクトリ エントリ

重要なセカンダリ ディレクトリ エントリには、含まれるディレクトリ エントリ セットの適切な管理に不可欠な情報が含まれています。 特定の重要なセカンダリ ディレクトリ エントリのサポートは省略可能ですが、認識されないクリティカル ディレクトリ エントリでは、ディレクトリ エントリ セット全体が認識されない (該当するディレクトリ エントリ テンプレートの定義を超えて) レンダリングされます。

ただし、ディレクトリ エントリ セットに、実装で認識されない重要なセカンダリ ディレクトリ エントリが少なくとも 1 つ含まれている場合、実装は、ディレクトリ エントリ セット内のディレクトリ エントリのテンプレートを解釈し、ディレクトリ エントリ セット内のディレクトリ エントリに関連付けられているすべての割り当てに含まれるデータを解釈しません (ファイル ディレクトリ エントリは例外です。 セクション 7.4 を参照)。

6.4.1.2.2 良性のセカンダリ ディレクトリ エントリ

無害なセカンダリ ディレクトリ エントリには追加情報が含まれており、その情報が含まれているディレクトリ エントリ セットを管理するのに役立つ場合があります。 特定の無害なセカンダリ ディレクトリ エントリのサポートは省略可能です。 認識されない無害なセカンダリ ディレクトリ エントリでは、ディレクトリ エントリ セット全体が認識されないと表示されません。

実装では、認識されない無害なセカンダリ エントリが無視される場合があります。

6.4.1.3 TypeCategory フィールド

TypeCategory フィールドは、Generic DirectoryEntry テンプレートで提供されている定義に準拠する必要があります ( セクション 6.2.1.3 を参照)。

このテンプレートの場合、このフィールドの有効な値は 1 です。

6.4.1.4 InUse フィールド

InUse フィールドは、Generic DirectoryEntry テンプレートで提供されている定義に準拠するものとします ( セクション 6.2.1.4 を参照)。

6.4.2 GeneralSecondaryFlags フィールド

GeneralSecondaryFlags フィールドにはフラグが含まれています ( 表 19 を参照)。

表 19 ジェネリック GeneralSecondaryFlags フィールド構造体

フィールド名

Offset

(ビット)

[サイズ]

(ビット)

 コメント
AllocationPossible 0 1 このフィールドは必須であり、 セクション6.4.2.1 はその内容を定義します。
NoFatChain 1 1 このフィールドは必須であり、 セクション6.4.2.2 はその内容を定義します。
CustomDefined 2 6 このフィールドは必須であり、このテンプレートから派生する構造体はこのフィールドを定義できます。
6.4.2.1 AllocationPossible フィールド

AllocationPossible フィールドは、Generic Primary DirectoryEntry テンプレート内の同じ名前のフィールドと同じ定義を持つ必要があります ( セクション 6.3.4.1 を参照)。

6.4.2.2 NoFatChain フィールド

NoFatChain フィールドは、Generic Primary DirectoryEntry テンプレート内の同じ名前のフィールドと同じ定義を持つものとします ( セクション 6.3.4.2 を参照)。

6.4.3 FirstCluster フィールド

FirstCluster フィールドは、Generic DirectoryEntry テンプレートで提供される定義に準拠する必要があります ( セクション 6.2.2 を参照)。

NoFatChain ビットが 1 の場合、FirstCluster はクラスター ヒープ内の有効なクラスターを指す必要があります。

6.4.4 DataLength フィールド

DataLength フィールドは、Generic DirectoryEntry テンプレートで提供されている定義に準拠する必要があります ( セクション 6.2.3 を参照)。

NoFatChain ビットが 1 の場合、DataLength は 0 にすることはできません。 FirstCluster フィールドが 0 の場合、DataLength も 0 である必要があります。

7 ディレクトリ エントリの定義

exFAT ファイル システムのリビジョン 1.00 では、次のディレクトリ エントリが定義されています。

7.1 割り当てビットマップディレクトリエントリ

exFAT ファイル システムでは、FAT ではクラスターの割り当て状態は記述されません。ではなく、割り当てビットマップが行います。 割り当てビットマップはクラスター ヒープに存在し ( セクション 7.1.5 を参照)、ルート ディレクトリに対応する重要なプライマリ ディレクトリ エントリがあります ( 表 20 を参照)。

NumberOfFats フィールドは、ルート ディレクトリ内の有効な割り当てビットマップ ディレクトリ エントリの数を決定します。 NumberOfFats フィールドに値 1 が含まれている場合、割り当てビットマップ ディレクトリ エントリの有効な数は 1 のみです。 さらに、1 つの割り当てビットマップ ディレクトリ エントリは、最初の割り当てビットマップを記述している場合にのみ有効です ( セクション 7.1.2.1 を参照)。 NumberOfFats フィールドに値 2 が含まれている場合、割り当てビットマップ ディレクトリ エントリの有効な数は 2 のみです。 また、2 つの割り当てビットマップ ディレクトリ エントリは、一方が最初の割り当てビットマップを記述し、もう一方が第 2 の割り当てビットマップを記述する場合にのみ有効です。

表 20 ビットマップディレクトリエントリ構造の割り当て

フィールド名

Offset

(バイト)

[サイズ]

(バイト)

 コメント
EntryType 0 1 このフィールドは必須であり、 セクション7.1.1 はその内容を定義します。
BitmapFlags 1 1 このフィールドは必須であり、 セクション7.1.2 はその内容を定義します。
予約されています。 2 18 このフィールドは必須であり、その内容は予約されています。
FirstCluster 20 4 このフィールドは必須であり、 セクション7.1.3 はその内容を定義します。
DataLength 24 8 このフィールドは必須であり、 セクション7.1.4 はその内容を定義します。

7.1.1 EntryType フィールド

EntryType フィールドは、汎用プライマリ DirectoryEntry テンプレートで提供される定義に準拠する必要があります ( セクション 6.3.1 を参照)。

7.1.1.1 TypeCode フィールド

TypeCode フィールドは、汎用プライマリ DirectoryEntry テンプレートで提供される定義に準拠するものとします ( セクション 6.3.1.1 を参照)。

割り当てビットマップ ディレクトリ エントリの場合、このフィールドの有効な値は 1 です。

7.1.1.2 TypeImportance フィールド

TypeImportance フィールドは、汎用プライマリ DirectoryEntry テンプレートで提供される定義に準拠するものとします ( セクション 6.3.1.2 を参照)。

割り当てビットマップ ディレクトリ エントリの場合、このフィールドの有効な値は 0 です。

7.1.1.3 TypeCategory フィールド

TypeCategory フィールドは、汎用プライマリ DirectoryEntry テンプレートで提供される定義に準拠するものとします ( セクション 6.3.1.3 を参照)。

7.1.1.4 InUse フィールド

InUse フィールドは、汎用プライマリ DirectoryEntry テンプレートで提供される定義に準拠するものとします ( セクション 6.3.1.4 を参照)。

7.1.2 BitmapFlags フィールド

BitmapFlags フィールドにはフラグが含まれています ( 表 21 を参照)。

表 21 BitmapFlags フィールド構造

フィールド名

Offset

(ビット)

[サイズ]

(ビット)

 コメント
BitmapIdentifier 0 1 このフィールドは必須であり、 セクション 7.1.2.1 ではその内容が定義されています。
予約済み 1 7 このフィールドは必須であり、その内容は予約されています。
7.1.2.1 BitmapIdentifier フィールド

BitmapIdentifier フィールドは、指定されたディレクトリ エントリが記述する割り当てビットマップを示す必要があります。 実装では、最初の割り当てビットマップを最初の FAT と組み合わせて使用し、2 番目の FAT と組み合わせて 2 番目の割り当てビットマップを使用する必要があります。 ActiveFat フィールドには、アクティブな FAT と割り当てビットマップが記述されています。

このフィールドの有効な値は次のようになります。

  • 0 は、指定されたディレクトリ エントリが最初の割り当てビットマップを記述します。

  • 1 は、指定されたディレクトリ エントリが 2 番目の割り当てビットマップを記述し、NumberOfFats に値 2 が含まれている場合にのみ可能であることを意味します。

7.1.3 FirstCluster フィールド

FirstCluster フィールドは、汎用プライマリ DirectoryEntry テンプレートで提供される定義に準拠する必要があります ( セクション 6.3.5 を参照)。

このフィールドには、割り当てビットマップをホストする FAT が説明するように、クラスター チェーンの最初のクラスターのインデックスが含まれています。

7.1.4 DataLength フィールド

DataCluster フィールドは、汎用プライマリ DirectoryEntry テンプレートで提供される定義に準拠する必要があります ( セクション 6.3.6 を参照)。

7.1.5 割り当てビットマップ

割り当てビットマップは、クラスター ヒープ内のクラスターの割り当て状態を記録します。 割り当てビットマップ内の各ビットは、対応するクラスターが割り当てに使用できるかどうかを示します。

割り当てビットマップは、最下位から最上位のインデックスまでのクラスターを表します ( 表 22 を参照)。 履歴上の理由から、最初のクラスターにはインデックス 2 があります。 注: ビットマップの最初のビットは、最初のバイトの最下位ビットです。

表 22 ビットマップの割り当て構造

フィールド名

Offset

(ビット)

[サイズ]

(ビット)

 コメント
BitmapEntry[2] 0 1 このフィールドは必須であり、 セクション7.1.5.1 ではその内容を定義します。

.

.

.

.

.

.

.

.

.

.

.

.
BitmapEntry[ClusterCount+1] ClusterCount - 1 1

このフィールドは必須であり、 セクション7.1.5.1 はその内容を定義します。

注: メイン ブート セクターとバックアップ ブート セクターの両方に ClusterCount フィールドが含まれています。
予約済み ClusterCount (DataLength * 8) – ClusterCount

このフィールドは必須であり、その内容 (存在する場合) は予約されています。

注: メイン ブート セクターとバックアップ ブート セクターの両方に ClusterCount フィールドが含まれています。
7.1.5.1 BitmapEntry[2] ...BitmapEntry[ClusterCount+1] フィールド

この配列の各 BitmapEntry フィールドは、クラスター ヒープ内のクラスターを表します。 BitmapEntry[2] はクラスター ヒープ内の最初のクラスターを表し、[ClusterCount+1] はクラスター ヒープ内の最後のクラスターを表します。

これらのフィールドの有効な値は次のようになります。

  • 割り当て可能な対応するクラスターを表す 0

  • 1:対応するクラスターを割り当てに使用できないと記述します (クラスター割り当てで対応するクラスターが既に使用されているか、アクティブな FAT が対応するクラスターを不適切と記述している可能性があります)

7.2 アップケーステーブルディレクトリエントリ

Up-case Table では、小文字から大文字への変換が定義されています。 これは、Unicode 文字を使用するファイル名ディレクトリ エントリ (セクション 7.7 を参照) と exFAT ファイル システムで大文字と小文字が区別されず、大文字と小文字が保持されるために重要です。 Up-case テーブルはクラスター ヒープに存在し ( セクション 7.2.5 を参照)、ルート ディレクトリに対応する重要なプライマリ ディレクトリ エントリがあります ( 表 23 を参照)。 Up-case Table ディレクトリ エントリの有効な数は 1 です。

Up-case テーブルとファイル名の関係により、実装では、書式操作の結果を除き、アップケース テーブルを変更しないでください。

表 23 Up-case Table DirectoryEntry 構造体

フィールド名

Offset

(バイト)

[サイズ]

(バイト)

 コメント
EntryType 0 1 このフィールドは必須であり、 セクション7.2.1 はその内容を定義します。
Reserved1 1 3 このフィールドは必須であり、その内容は予約されています。
TableChecksum 4 4 このフィールドは必須であり、 セクション7.2.2 はその内容を定義します。
Reserved2 8 12 このフィールドは必須であり、その内容は予約されています。
FirstCluster 20 4 このフィールドは必須であり、 セクション 7.2.3 ではその内容が定義されています。
DataLength 24 8 このフィールドは必須であり、 セクション 7.2.4 ではその内容が定義されています。

7.2.1 EntryType フィールド

EntryType フィールドは、汎用プライマリ DirectoryEntry テンプレートで提供される定義に準拠する必要があります ( セクション 6.3.1 を参照)。

7.2.1.1 TypeCode フィールド

TypeCode フィールドは、汎用プライマリ DirectoryEntry テンプレートで提供される定義に準拠するものとします ( セクション 6.3.1.1 を参照)。

Up-case Table ディレクトリ エントリの場合、このフィールドの有効な値は 2 です。

7.2.1.2 TypeImportance フィールド

TypeImportance フィールドは、汎用プライマリ DirectoryEntry テンプレートで提供される定義に準拠するものとします ( セクション 6.3.1.2 を参照)。

Up-case Table ディレクトリ エントリの場合、このフィールドの有効な値は 0 です。

7.2.1.3 TypeCategory フィールド

TypeCategory フィールドは、汎用プライマリ DirectoryEntry テンプレートで提供される定義に準拠するものとします ( セクション 6.3.1.3 を参照)。

7.2.1.4 InUse フィールド

InUse フィールドは、汎用プライマリ DirectoryEntry テンプレートで提供される定義に準拠するものとします ( セクション 6.3.1.4 を参照)。

7.2.2 TableChecksum フィールド

TableChecksum フィールドには、Up-case テーブルのチェックサムが含まれています (FirstCluster フィールドと DataLength フィールドで説明されています)。 実装では、アップケース テーブルを使用する前に、このフィールドの内容が有効であることを確認する必要があります。

図 3 TableChecksum の計算

UInt32 TableChecksum
(
    UCHAR  * Table,    // points to an in-memory copy of the up-case table
    UInt64   DataLength
)
{
    UInt32 Checksum = 0;
    UInt64 Index;

    for (Index = 0; Index < DataLength; Index++)
    {
        Checksum = ((Checksum&1) ? 0x80000000 : 0) + (Checksum>>1) + (UInt32)Table[Index];
    }

    return Checksum;
}

7.2.3 FirstCluster フィールド

FirstCluster フィールドは、汎用プライマリ DirectoryEntry テンプレートで提供される定義に準拠する必要があります ( セクション 6.3.5 を参照)。

このフィールドには、UP-case テーブルをホストする FAT が説明するように、クラスター チェーンの最初のクラスターのインデックスが含まれています。

7.2.4 DataLength フィールド

DataCluster フィールドは、汎用プライマリ DirectoryEntry テンプレートで提供される定義に準拠する必要があります ( セクション 6.3.6 を参照)。

7.2.5 アップケーステーブル

アップケース テーブルは、一連の Unicode 文字マッピングです。 文字マッピングは 2 バイトのフィールドで構成され、アップケース テーブルのフィールドのインデックスは、アップケースの Unicode 文字を表し、2 バイトのフィールドはアップケース Unicode 文字を表します。

最初の 128 個の Unicode 文字には、必須のマッピングがあります ( 表 24 を参照)。 最初の 128 個の Unicode 文字のいずれかに対して他の文字マッピングがある大文字と小文字のテーブルは無効です。

必須マッピング範囲の文字のみをサポートする実装では、アップケース テーブルの残りの部分のマッピングが無視される場合があります。 このような実装では、ファイルを作成または名前変更するときに、必須のマッピング範囲の文字のみを使用します (ファイル名ディレクトリエントリを介して、 セクション 7.7 を参照)。 既存のファイル名の大文字と小文字を区別する場合、このような実装では、非必須マッピング範囲の大文字と小文字は区別されませんが、結果として生成されるアップケースファイル名にはそのまま残す必要があります (これは部分的な大文字と小文字です)。 ファイル名を比較する場合、このような実装では、比較対象の名前と異なるファイル名は、非必須マッピング範囲の Unicode 文字によってのみ同等として扱う必要があります。 このようなファイル名は同等である可能性はありますが、このような実装では、完全に大文字と小文字が区別されたファイル名が比較対象の名前と競合しないようにすることはできません。

表 24 必須の最初の 128 個のアップケース テーブル エントリ

テーブル インデックス + 0 + 1 + 2 + 3 + 4 + 5 + 6 + 7
0000h 0000h 0001h 0002h 0003h 0004h 0005h 0006h 0007h
0008h 0008h 0009h 000Ah 000Bh 000Ch 000Dh 000Eh 000Fh
0010h 0010h 0011h 0012h 0013h 0014h 0015h 0016h 0017h
0018h 0018h 0019h 001Ah 001Bh 001Ch 001Dh 001Eh 001Fh
0020h 0020h 0021h 0022h 0023h 0024h 0025h 0026h 0027h
0028h 0028h 0029h 002Ah 002Bh 002Ch 002Dh 002Eh 002Fh
0030h 0030h 0031h 0032h 0033h 0034h 0035h 0036h 0037h
0038h 0038h 0039h 003Ah 003Bh 003Ch 003Dh 003Eh 003Fh
0040h 0040h 0041h 0042h 0043h 0044h 0045h 0046h 0047h
0048h 0048h 0049h 004Ah 004Bh 004Ch 004Dh 004Eh 004Fh
0050h 0050h 0051h 0052h 0053h 0054h 0055h 0056h 0057h
0058h 0058h 0059h 005Ah 005Bh 005Ch 005Dh 005Eh 005Fh
0060h 0060h 0041h 0042h 0043h 0044h 0045h 0046h 0047h
0068h 0048h 0049h 004Ah 004Bh 004Ch 004Dh 004Eh 004Fh
0070h 0050h 0051h 0052h 0053h 0054h 0055h 0056h 0057h
0078h 0058h 0059h 005Ah 007Bh 007Ch 007Dh 007Eh 007Fh

(注: ID 以外の大文字と小文字のマッピングを持つエントリは太字で表示されます)

Unicode 文字空間の大部分には大文字と小文字の概念がないため、ボリュームを書式設定すると、実装によって、ID マッピング圧縮を使用して圧縮形式のアップケース テーブルが生成される場合があります (つまり、"小文字" と "大文字" の文字は同等です)。 実装では、一連の ID マッピングを FFFFh 値に続けて ID マッピングの数と共に表すことによって、アップケース テーブルを圧縮します。

たとえば、実装は、最初の 100 (64h) 文字マッピングを表し、圧縮されたアップケース テーブルの次の 8 つのエントリを表します。

FFFFh, 0061h, 0041h, 0042h, 0043h

最初の 2 つのエントリは、最初の 97 (61h) 文字 (0000h から 0060h) に ID マッピングがあることを示します。 後続の文字 (0061h ~ 0063h) は、それぞれ 0041h ~ 0043h の文字にマップされます。

ボリュームの書式設定時に、圧縮された大文字と小文字を区別するテーブルを提供する機能は省略可能です。 ただし、圧縮されていないテーブルと圧縮されたアップケース テーブルの両方を解釈する機能は必須です。 TableChecksum フィールドの値は、ボリューム上にアップケース テーブルが存在する方法に常に準拠します。これは、圧縮形式または非圧縮形式のいずれかになります。

ボリュームをフォーマットする場合、実装では、推奨されるアップケース テーブルを圧縮形式で記録する必要があります ( 表 25 を参照)。TableChecksum フィールドの値は E619D30Dh です。

実装で独自のアップケース テーブル (圧縮または非圧縮) が定義されている場合、そのテーブルは完全な Unicode 文字範囲 (文字コード 0000h から FFFFh を含む) をカバーする必要があります。