找回密码
 注册
查看: 25447|回复: 5

exFAT 深层介绍

[复制链接]
发表于 2009-2-22 07:33:04 | 显示全部楼层 |阅读模式
exFAT 構造解析

                                                        2008/06/27  K.Takata

1.初めに
 この文書では、Windows Vista SP1 と Windows CE 6.0 で新たに採用された
ファイルシステムである exFAT の構造を独自に解析した結果を示す。



2.仕様の概要
 exFAT の仕様の概要を示す。以下は、WinHEC 2006 のスライド [1] および、
MSDN の情報 [2,3] からの抜粋である。

・フラッシュメディア向けのファイルシステム
・32GB より大きなメディアに対応
・1つのディレクトリで千以上のファイルを扱える
・空きスペースビットマップ
  - 高速な領域割り当て、高速な削除
・ファイルサイズを 64bit で管理
・大きなクラスタサイズ(理論上の最大は 2^255、実装上の最大は 32MB)
・将来への拡張性
  - 柔軟で拡張可能なディレクトリ構造
  - 互換性を保ったまま機能追加可能
・ファイル名のハッシュ
  - 大文字ファイル名の 2バイトチェックサム
  - ファイル名のチェックの高速化
・OEM 固有パラメータ
・Transaction-Safe FAT (TFAT)
・FAT32 との後方互換性は無し
・短いファイル名は無し

 また、解析結果から類推される仕様を以下に示す。

・ボリュームサイズは最大で、セクタサイズ × 2^64 (512Bセクタで 8ZiB)
・32bit クラスタ番号
  - クラスタ番号の扱い方は従来と同様
・ファイル名のハッシュ算出用の大文字変換テーブルを持つ
・FAT32 と同様に、ルートディレクトリは特殊なサブディレクトリの扱い
  - ルートディレクトリのサイズ拡張可能
・空きスペースビットマップと大文字変換テーブルは特殊なファイルの扱い



3.解析結果

3.1. ボリューム先頭
・セクタ 0
+00h: BYTE[3] ジャンプ命令
+03h: BYTE[8] OEM名 ("EXFAT   ")
+0bh: BPB32 (00h)
+40h: DWORD ??? (78h)
+44h: DWORD ??? (00h)
+48h: QWORD ボリュームのセクタ数
+50h: DWORD FAT開始セクタ番号
+54h: DWORD FATセクタ数
+58h: DWORD 先頭クラスタ開始セクタ番号
+5ch: DWORD ボリュームのクラスタ数
+60h: DWORD ルートディレクトリ開始クラスタ番号
+64h: DWORD Volume ID
+68h: DWORD ??? (0100h)
+6ch: BYTE  SectorSizeShift
+6dh: BYTE  ClusterShift
+6eh: BYTE  ??? (01h)
+6fh: BYTE  ??? (80h)
+1feh: WORD Signature (AA55h)

FAT32 の BPB に相当する +0bh~+3fh の部分は 0 で埋められている。
SectorSize = 1 << SectorSizeShift
ClusterSize = SectorSize << ClusterShift


&#12539;セクタ 0~8
+00h: BYTE[510] Data (00h)
+1feh: WORD Signature (AA55h)

&#12539;セクタ 9~10
空き?

&#12539;セクタ 11
不明 (ex. 3ah cbh 3fh abh ...)

&#12539;セクタ 12~23
セクタ 0~11 のバックアップ

&#12539;セクタ 24~FAT直前
空き



3.2. ディレクトリエントリ
ディレクトリエントリは 1つ 32bytes から成り、それらを複数組み合わせて 1つの
ファイルの情報を表す。ディレクトリエントリの先頭 1byte は、エントリの種別を
示しており、残りの 31bytes は種別により異なる情報が格納される。

現在確認できているエントリ種別は以下の通り。詳細は後述。
&#12539;81h, 82h, 83h, 85h, C0h, C1h, 05h, 40h, 41h, 00h

ルートディレクトリには、通常、先頭から 83h, 81h, 82h の順にディレクトリ
エントリが並び、一般のファイルはその後に並ぶ。

