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 特定の用語

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

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

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

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

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

  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 ではその内容が定義されます (存在する場合)。

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

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

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

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

注: メイン ブート セクターとバックアップ ブート セクターには、どちらも ClusterHeapOffset、ClusterCount、および SectorsPerClusterShift フィールドが含まれています。
余分な領域 ClusterHeapOffset + ClusterCount * 2セクターPerClusterShift 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 が "ジャンプ" され、BootCode フィールドでブート ストラップ命令が実行されます。

このフィールドの有効な値は、(下位バイトから上位バイトの順) 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 ボリュームのサイズを記述する必要があります。

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

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

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

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

3.1.6 FatOffset フィールド

FatOffset フィールドは、First 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 を参照)。

実装では、それぞれのメイン ブートまたはバックアップ ブート領域のチェックサムを計算するときに、このフィールドを含めないようにします。 バックアップ ブート セクターを参照する場合、実装では、このフィールドを古いものとして扱う必要があります。

表 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 セクターPerClusterShift フィールド

[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 に変更する必要があります。

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

3.1.19 BootCode フィールド

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

3.1.20 BootSignature フィールド

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

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

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

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

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

Main または Backup の拡張ブート セクターの命令を実行する前に、各セクターの ExtendedBootSignature フィールドに指定された値が含まれていることを確認することで、実装で内容を確認する必要があります。

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

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

フィールド名

Offset

(バイト)

[サイズ]

(バイト)

 コメント
ExtendedBootCode 0 2BytesPerSectorShift – 4

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

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

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

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

3.2.1 ExtendedBootCode フィールド

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

3.2.2 ExtendedBootSignature フィールド

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

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

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

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

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

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

製造元は、Main パラメーターと Backup OEM パラメーターに独自のカスタム パラメーター構造 (存在する場合) とその他のパラメーター構造を設定する必要があります。 後続のフォーマット操作では、Main パラメーターと Backup 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 を記述する必要があります。

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

3.3.3 Null パラメーター

Null Parameters 構造体は、ジェネリック パラメーター テンプレートから派生し ( セクション 3.3.2 を参照)、未使用の Parameters フィールドを記述する必要があります ( 表 9 を参照)。 OEM Parameters 構造体を作成または更新する場合、実装では、使用されていない Parameters フィールドに Null Parameters 構造体を設定する必要があります。 また、OEM Parameters 構造体を作成または更新する場合、実装では、配列の末尾に Null Parameters 構造体を統合し、OEM Parameters 構造体の先頭に他のすべての 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 フィールド (好ましくは 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 Parameters フィールドで使用可能なすべての値が有効です。 ただし、値 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) 領域には、最初の FAT サブリージョンと 2 番目の FAT サブリージョンの 1 つを含む最大 2 つの FAT が含まれる場合があります。 NumberOfFats フィールドには、このリージョンに含まれる FAT の数が示されます。 NumberOfFats フィールドの有効な値は 1 と 2 です。 したがって、最初の FAT サブ領域には常に FAT が含まれます。 NumberOfFats フィールドが 2 の場合、2 番目の FAT サブリージョンにも FAT が含まれます。

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

4.1 1 番目と 2 番目の FAT サブリージョン

FAT では、クラスター ヒープ内のクラスター チェーンについて説明する必要があります ( 表 11 を参照)。 クラスター チェーンは、ファイル、ディレクトリ、およびその他のファイル システム構造の内容を記録するための領域を提供する一連のクラスターです。 FAT は、クラスター チェーンをクラスター インデックスの 1 つのリンクされたリストとして表します。 最初の 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] はクラスター ヒープ内の最初のクラスターを表し、FatEntry[ClusterCount+1] はクラスター ヒープ内の最後のクラスターを表します。

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

  • 2 から ClusterCount + 1 の間(指定されたクラスター チェーン内の次の FatEntry を指す)指定された FatEntry は、指定されたクラスター チェーン内のその前にある FatEntry を指すものではありません

  • 正確に FFFFFFF7h。指定された FatEntry の対応するクラスターを "無効" としてマークします

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

5 データ領域

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

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

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

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

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

フィールド名

Offset

(セクター)

[サイズ]

(セクター)

 コメント
Cluster[2] ClusterHeapOffset 2セクターPerClusterShift

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

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

.

.

.

.

.

.

.

.

.

.

.

.
Cluster[ClusterCount+1] ClusterHeapOffset + (ClusterCount – 1) * 2セクターPerClusterShift 2セクターPerClusterShift

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

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

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

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

6 ディレクトリ構造

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

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

