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

1 Introduction (はじめに)

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

1.1 設計目標

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

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

    FAT ベースのファイルシステムの長所の1つは、その相対的な簡略化と実装の容易さです。 その前に、実装者は比較的単純で実装が簡単な exFAT を見つける必要があります。

  2. 非常に大きなファイルと記憶装置を有効にします。

    ExFAT ファイルシステムでは、ファイルサイズを示すために64ビットが使用されているため、非常に大きなファイルに依存するアプリケーションが有効になります。 また、exFAT ファイルシステムでは、非常に大きな記憶装置を効果的に実現するために、32 MB のクラスターを使用できます。

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

    ExFAT ファイルシステムの設計には拡張性が組み込まれているため、ファイルシステムはストレージのイノベーションや使用状況の変化に対応できるようになります。

1.2 固有の用語

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

表1特定の意味を持つ用語の定義

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

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

  1. はゼロに初期化する必要があり、目的には使用できません

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

  3. 周囲のフィールドまたは構造を変更する操作をまたいで保持する必要がある

1.3 共通頭字語の完全なテキスト

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

表2共通頭字語の完全なテキスト

頭字語 [フルテキスト]
ASCII American Standard Code for Information Interchange
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つの FATs ビットマップとアロケーションビットマップを使用する必要があります。 また、埋め込み記述子やセキュリティ記述子など、いくつかの追加の構造も定義されています。

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 Fat オフセット–24

このサブ領域は必須であり、その内容 (存在する場合) は未定義です。

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

最初の FAT Fat オフセット Fat の長さ

このサブ領域は必須であり、 セクション 4.1 はその内容を定義します。

注: メインおよびバックアップのブートセクターには、どちらにも、[Fat オフセット] フィールドと [Fat 長さ] フィールドが含まれています。

2番目の FAT Fat オフセット + Fat の長さ Fat の長さ * (Number Offats – 1)

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

注: メインおよびバックアップのブートセクターには、どちらにも、Fat オフセット、Fat の長さ、および数値 Offats の各フィールドが含まれています。 Number Offats フィールドには、値1と2しか保持できません。

データ領域
クラスターヒープのアラインメント Fat オフセット + Fat の長さ * 数値 Offats ClusterHeapOffset – (Fat オフセット + Fat の長さ * Number Offats)

このサブ領域は必須であり、その内容 (存在する場合) は未定義です。

注: メインおよびバックアップのブートセクターには、どちらにも、Fat オフセット、Fat の長さ、数字オフ、および ClusterHeapOffset の各フィールドが含まれています。 Number Offats フィールドの有効値は1と2です。

クラスターヒープ ClusterHeapOffset ClusterCount * 2SectorsPerClusterShift

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

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

超過領域 ClusterHeapOffset + ClusterCount * 2SectorsPerClusterShift VolumeLength – (ClusterHeapOffset + ClusterCount * 2SectorsPerClusterShift)

このサブ領域は必須であり、その内容 (存在する場合) は未定義です。

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

3メインおよびバックアップのブートリージョン

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

  1. ExFAT ボリュームからコンピューターシステムを起動します。

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

  3. ExFAT file システム構造の場所を検出します。

バックアップブートリージョンは、メインブートリージョンのバックアップです。 メインブートリージョンが不整合な状態にある場合に、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

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

注: Main ブート セクターと Backup ブート セクターの両方に 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 ボリュームのサイズを記述する必要があります。

このフィールドの有効な値の範囲は次の値である必要があります。

  • 少なくとも 220/ 2BytesPerSectorShift。これにより、最小ボリュームが 1 MB 以下になります。

  • 最大で 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) * 22/ 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 つのクラスターを推奨しています。 ただし、実装では、クラスター ヒープに最大 232から 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

(ビット)

[サイズ]

(bits)

コメント
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 です。

このフィールドの有効な値の範囲は次の値である必要があります。

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

  • 最大 12 (セクター サイズは 4,096 バイト)、これはパーソナル コンピューターで一般的な 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 に変更する必要があります。

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

3.1.19 BootCode フィールド

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

3.1.20 BootSignature フィールド

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

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

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

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

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

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

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

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

フィールド名

Offset

(byte)

[サイズ]

(バイト)

コメント
ExtendedBootCode 0 2BytesPerSectorShift – 4

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

注: Main ブート セクターと Backup ブート セクターの両方に BytesPerSectorShift フィールドが含まれます。

ExtendedBootSignature 2BytesPerSectorShift – 4 4

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

注: Main ブート セクターと Backup ブート セクターの両方に BytesPerSectorShift フィールドが含まれます。

3.2.1 ExtendedBootCode フィールド

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

3.2.2 ExtendedBootSignature フィールド

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

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

3.3 メインおよびバックアップ 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

(byte)

[サイズ]

(バイト)

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

.

.

.

.

.

.

.

.

.

.

.

.

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

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

注: Main ブート セクターと Backup ブート セクターの両方に BytesPerSectorShift フィールドが含まれます。