一般のファイルやサブディレクトリのディレクトリエントリは、85h, C0h, C1h の
順に並ぶ。ファイル名が 15文字を超える場合は、C1h が複数並ぶ。
(例: 85h, C0h, C1h, C1h ... C1h)

従来 FAT とは異なり、サブディレクトリには、親ディレクトリや自身を示す
".." や "." といったディレクトリエントリは作成されない。


○ DirectoryEntry
+00h: BYTE type
+01h: BYTE[31] Data

○ type=83h VolumeID
+00h: BYTE type (83h)
+01h: BYTE len (max:11)
+02h: WCHAR[11] VolumeID
+18h: BYTE[8] reserved

ボリューム名を格納するエントリ。


○ type=81h ClusterBitmapFile
+00h: BYTE type (81h)
+01h: BYTE reserved (00h)
+02h: BYTE[18] reserved
+14h: DWORD StartCluster (0002h)
+18h: QWORD FileSize

クラスタの使用状況を示すビットマップを格納した特殊ファイルの格納位置とサイズを
示すエントリ。


○ type=82h CharUpperTableFile
+00h: BYTE type (82h)
+01h: BYTE reserved (00h)
+02h: BYTE[2] reserved
+04h: DWORD ???
+08h: BYTE[12] reserved
+14h: DWORD StartCluster
+18h: QWORD FileSize

ファイル名のハッシュの算出に使用する、大文字変換テーブルを格納した特殊ファイル
の格納位置とサイズを示すエントリ。


○ type=85h FileAttributes1
+00h: BYTE type (85h)
+01h: BYTE AdditionalEntryNum (2~18 ?)
+02h: WORD Checksum
+04h: DWORD Attributes
+08h: DWORD CreationTime
+0Ch: DWORD LastWriteTime
+10h: DWORD LastAccessTime
+14h: BYTE  CreationTime (10ms)
+15h: BYTE[3] reserved
+18h: BYTE[8] reserved

ファイルの属性などを格納するエントリ。
&#12539;日時の形式は従来 FAT と同様。
&#12539;Checksum の算出方法は後述。
&#12539;Attributes の値は、従来 FAT と同様。


○ type=C0h FileAttributes2
+00h: BYTE type (C0h)
+01h: BYTE FragmentFlag ??? (01h or 03h)
+02h: BYTE reserved ???
+03h: BYTE FileNameLength WCHAR単位のファイル名長
+04h: WORD FileNameHash
+06h: WORD reserved
+08h: QWORD FileSize1
+10h: DWORD reserved
+14h: DWORD StartCluster
+18h: QWORD FileSize2

ファイルの属性などを格納するエントリ。
&#12539;ファイルサイズが 2つあるが、NTFS のようなファイルの圧縮を想定したものと
  思われる。どちらが圧縮後のファイルサイズかは不明。(現在はどちらも同じ値が
  格納されている。)
&#12539;FragmentFlag は、ファイルサイズが 0 のとき、あるいはファイルが分断している
  ときは 01h、ファイルが連続しているときは 03h となる模様。(詳細不明)
&#12539;FileNameHash の算出方法は後述。
&#12539;従来 FAT とは異なり、ディレクトリの場合にもファイルサイズが書き込まれる。
  (クラスタビットマップだけではどこまでで終わりとなるかが分からないため。)
  サイズは、クラスタサイズの倍数となる。


○ type=C1h FileName
+00h: BYTE type (C1h)
+01h: BYTE reserved
+02h: WCHAR[15] FileName

ファイル名を格納するエントリ。
&#12539;ファイル名が 15文字を超える場合は複数使用する。その際、ファイル名は先頭から
  順に格納する。(従来 FAT のように逆順にはならない。)


○ type=05h, 40h, 41h DeletedEntry
削除済みエントリ。
&#12539;ファイルを削除した場合、type の最上位ビットは 0 になる。
&#12539;削除の際、チェックサムの再計算は行わない。


○ type=00h LastEntry
最後のエントリ。



&#12539;Checksum 算出方法
 ディレクトリエントリの整合性を確認するためのチェックサムの算出方法を示す。