各ディレクトリは、一連のディレクトリ エントリで構成されます ( 表 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 フィールドは、Generic DirectoryEntry テンプレートから派生します ( セクション 6.2 を参照)。

6.2 汎用ディレクトリエントリ テンプレート

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

表 14 汎用ディレクトリエントリ テンプレート

フィールド名

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 * 2セクターPerClusterShift* 2BytesPerSectorShift

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

6.3 汎用プライマリ ディレクトリエントリ テンプレート

ディレクトリ エントリ セット内の最初のディレクトリ エントリは、プライマリ ディレクトリ エントリである必要があります。 ディレクトリ エントリ セット内の後続のすべてのディレクトリ エントリ (存在する場合) は、セカンダリ ディレクトリ エントリである必要があります ( セクション 6.4 を参照)。

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

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

表 16 汎用プライマリ ディレクトリエントリ テンプレート

フィールド名

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 フィールドは、Generic 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 フィールドは、Generic DirectoryEntry テンプレートで提供される定義に準拠している必要があります ( セクション 6.2.2 を参照)。

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

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

6.3.6 DataLength フィールド

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

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

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

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

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

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

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

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

フィールド名

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 フィールドは、Generic DirectoryEntry テンプレートで提供される定義に準拠している必要があります ( セクション 6.2.1 を参照)

6.4.1.1 TypeCode フィールド

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

6.4.1.2 TypeImportance フィールド

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

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

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

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

6.4.1.2.2 無害なセカンダリ ディレクトリ エントリ

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

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

6.4.1.3 TypeCategory フィールド

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

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

6.4.1.4 InUse フィールド

InUse フィールドは、汎用 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 フィールドは、汎用 Primary DirectoryEntry テンプレートの同じ名前のフィールドと同じ定義を持つ必要があります ( セクション 6.3.4.1 を参照)。

6.4.2.2 NoFatChain フィールド

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

6.4.3 FirstCluster フィールド

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

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

6.4.4 DataLength フィールド

DataLength フィールドは、汎用 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 割り当てビットマップ ディレクトリEntry 構造体

フィールド名

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 フィールドは、汎用プライマリ ディレクトリEntry テンプレートで提供されている定義に準拠している必要があります ( セクション 6.3.1 を参照)。

7.1.1.1 TypeCode フィールド

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

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

7.1.1.2 TypeImportance フィールド

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

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

7.1.1.3 TypeCategory フィールド

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

7.1.1.4 InUse フィールド

InUse フィールドは、汎用プライマリ ディレクトリEntry テンプレートで提供されている定義に準拠している必要があります ( セクション 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 フィールドは、汎用プライマリ ディレクトリEntry テンプレートで提供される定義に準拠する必要があります ( セクション 6.3.5 を参照)。

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

7.1.4 DataLength フィールド

DataCluster フィールドは、汎用プライマリ ディレクトリEntry テンプレートで提供されている定義に準拠する必要があります ( セクション 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] はクラスター ヒープ内の最初のクラスターを表し、BitmapEntry[ClusterCount+1] はクラスター ヒープ内の最後のクラスターを表します。

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

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

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

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

Up-case Table は、小文字から大文字への変換を定義します。 これは、Unicode 文字を使用するファイル名ディレクトリ エントリ (セクション 7.7 を参照) と exFAT ファイル システムで大文字と小文字が区別されず、大文字と小文字が保持されるために重要です。 アップケース テーブルはクラスター ヒープに存在し ( セクション 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 フィールドは、汎用プライマリ ディレクトリEntry テンプレートで提供されている定義に準拠している必要があります ( セクション 6.3.1 を参照)。

7.2.1.1 TypeCode フィールド

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

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

7.2.1.2 TypeImportance フィールド

TypeImportance フィールドは、汎用プライマリ ディレクトリEntry テンプレートで提供される定義に準拠する必要があります ( セクション 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 フィールドは、汎用プライマリ ディレクトリEntry テンプレートで提供されている定義に準拠している必要があります ( セクション 6.3.1.4 を参照)。

7.2.2 TableChecksum フィールド

TableChecksum フィールドには、アップケース テーブル (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 フィールドは、汎用プライマリ ディレクトリEntry テンプレートで提供される定義に準拠する必要があります ( セクション 6.3.5 を参照)。

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

7.2.4 DataLength フィールド

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

7.2.5 アップケーステーブル

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

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

必須マッピング範囲の文字のみをサポートする実装では、アップケース テーブルの残りの部分のマッピングが無視される場合があります。 このような実装では、ファイルの作成時または名前変更時に、必須マッピング範囲の文字のみを使用する必要があります (ファイル名ディレクトリエントリを介して、 セクション 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 まで) をカバーする必要があります。