3.3.1 パラメーター [ 0 ] ...パラメーター [ 9]

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

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

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

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

フィールド名

Offset

(byte)

[サイズ]

(バイト)

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

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

表 9 null パラメーターの構造

フィールド名

Offset

(byte)

[サイズ]

(バイト)

コメント
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 パラメーター構造体はジェネリック パラメーター テンプレート (セクション3.3.2を参照) から派生し、フラッシュ メディアのパラメーターが含まれています (表10 を参照)。 フラッシュ ベースのストレージ デバイスの製造元は、このパラメーター構造を使用して Parameters フィールド (可能な場合は Parameters [ 0 フィールド ] ) を設定できます。 実装では、Flash Parameters 構造体の情報を使用して、読み取り/書き込み中のアクセス操作を最適化し、メディアの書式設定を行うファイル システム構造の配置を行う場合があります。

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

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

フィールド名

Offset

(byte)

[サイズ]

(バイト)

コメント
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 Main および Backup Boot Checksum サブリージョン

Main ブート チェックサムと Backup ブート チェックサムにはそれぞれ、それぞれのブート リージョン内の他のすべてのサブリージョンの内容の 4 バイトチェックサムの繰り返しパターンが含まれている。 チェックサム計算では、それぞれのブート セクターに VolumeFlags フィールドと PercentInUse フィールドを含め "(図 1 を参照)" を指定する必要があります。 4 バイトチェックサムの繰り返しパターンは、サブリージョンの先頭から末尾まで、それぞれのブート チェックサム サブリージョンを埋めるパターンです。

メイン またはバックアップ ブート のいずれかのリージョンの他のサブリージョンの内容を使用する前に、実装ではそれぞれのブート チェックサムを検証して内容を検証する必要があります。

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

図 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) 領域には、最大 2 つの FAT が含まれる場合があります。1 つは最初の FAT サブリージョンに、もう 1 つは 2 番目の FAT サブリージョンに含まれる場合があります。 NumberOfFats フィールドには、このリージョンに含まれる FAT の数が記述されます。 NumberOfFats フィールドの有効な値は 1 と 2 です。 したがって、最初の FAT サブリージョンには常に FAT が含まれている。 NumberOfFats フィールドが 2 の場合、2 番目の FAT サブリージョンにも FAT が含まれる。

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

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

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

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

フィールド名

Offset

(byte)

[サイズ]

(バイト)

コメント
FatEntry[0] 0 4 このフィールドは必須であり、 セクション 4.1.2 では その内容が定義されています。
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 を超えすることはできません。

注: Main ブート セクターと Backup ブート セクターの両方に ClusterCount フィールドが含まれている。

ExcessSpace (ClusterCount + 2) * 4 (FatLength * 2BytesPerSectorShift) – ((ClusterCount + 2) * 4)

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

注: Main ブート セクターと Backup ブート セクターの両方に、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 の対応するクラスターを "bad" としてマークします

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

5 データ領域

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

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

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

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

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

フィールド名

Offset

(セクター)

[サイズ]

(セクター)

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

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

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

.

.

.

.

.

.

.

.

.

.

.

.

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

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

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

5.1.1 クラスター [ 2 ] ...Cluster [ ClusterCount+1 ] フィールド

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

6 ディレクトリ構造

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

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

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

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

表 13 ディレクトリ構造

フィールド名

Offset

(byte)

[サイズ]

(byte)

コメント
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 汎用 DirectoryEntry テンプレート

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

表 14 汎用 DirectoryEntry テンプレート

フィールド名

Offset

(byte)

[サイズ]

(byte)

コメント
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

(ビット)

[サイズ]

(bits)

コメント
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 汎用プライマリ ディレクトリEntry テンプレート

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

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

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

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

フィールド名

Offset

(byte)

[サイズ]

(byte)

コメント
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 の一般 Primaryflags フィールド

一般 Primaryflags フィールドにはフラグが含まれています ( 表 17を参照してください)。

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

表17汎用汎用 Primaryflags フィールド構造

フィールド名

Offset

16-bit

[サイズ]

コメント
割り当て可能 0 1 このフィールドは必須であり、 セクション 6.3.4.1 によってその内容が定義されます。
Nofat チェーン 1 1 このフィールドは必須であり、 セクション 6.3.4.2 によってその内容が定義されます。
CustomDefined 2 14 このフィールドは必須です。このテンプレートから派生する構造体は、このフィールドを定義できます。
6.3.4.1 の使用可能なフィールド

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

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

  • 0の場合、関連付けられたクラスターの割り当ては不可能であり、FirstCluster および DataLength フィールドは実際には定義されていません (このテンプレートから派生する構造体は、これらのフィールドを再定義できます)。

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

6.3.4.2 Nofat チェーンフィールド

Nofat Chain フィールドは、アクティブな FAT が特定の割り当てのクラスターチェーンを説明しているかどうかを示します。

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

  • 0: 割り当てのクラスターチェーンに対応する FAT エントリが有効であり、実装によって解釈されることを意味します。[使用可能] フィールドに値0が含まれている場合、または [使用可能] フィールドに値1が含まれていて、[FirstCluster] フィールドに値0が含まれている場合、このフィールドの有効値は0です。

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

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