通常、ファイルの情報は複数のディレクトリエントリに渡って格納されているが、
チェックサムはそれらのエントリ全体に対して計算を行う。なお、チェックサム
算出時には、チェックサム領域そのものは飛ばして計算する。

WORD CalcChecksum(LPCBYTE entry)
{
    WORD chk = 0;
    int len, i;
   
    len = 32 * (entry[1] + 1);
    for (i = 0; i < len; i++) {
        if (i == 2 || i == 3)
            continue;
        chk = (WORD) (((chk << 15) | (chk >> 1)) + entry);
    }
    return chk;
}


&#12539;ファイル名ハッシュ算出方法
 ファイル名のハッシュは、Unicode で大文字に変換してから 1バイト単位で計算を
行う。大文字への変換は、下記のコードでは CharUpperW() を利用しているが、実際
には後述の大文字変換テーブルを用いる。

WORD CalcFileNameHash(LPCWSTR filename)
{
    WORD chk = 0;
    int len, i;
   
    len = lstrlenW(filename);
    for (i = 0; i < len; i++) {
        WCHAR c = (WCHAR) CharUpperW((LPWSTR) filename);
        chk = (WORD) (((chk << 15) | (chk >> 1)) + LOBYTE(c));
        chk = (WORD) (((chk << 15) | (chk >> 1)) + HIBYTE(c));
    }
    return chk;
}



3.3. FAT
 FAT の構造は FAT32 とほぼ同等。ただし、クラスタ番号は 28bit ではなく、32bit
となっている。
 FAT の個数は 1個。(TFAT を使う場合は 2個?)
 クラスタビットマップ、大文字変換テーブル、ルートディレクトリは、必ず FAT に
クラスタの使用状況が書き込まれるが、それ以外のファイル&#12539;ディレクトリについて
は、分断が発生した場合だけクラスタ使用状況が書き込まれる。



3.4. クラスタビットマップ
 クラスタの使用状況を示したビットマップ。1bit が 1クラスタに対応しており、
先頭クラスタである No.2 クラスタは 0バイト目の 0bit に対応する。
ビットが立っていれば、そのクラスタは使用中である。
 FAT 上での使用状況と、ビットマップ上での使用状況が一致していない場合は、
ビットマップの方が優先される。



3.5. 大文字変換テーブル
 ファイル名ハッシュの算出の際に利用する大文字への変換テーブルである。
WCHAR 単位で、U+0000 から U+FFFF までの変換情報が格納されているが、サイズ
削減のため、変換の必要ない部分に関しては省略されている。有効な区間の終端には
FFFFh が格納され、その次の 2バイトには、スキップする文字数が格納されている。
 以下に、大文字変換テーブルの例を示す。

+0000h: 0000h (U+0000)
+0002h: 0001h (U+0001)
+0004h: 0002h (U+0002)
   :
+0B0Ch: 0556h (U+0586)
+0B0Eh: FFFFh 終端
+0B10h: 17F6h スキップ数
+0B12h: 2C63h (U+1D7D) (0586h + 17F6h + 1 = 1D7Dh)
+0B14h: 1D7Eh (U+1D7E)
   :
+1320h: 2183h (U+2184)
+1322h: FFFFh 終端
+1324h: 034Bh スキップ数
+1326h: 24B6h (U+24D0) (2184h + 034Bh + 1 = 24D0h)
   :
+1358h: 24CFh (U+24E9)
+135Ah: FFFFh 終端
+135Ch: 0746h スキップ数
+135Eh: 2C00h (U+2C30) (24E9h + 0746h + 1 = 2C30h)
   :
+1548h: 10C5h (U+2D25)
+154Ah: FFFFh 終端
+154Ch: D21Bh スキップ数
+154Eh: FF21h (U+FF41) (2D25h + D12Bh + 1 = FF41h)
   :
+16C8h: FFFEh (U+FFFE)
+16CAh: FFFFh (U+FFFF) 終端



4.更新履歴
2008/06/25
  &#12539;初公開。

2008/06/27
  &#12539;小修正。



5.参考文献
[1] Personal Storage: Opportunities and Challenges for Pocket-Sized Storage Devices in the Windows World
http://download.microsoft.com/do ... 3cd/STO072_WH06.ppt

[2] Extended FAT File System
http://msdn.microsoft.com/en-us/library/aa914353.aspx

[3] Transaction-Safe FAT File System
http://msdn.microsoft.com/en-us/library/aa911939.aspx

[4] FAT32 File System Specification
http://www.microsoft.com/whdc/sy ... irmware/fatgen.mspx


--
K.Takata
http://webs.to/ken/
http://homepage3.nifty.com/k-takata/
 楼主| 发表于 2009-2-22 07:34:08 | 显示全部楼层
李先生,等着下个版本更新呢,呵呵,我QQ 104505021
 楼主| 发表于 2009-2-22 07:37:18 | 显示全部楼层

翻译的英文版(Google)

exFAT structural analysis

                                                         2008/06/27 K. Takata

1. Early
In this document, Windows Vista SP1 and Windows CE 6.0 was adopted in New
ExFAT file system that shows the result of a unique structure.



Two. Specifications Overview
ExFAT outline specification. Below, WinHEC 2006 slides [1] and,
MSDN information [2,3] are excerpts.

File system for flash media
Corresponds to a larger media 32GB
Handle more than a thousand files in one directory
Available SUPESUBITTOMAPPU
   - Allocate space fast, fast delete
64bit file size management
Large cluster size (up to 2 ^ 255 is the theoretical maximum on the implementation 32MB)
Scalability for the future
   - Flexible and scalable directory structure
   - You can add features while maintaining compatibility
Hash of the file name
   - The file name uppercase 2 BAITOCHEKKUSAMU
   - Check the speed of the file name
OEM-specific parameters
Transaction-Safe FAT (TFAT)
FAT32 has no backwards compatibility with
No short file name

In addition, the following specifications to be inferred from the analysis results.

The maximum volume size, sector size × 2 ^ 64 (512B sectors 8ZiB)
32bit cluster number
   - How to handle the same cluster number
Conversion table for a calculated sensitivity of the hash of the file name
As with FAT32, the root directory are treated in a special subdirectory
   - The size of the root directory can be expanded
Conversion table SUPESUBITTOMAPPU and sensitive handling of space is a special file



Three. Analysis results

3.1. The volume
Sector 0
+00 H: BYTE [3] Jump instruction
+03 H: BYTE [8] OEM name ( "EXFAT")
+0 Bh: BPB32 (00h)
+40 H: DWORD??? (78h)
+44 H: DWORD??? (00h)
+48 H: QWORD number of sectors in volume
+50 H: DWORD FAT start sector number
+54 H: DWORD FAT Number of sectors
+58 H: DWORD starting sector number cluster head
+5 Ch: DWORD number of clusters of volume
+60 H: DWORD root directory start cluster number
+64 H: DWORD Volume ID
+68 H: DWORD??? (0100h)
+6 Ch: BYTE SectorSizeShift
+6 Dh: BYTE ClusterShift
+6 Eh: BYTE??? (01h)
+6 Fh: BYTE??? (80h)
+1 Feh: WORD Signature (AA55h)

Equivalent to the FAT32 BPB +0 bh ~ +3 fh parts are filled with 0.
SectorSize = 1 <<SectorSizeShift
ClusterSize = SectorSize <<ClusterShift


Sector 0-8
+00 H: BYTE [510] Data (00h)
+1 Feh: WORD Signature (AA55h)

Sectors 9-10
Available?

Sector 11
Unknown (ex. 3ah cbh 3fh abh ...)

Sector 12-23
Sector backup 0-11

24 ~ FAT sector just before
Available



3.2. Directory entry
One directory entry consists of 32bytes, a combination of single and multiple
Representing the information of the file. 1byte top of the directory entry, the type of entry
And shows the remaining 31bytes be different depending on the information stored in the seed.

Now you can type the entries are as follows. For details, see below.
81h, 82h, 83h, 85h, C0h, C1h, 05h, 40h, 41h, 00h