6.3.5 FirstCluster フィールド

FirstCluster フィールドは、汎用の DirectoryEntry テンプレートに用意されている定義に準拠している必要があります (「 6.2.2」セクションを参照してください)。

Nofat チェーンビットが1の場合、FirstCluster はクラスターヒープ内の有効なクラスターを参照する必要があります。

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

6.3.6 DataLength フィールド

DataLength フィールドは、汎用の DirectoryEntry テンプレートに用意されている定義に準拠している必要があります (「 6.2.3」セクションを参照してください)。

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

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

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

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

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

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

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

フィールド名

Offset

バイト

[サイズ]

バイト

コメント
EntryType 0 1 このフィールドは必須であり、セクション セクション 6.4.1 にその内容が定義されています。
全般の Secondaryflags 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 の型のフィールド

[単位] フィールドは、汎用の 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 フィールドは、汎用の DirectoryEntry テンプレートで提供されている定義に準拠している必要があります (「 6.2.1.3」を参照してください)。

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

6.4.1.4 InUse フィールド

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

6.4.2 の全般の Secondaryflags フィールド

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

表19一般全般 Secondaryflags フィールド構造

フィールド名

Offset

16-bit

[サイズ]

コメント
割り当て可能 0 1 このフィールドは必須であり、 セクション 6.4.2.1 によってその内容が定義されます。
Nofat チェーン 1 1 このフィールドは必須であり、 セクション 6.4.2.2 によってその内容が定義されます。
CustomDefined 2 6 このフィールドは必須です。このテンプレートから派生する構造体は、このフィールドを定義できます。
6.4.2.1 の使用可能なフィールド

使用可能なフィールドは、汎用プライマリ DirectoryEntry テンプレートで同じ名前を持つフィールドと同じ定義にする必要があります (「 6.3.4.1」セクションを参照してください)。

6.4.2.2 Nofat チェーンフィールド

Nofat チェーンフィールドは、汎用プライマリ DirectoryEntry テンプレートで同じ名前を持つフィールドと同じ定義である必要があります (「 6.3.4.2」セクションを参照してください)。

6.4.3 FirstCluster フィールド

FirstCluster フィールドは、汎用の DirectoryEntry テンプレートに用意されている定義に準拠している必要があります (「 6.2.2」セクションを参照してください)。

Nofat チェーンビットが1の場合、FirstCluster はクラスターヒープ内の有効なクラスターを参照する必要があります。

6.4.4 DataLength フィールド

DataLength フィールドは、汎用の DirectoryEntry テンプレートに用意されている定義に準拠している必要があります (「 6.2.3」セクションを参照してください)。

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

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

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

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

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

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

表20割り当てビットマップ DirectoryEntry 構造体

フィールド名

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 の型のフィールド

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

アロケーションビットマップディレクトリエントリの場合、このフィールドの有効な値は1です。

7.1.1.2 TypeImportance 度フィールド

TypeImportance DirectoryEntry テンプレートで提供されている定義には、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

16-bit

[サイズ]

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

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

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

  • 0: 指定されたディレクトリエントリが最初の割り当てビットマップを説明することを意味します。

  • 1 (指定されたディレクトリエントリで2番目の割り当てビットマップが記述されており、数値が含まれている場合にのみ可能です) 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

16-bit

[サイズ]

コメント
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 アップケーステーブルのディレクトリエントリ

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

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

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

7.2.1.1 TypeCode フィールド

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

[Up-case Table directory]/(アップケース テーブル ディレクトリ)エントリの場合、このフィールドの有効な値は です。 2.

7.2.1.2 TypeImportance フィールド

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

[Up-case Table directory]/(アップケース テーブル ディレクトリ)エントリの場合、このフィールドの有効な値は です。 0.

7.2.1.3 TypeCategory フィールド

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

7.2.1.4 InUse フィールド

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

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

7.2.4 DataLength フィールド

DataCluster フィールドは、Generic Primary 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 0042時間 0043h 0044時間 0045h 0046h 0047時間
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 0042時間 0043h 0044時間 0045h 0046h 0047時間
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 マッピング圧縮を使用して、圧縮形式でアップケーステーブルを生成する場合があります。 実装では、値 FFFFh に続けて id マッピングの数を指定して、一連の id マッピングを表すことによって、上位ケーステーブルを圧縮します。

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

FFFFh、0061h、0041h、0042 h、0041h

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

ボリュームのフォーマット時に、圧縮されたアップケーステーブルを提供する機能はオプションです。 ただし、圧縮されていないアップケーステーブルと圧縮されたアップケーステーブルの両方を解釈する機能は必須です。 TableChecksum フィールドの値は、常に、ボリューム上のアップケーステーブルが存在する方法に準拠しています。これは、圧縮形式または圧縮されていない形式のいずれかになります。

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

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