The root directory is usually the first 83h, 81h, 82h Directory>
Order entry, and then stand in the public file.

Directory entries of files and subdirectories of the public, 85h, C0h, C1h of
Stand in order. If the file name exceeds 15 characters, C1h multiple stand.
(Example: 85h, C0h, C1h, C1h ... C1h)

FAT Unlike conventional, sub-directory, which contains the directory and their parents
".." Or "." And the directory entry is not created.


○ DirectoryEntry
+00 H: BYTE type
+01 H: BYTE [31] Data

○ type = 83h VolumeID
+00 H: BYTE type (83h)
+01 H: BYTE len (max: 11)
+02 H: WCHAR [11] VolumeID
+18 H: BYTE [8] reserved

Entry to store the volume name.


○ type = 81h ClusterBitmapFile
+00 H: BYTE type (81h)
+01 H: BYTE reserved (00h)
+02 H: BYTE [18] reserved
+14 H: DWORD StartCluster (0002h)
+18 H: QWORD FileSize

The position and size stored in a special file containing a bitmap that indicates the use of cluster
Show entry.


○ type = 82h CharUpperTableFile
+00 H: BYTE type (82h)
+01 H: BYTE reserved (00h)
+02 H: BYTE [2] reserved
+04 H: DWORD???
+08 H: BYTE [12] reserved
+14 H: DWORD StartCluster
+18 H: QWORD FileSize

Used to calculate the hash of the file name, a special file containing the sensitive conversion table
Entry indicating the position and size of the store.


○ type = 85h FileAttributes1
+00 H: BYTE type (85h)
+01 H: BYTE AdditionalEntryNum (2 ~ 18?)
+02 H: WORD Checksum
+04 H: DWORD Attributes
+08 H: DWORD CreationTime
+0 Ch: DWORD LastWriteTime
+10 H: DWORD LastAccessTime
+14 H: BYTE CreationTime (10ms)
+15 H: BYTE [3] reserved
+18 H: BYTE [8] reserved

Entries and attributes to store the file.
Date format is similar to conventional FAT.
Checksum calculation method is described below.
Attributes values are similar to conventional FAT.


○ type = C0h FileAttributes2
+00 H: BYTE type (C0h)
+01 H: BYTE FragmentFlag??? (01h or 03h)
+02 H: BYTE reserved???
+03 H: BYTE FileNameLength WCHAR filename length of unit
+04 H: WORD FileNameHash
+06 H: WORD reserved
+08 H: QWORD FileSize1
+10 H: DWORD reserved
+14 H: DWORD StartCluster
+18 H: QWORD FileSize2

Entries and attributes to store the file.
2 is a single file size, NTFS, and assumes that the compression of files, such as
   Be. After the compressed file size or both is unknown. (Current value is the same
   Are stored. )
FragmentFlag is 0 when the file size, or that the file division
   When is 01h, while a continuous pattern file and 03h. (Unspecified)
FileNameHash calculation method is described below.
Unlike conventional FAT, is written as if the directory size.
   (KURASUTABITTOMAPPU just because I do not know how far and in the end.)
   Size is the multiple of the cluster size.


○ type = C1h FileName
+00 H: BYTE type (C1h)
+01 H: BYTE reserved
+02 H: WCHAR [15] FileName

Entry to store the file name.
If the file name exceeds 15 characters is used. The file name from the top
   Stored sequentially. (Conventional FAT is not as backwards.)


○ type = 05h, 40h, 41h DeletedEntry
Deleted entry.
If you delete a file, type the most significant bit is zero.
When removed, the checksum is not recalculated.


○ type = 00h LastEntry
The last entry.



Checksum calculation method
That shows how to calculate the checksum to verify the integrity of the directory entry.
Typically, files are stored across multiple directory entries,
Checksum is calculated over the entire entry to them. The Checksum
When calculated, the checksum is calculated to skip areas.

WORD CalcChecksum (LPCBYTE entry)
(
     WORD chk = 0;
     int len, i;
     
     len = 32 * (entry [1] + 1);
     for (i = 0; i <len; i + +) (
         if (i == 2 | | i == 3)
             continue;
         chk = (WORD) (((chk <<15) | (chk>> 1)) + entry);
     )
     return chk;
)


How to calculate file hashes
Hash of the file names, Unicode and then converted to uppercase in a calculation in bytes
Do. Converted to uppercase, the following code CharUpperW () is used to actually
Sensitive to the use of conversion tables below.

WORD CalcFileNameHash (LPCWSTR filename)
(
     WORD chk = 0;
     int len, i;
     
     len = lstrlenW (filename);
     for (i = 0; i <len; i + +) (
         WCHAR c = (WCHAR) CharUpperW ((LPWSTR) filename);
         chk = (WORD) (((chk <<15) | (chk>> 1)) + LOBYTE (c));
         chk = (WORD) (((chk <<15) | (chk>> 1)) + HIBYTE (c));
     )
     return chk;
)



3.3. FAT
The structure of the FAT and FAT32 similar. However, the cluster number 28bit instead, 32bit
Said.
A number of the FAT. (TFAT to use two?)
KURASUTABITTOMAPPU, uppercase conversion table, root directory, be sure to FAT
The use of the cluster is written for the other file directory
Is written to use only the case of cluster division.



3.4. KURASUTABITTOMAPPU
Bitmap usage of the cluster. 1bit the one which corresponds to the cluster,
No.2 is the cluster head of cluster 0 of the corresponding byte 0bit.
If the bit is on, the cluster is in use.
FAT on usage and, if not identical to the usage of the bitmap,
Preference is given to the bitmap.



3.5. Uppercase conversion table
Table is converted to uppercase when used to calculate the hash of the file name.
WCHAR unit, U +0000 to U + FFFF are stored information is converted to size
To reduce any part of the conversion should not have been omitted. The end of the section is valid
FFFFH is stored, the next two bytes are stored in the number of characters to skip.
The following table shows an example of transformation capitalized.

+0000 H: 0000h (U +0000)
+0002 H: 0001h (U +0001)
+0004 H: 0002h (U +0002)
    :
+0 B0Ch: 0556h (U +0586)
+0 B0Eh: FFFFh termination
+0 B10h: 17F6h number of skipped
+0 B12h: 2C63h (U +1 D7D) (0586h + 17F6h + 1 = 1D7Dh)
+0 B14h: 1D7Eh (U +1 D7E)
    :
+1320 H: 2183h (U +2184)
+1322 H: FFFFh termination
+1324 H: 034Bh number of skipped
+1326 H: 24B6h (U +24 D0) (2184h + 034Bh + 1 = 24D0h)
    :
+1358 H: 24CFh (U +24 E9)
+135 Ah: FFFFh termination
+135 Ch: 0746h number of skipped
+135 Eh: 2C00h (U +2 C30) (24E9h + 0746h + 1 = 2C30h)
    :
+1548 H: 10C5h (U +2 D25)
+154 Ah: FFFFh termination
+154 Ch: D21Bh number of skipped
+154 Eh: FF21h (U + FF41) (2D25h + D12Bh + 1 = FF41h)
    :
+16 C8h: FFFEh (U + FFFE)
+16 CAh: FFFFh (U + FFFF) termination



Four. History
2008/06/25
   First published.

2008/06/27
   Minor change.
发表于 2009-2-28 20:59:39 | 显示全部楼层
- -可不可以上中文版的
发表于 2009-2-28 21:43:32 | 显示全部楼层
可以考虑在论坛里开一个技术交流区,呵呵。
 楼主| 发表于 2009-3-1 12:52:28 | 显示全部楼层

回复 5# DGen 的帖子

好的 :D :D
您需要登录后才可以回帖 登录 | 注册

本版积分规则

Archiver|手机版|小黑屋|DiskGenius ( 冀ICP备05002509号-2 )

GMT+8, 2024-12-23 10:55 , Processed in 0.081588 second(s), 16 queries .

Powered by Discuz! X3.5

© 2001-2024 Discuz! Team.

快速回复 返回顶部 返回列表