Specifica del file system exFAT

  • Articolo
  • 112 minuti per la lettura

1 Introduzione

Il file system exFAT è il successore di FAT32 nella famiglia FAT di file system. Questa specifica descrive il file system exFAT e fornisce tutte le informazioni necessarie per implementare il file system exFAT.

1.1 Obiettivi di progettazione

Il file system exFAT ha tre obiettivi di progettazione centrale (vedere l'elenco seguente).

  1. Mantenere la semplicità dei file system basati su FAT.

    Due dei punti di forza dei file system basati su FAT sono la loro semplicità e facilità di implementazione. Nello spirito dei suoi predecessori, gli implementatori dovrebbero trovare exFAT relativamente semplice e facile da implementare.

  2. Abilitare file e dispositivi di archiviazione molto grandi.

    Il file system exFAT usa 64 bit per descrivere le dimensioni dei file, consentendo così alle applicazioni che dipendono da file molto grandi. Il file system exFAT consente anche i cluster di grandi dimensioni pari a 32 MB, consentendo in modo efficace dispositivi di archiviazione molto grandi.

  3. Incorporare l'estendibilità per l'innovazione futura.

    Il file system exFAT incorpora l'estendibilità nella sua progettazione, consentendo al file system di mantenere il ritmo con le innovazioni nell'archiviazione e nelle modifiche nell'utilizzo.

1.2 Terminologia specifica

Nel contesto di questa specifica, alcuni termini (vedere Tabella 1) contengono un significato specifico per la progettazione e l'implementazione del file system exFAT.

Tabella 1 definizione dei termini che contengono un significato molto specifico

Termine Definizione
Deve Questa specifica usa il termine "deve" per descrivere un comportamento obbligatorio.
Dovrebbe Questa specifica usa il termine "deve" per descrivere un comportamento che consiglia vivamente, ma non rende obbligatorio.
Mag Questa specifica usa il termine "may" per descrivere un comportamento facoltativo.
Obbligatorio Questo termine descrive un campo o una struttura che un'implementazione modifica e interpreta come questa specifica.
Facoltativo Questo termine descrive un campo o una struttura che può supportare o meno un'implementazione. Se un'implementazione supporta un determinato campo o struttura facoltativa, la modifica e interpreta il campo o la struttura come questa specifica.
Non definito Questo termine descrive il contenuto del campo o della struttura che un'implementazione può modificare in base alle esigenze (ad esempio, cancellare a zero quando si impostano campi o strutture circostanti) e non interpretare per contenere alcun significato specifico.
Riservato

Questo termine descrive il contenuto del campo o della struttura che implementa:

  1. Inizializza a zero e non deve essere usato per alcun scopo

  2. Non è consigliabile interpretare, tranne quando si calcolano i checksum

  3. Conserva le operazioni che modificano i campi o le strutture circostanti

1.3 Testo completo degli acronimi comuni

Questa specifica usa gli acronimi in uso comune nel settore del personal computer (vedere Tabella 2).

Tabella 2 full text degli acronimi comuni

Acronimo Full-text
ASCII Codice standard americano per l'interscambio delle informazioni
BIOS Sistema di output di input di base
CPU Unità di elaborazione centrale
exFAT Tabella di allocazione file estendibile
FAT Tabella di allocazione file
FAT12 Tabella allocazione file, indici cluster a 12 bit
FAT16 Tabella allocazione file, indici cluster a 16 bit
FAT32 Tabella allocazione file, indici cluster a 32 bit
GPT tabella delle partizioni GUID
GUID Identificatore univoco globale (vedere la sezione 10.1)
INT Interrompere
MBR record di avvio principale
texFAT ExFAT sicuro delle transazioni
UTC Ora universale coordinata

1.4 Qualificatori di campo e struttura predefiniti

I campi e le strutture in questa specifica hanno i qualificatori seguenti (vedere l'elenco seguente), a meno che le note sulla specifica non siano diverse.

  1. Non firmato

  2. Usare la notazione decimale per descrivere i valori, dove non diversamente annotati; questa specifica usa la lettera "h" post-correzione per indicare i numeri esadecimali e racchiude i GUID nelle parentesi graffe

  3. Sono in formato little-endian

  4. Non richiedere un carattere di terminazione null per le stringhe

1.5 Windows CE e TexFAT

TexFAT è un'estensione di exFAT che aggiunge semantica operativa sicura per le transazioni nella parte superiore del file system di base. TexFAT viene usato da Windows CE. TexFAT richiede l'uso delle due bitmap di allocazione e delle due unità di tipo FATS per l'uso nelle transazioni. Definisce anche diverse strutture aggiuntive, tra cui descrittori di riempimento e descrittori di sicurezza.

Struttura del volume 2

Un volume è il set di tutte le strutture del file system e lo spazio dati necessario per archiviare e recuperare i dati utente. Tutti i volumi exFAT contengono quattro aree (vedere Tabella 3).

Struttura del volume tabella 3

Nome area secondaria

Offset

(settore)

Dimensione

(settori)

 Commenti
Area di avvio principale
Settore principale di avvio 0 1 Questa sotto-area è obbligatoria e la sezione 3.1 definisce il contenuto.
Principali settori di avvio estesi 1 8 Questa sotto-area è obbligatoria e la sezione 3.2 definisce il contenuto.
Parametri OEM principali 9 1 Questa sotto-area è obbligatoria e la sezione 3.3 definisce il contenuto.
Principale riservato 10 1 Questa sotto-area è obbligatoria e il relativo contenuto è riservato.
Controllo di avvio principale 11 1 Questa sotto-area è obbligatoria e la sezione 3.4 definisce il contenuto.
Area di avvio del backup
Settore di avvio di backup 12 1 Questa sotto-area è obbligatoria e la sezione 3.1 definisce il contenuto.
Settori di avvio estesi di backup 13 8 Questa sotto-area è obbligatoria e la sezione 3.2 definisce il contenuto.
Parametri OEM di backup 21 1 Questa sotto-area è obbligatoria e la sezione 3.3 definisce il contenuto.
Backup riservato 22 1 Questa sotto-area è obbligatoria e il relativo contenuto è riservato.
Controllo di avvio del backup 23 1 Questa sotto-area è obbligatoria e la sezione 3.4 definisce il contenuto.
Area FAT
Allineamento FAT 24 FatOffset - 24

Questa sotto-area è obbligatoria e il relativo contenuto, se presente, non sono definiti.

Nota: i settori di avvio principale e di backup contengono entrambi il campo FatOffset.
Primo GRASSO FatOffset FatLength

Questa sotto-area è obbligatoria e la sezione 4.1 definisce il contenuto.

Nota: i settori di avvio principale e di backup contengono entrambi i campi FatOffset e FatLength.
Secondo GRASSO FatOffset + FatLength FatLength * (NumberOfFats - 1)

Questa sotto-area è obbligatoria e la sezione 4.1 definisce il contenuto, se presente.

Nota: i settori di avvio principale e di backup contengono entrambi i campi FatOffset, FatLength e NumberOfFats. Il campo NumberOfFats può contenere solo valori 1 e 2.
Area dati
Allineamento dell'heap del cluster FatOffset + FatLength * NumberOfFats ClusterHeapOffset : (FatOffset + FatLength * NumberOfFats)

Questa sotto-area è obbligatoria e il relativo contenuto, se presente, non sono definiti.

Nota: i settori di avvio principale e di backup contengono entrambi i campi FatOffset, FatLength, NumberOfFats e ClusterHeapOffset. I valori validi del campo NumberOfFats sono 1 e 2.
Cluster Heap ClusterHeapOffset ClusterCount * 2SettoriPerClusterShift

Questa sotto-area è obbligatoria e la sezione 5.1 definisce il contenuto.

Nota: i settori di avvio principale e di backup contengono entrambi i campi ClusterHeapOffset, ClusterCount e SectorsPerClusterShift.
Spazio in eccesso ClusterHeapOffset + ClusterCount * 2SettoriPerClusterShift VolumeLength : (ClusterHeapOffset + ClusterCount * 2SettoriPerClusterShift)

Questa sotto-area è obbligatoria e il relativo contenuto, se presente, non sono definiti.

Nota: i settori di avvio principale e di backup contengono entrambi i campi ClusterHeapOffset, ClusterCount, SectorsPerClusterShift e VolumeLength.

3 Aree di avvio principale e di backup

L'area principale di avvio fornisce tutte le istruzioni di avvio necessarie, l'identificazione delle informazioni e i parametri del file system per consentire a un'implementazione di eseguire le operazioni seguenti:

  1. Nastro di avvio di un sistema computer da un volume exFAT.

  2. Identificare il file system nel volume come exFAT.

  3. Individuare il percorso delle strutture del file system exFAT.

L'area di avvio del backup è un backup dell'area di avvio principale. Consente il ripristino del volume exFAT in caso di avvio principale in uno stato incoerente. Ad eccezione di circostanze non frequenti, ad esempio l'aggiornamento delle istruzioni di avvio a strappo, le implementazioni non devono modificare il contenuto dell'area di avvio di backup.

3.1 Aree secondarie del settore principale e di avvio di backup

Il settore principale di avvio contiene il codice per l'associazione di avvio da un volume exFAT e parametri fondamentali di exFAT che descrivono la struttura del volume (vedere Tabella 4). BIOS, MBR o altri agenti di strapping di avvio possono controllare questo settore e possono caricare ed eseguire eventuali istruzioni di strapping di avvio contenute in esso.

Il settore di avvio di backup è un backup del settore principale di avvio e ha la stessa struttura (vedere La tabella 4). Il settore di avvio del backup può aiutare le operazioni di ripristino; tuttavia, le implementazioni considerano il contenuto dei campi VolumeFlags e PercentInUse come non aggiornati.

Prima di usare il contenuto del settore principale o di avvio di backup, le implementazioni verificheranno il contenuto convalidando il rispettivo checksum di avvio e assicurando che tutti i campi siano all'interno dell'intervallo di valori validi.

Anche se l'operazione di formato iniziale inizializza il contenuto dei settori di avvio principale e di backup, le implementazioni possono aggiornare questi settori (e aggiorneranno anche il rispettivo checksum di avvio) in base alle esigenze. Tuttavia, le implementazioni possono aggiornare i campi VolumeFlags o PercentInUse senza aggiornare il rispettivo checksum di avvio (il checksum esclude in modo specifico questi due campi).

Tabella 4 Struttura principale e del settore di avvio di backup

Nome campo

Offset

(byte)

Dimensione

(byte)

 Commenti
JumpBoot 0 3 Questo campo è obbligatorio e la sezione 3.1.1 definisce il contenuto.
FileSystemName 3 8 Questo campo è obbligatorio e la sezione 3.1.2 definisce il contenuto.
MustBeZero 11 53 Questo campo è obbligatorio e la sezione 3.1.3 ne definisce il contenuto.
PartitionOffset 64 8 Questo campo è obbligatorio e la sezione 3.1.4 ne definisce il contenuto.
VolumeLength 72 8 Questo campo è obbligatorio e la sezione 3.1.5 ne definisce il contenuto.
FatOffset 80 4 Questo campo è obbligatorio e la sezione 3.1.6 ne definisce il contenuto.
FatLength 84 4 Questo campo è obbligatorio e la sezione 3.1.7 ne definisce il contenuto.
ClusterHeapOffset 88 4 Questo campo è obbligatorio e la sezione 3.1.8 ne definisce il contenuto.
ClusterCount 92 4 Questo campo è obbligatorio e la sezione 3.1.9 ne definisce il contenuto.
FirstClusterOfRootDirectory 96 4 Questo campo è obbligatorio e la sezione 3.1.10 ne definisce il contenuto.
VolumeSerialNumber 100 4 Questo campo è obbligatorio e la sezione 3.1.11 ne definisce il contenuto.
FileSystemRevision 104 2 Questo campo è obbligatorio e la sezione 3.1.12 ne definisce il contenuto.
VolumeFlags 106 2 Questo campo è obbligatorio e la sezione 3.1.13 ne definisce il contenuto.
BytesPerSectorShift 108 1 Questo campo è obbligatorio e la sezione 3.1.14 ne definisce il contenuto.
SectorsPerClusterShift 109 1 Questo campo è obbligatorio e la sezione 3.1.15 ne definisce il contenuto.
NumberOfFats 110 1 Questo campo è obbligatorio e la sezione 3.1.16 ne definisce il contenuto.
DriveSelect 111 1 Questo campo è obbligatorio e la sezione 3.1.17 ne definisce il contenuto.
PercentInUse 112 1 Questo campo è obbligatorio e la sezione 3.1.18 ne definisce il contenuto.
Riservato 113 7 Questo campo è obbligatorio e il relativo contenuto è riservato.
BootCode 120 390 Questo campo è obbligatorio e la sezione 3.1.19 ne definisce il contenuto.
BootSignature 510 2 Questo campo è obbligatorio e la sezione 3.1.20 ne definisce il contenuto.
ExcessSpace 512 2BytePerSectorShift - 512

Questo campo è obbligatorio e il relativo contenuto, se presente, non sono definiti.

Nota: i settori principale e di avvio di backup contengono entrambi il campo BytesPerSectorShift.

3.1.1 Campo JumpBoot

Il campo JumpBoot deve contenere l'istruzione jump per le CPU comuni nei personal computer, che, quando eseguite, "salta" la CPU per eseguire le istruzioni di avvio a strapping nel campo BootCode.

Il valore valido per questo campo è (in ordine di byte di ordine basso a byte elevato) EBh 76h 90h.

3.1.2 Campo FileSystemName

Il campo FileSystemName deve contenere il nome del file system nel volume.

Il valore valido per questo campo è, in caratteri ASCII, "EXFAT", che include tre spazi vuoti finali.

3.1.3 Campo MustBeZero

Il campo MustBeZero deve corrispondere direttamente all'intervallo di byte utilizzato dal blocco di parametri BIOS compresso nei volumi FAT12/16/32.

Il valore valido per questo campo è 0, che consente di impedire alle implementazioni FAT12/16/32 di montare erroneamente un volume exFAT.

Campo PartitionOffset 3.1.4

Il campo PartitionOffset descrive l'offset del settore relativo ai supporti della partizione che ospita il volume exFAT specificato. Questo campo facilita l'strapping di avvio dal volume tramite INT esteso 13h nei computer personali.

Tutti i valori possibili per questo campo sono validi; Tuttavia, il valore 0 indica che le implementazioni devono ignorare questo campo.

Campo VolumeLength 3.1.5

Il campo VolumeLength descrive le dimensioni del volume exFAT specificato nei settori.

L'intervallo valido di valori per questo campo deve essere:

  • Almeno2 20/ 2BytePerSectorShift, che garantisce che il volume più piccolo non sia inferiore a 1 MB

  • Al massimo 264-1, il valore più grande che questo campo può descrivere.

    Tuttavia, se la dimensione della sotto-area spazio in eccesso è 0, il valore più grande di questo campo è ClusterHeapOffset + (232- 11) * 2SectorsPerClusterShift.

3.1.6 Campo FatOffset

Il campo FatOffset descrive l'offset del settore relativo al volume del First FAT. Questo campo consente alle implementazioni di allineare first FAT alle caratteristiche dei supporti di archiviazione sottostanti.

L'intervallo di valori valido per questo campo deve essere:

  • Almeno 24, che rappresenta i settori in cui vengono usate le aree di avvio principale e di avvio di backup

  • Al massimo ClusterHeapOffset - (FatLength * NumberOfFats), che rappresenta i settori in cui viene utilizzato l'Heap cluster

3.1.7 Campo FatLength

Il campo FatLength descrive la lunghezza, nei settori, di ogni tabella FAT (il volume può contenere fino a due FTS).

L'intervallo di valori valido per questo campo deve essere:

  • Almeno (ClusterCount + 2) *2 2/ 2BytePerSectorShiftarrotondato fino all'intero più vicino, che assicura che ogni FAT abbia spazio sufficiente per descrivere tutti i cluster nell'heap del cluster

  • Al massimo (ClusterHeapOffset - FatOffset) / NumberOfFats arrotondato verso il basso al numero intero più vicino, che garantisce che le fats esistano prima dell'heap del cluster

Questo campo può contenere un valore in eccesso del relativo limite inferiore (come descritto in precedenza) per consentire al Secondo FAT, se presente, di essere allineato anche alle caratteristiche dei supporti di archiviazione sottostanti. Il contenuto dello spazio che supera quello che il FAT stesso richiede, se presente, non è definito.

Campo ClusterHeapOffset 3.1.8

Il campo ClusterHeapOffset descrive l'offset del settore relativo al volume dell'heap cluster. Questo campo consente alle implementazioni di allineare l'heap cluster alle caratteristiche dei supporti di archiviazione sottostanti.

L'intervallo di valori valido per questo campo deve essere:

  • Almeno FatOffset + FatLength * NumberOfFats, per tenere conto dei settori che usano tutte le aree precedenti

  • Al massimo 232- 1 o VolumeLength - (ClusterCount * 2SectorsPerClusterShift), il calcolo è minore

Campo ClusterCount 3.1.9

Il campo ClusterCount descrive il numero di cluster che il cluster heap contiene.

Il valore valido per questo campo deve essere minore dei seguenti:

  • (VolumeLength - ClusterHeapOffset) / 2SectorsPerClusterShiftarrotondato verso il basso all'intero più vicino, ovvero esattamente il numero di cluster che possono adattarsi tra l'inizio dell'heap cluster e la fine del volume

  • 232- 11, ovvero il numero massimo di cluster che un FAT può descrivere

Il valore del campo ClusterCount determina la dimensione minima di un VALORE FAT. Per evitare le FTS estremamente grandi, le implementazioni possono controllare il numero di cluster nell'heap del cluster aumentando le dimensioni del cluster (tramite il campo SectorsPerClusterShift). Questa specifica consiglia di non più di 2 cluster da24 a 2 nel cluster Heap. Tuttavia, le implementazioni devono essere in grado di gestire i volumi con un massimo di 232- 11 cluster nell'heap del cluster.

3.1.10 PrimoClusterOfRootDirectory

Il campo FirstClusterOfRootDirectory contiene l'indice del cluster del primo cluster della directory radice. Le implementazioni devono eseguire ogni sforzo per posizionare il primo cluster della directory radice nel primo cluster non valido dopo l'utilizzo della bitmap di allocazione e della tabella up-case.

L'intervallo di valori valido per questo campo deve essere:

  • Almeno 2, l'indice del primo cluster nell'heap del cluster

  • Al massimo ClusterCount + 1, l'indice dell'ultimo cluster nell'heap del cluster

Campo VolumeSerialNumber 3.11

Il campo VolumeSerialNumber contiene un numero di serie univoco. In questo modo vengono aiutate le implementazioni a distinguere tra diversi volumi exFAT. Le implementazioni devono generare il numero di serie combinando la data e l'ora di formattazione del volume exFAT. Il meccanismo per combinare data e ora per formare un numero di serie è specifico dell'implementazione.

Tutti i valori possibili per questo campo sono validi.

Campo FileSystemRevision 3.1.12

Il campo FileSystemRevision descrive i numeri di revisione principali e secondari delle strutture exFAT nel volume specificato.

Il byte ad ordine elevato è il numero di revisione principale e il byte a basso ordine è il numero di revisione minore. Ad esempio, se il byte ad ordine elevato contiene il valore 01h e se il byte a basso ordine contiene il valore 05h, il campo FileSystemRevision descrive il numero di revisione 1.05. Analogamente, se il byte ad ordine elevato contiene il valore 0Ah e se il byte a basso ordine contiene il valore 0Fh, il campo FileSystemRevision descrive il numero di revisione 10.15.

L'intervallo di valori valido per questo campo deve essere:

  • Almeno 0 per il byte a basso ordine e 1 per il byte elevato

  • Al massimo 99 per il byte a basso ordine e 99 per il byte ad ordine elevato

Il numero di revisione di exFAT che descrive questa specifica è 1.00. Le implementazioni di questa specifica devono montare qualsiasi volume exFAT con il numero di revisione principale 1 e non montare alcun volume exFAT con qualsiasi altro numero di revisione principale. Le implementazioni devono rispettare il numero di revisione secondario e non eseguono operazioni o non creano strutture del file system non descritte nella specifica corrispondente del numero di revisione secondario specificato.

3.1.13 Campo VolumeFlags

Il campo VolumeFlags contiene flag che indicano lo stato di varie strutture del file system nel volume exFAT (vedere Tabella 5).

Le implementazioni non includono questo campo quando si calcola il rispettivo checksum dell'avvio principale o dell'area di avvio di backup. Quando si fa riferimento al settore di avvio di backup, le implementazioni considerano questo campo come non aggiornato.

Tabella 5 Struttura campo VolumeFlags

Nome campo

Offset

(bit)

Dimensione

(bit)

 Commenti
ActiveFat 0 1 Questo campo è obbligatorio e la sezione 3.1.13.1 definisce il contenuto.
VolumeDirty 1 1 Questo campo è obbligatorio e la sezione 3.1.13.2 definisce il contenuto.
MediaFailure 2 1 Questo campo è obbligatorio e la sezione 3.1.13.3 definisce il contenuto.
ClearToZero 3 1 Questo campo è obbligatorio e la sezione 3.1.13.4 definisce il contenuto.
Riservato 4 12 Questo campo è obbligatorio e il relativo contenuto è riservato.
3.1.13.1 Campo ActiveFat

Il campo ActiveFat descrive quali bitmap FAT e allocazione sono attivi (e le implementazioni devono usare), come indicato di seguito:

  • 0, il che significa che la prima bitmap DI FAT e First Allocazione sono attive

  • 1, il che significa che la seconda bitmap DI FAT e Seconda allocazione sono attive ed è possibile solo quando il campo NumberOfFats contiene il valore 2

Le implementazioni devono considerare fat e bitmap di allocazione inattivi come non aggiornate. Solo le implementazioni con riconoscimento di TexFAT cambiano le bitmap DI FAT e allocazione attive (vedere la sezione 7.1).

3.1.13.2 Campo VolumeDirty

Il campo VolumeDirty descrive se il volume è sporco o meno, come indicato di seguito:

  • 0, il che significa che il volume è probabilmente in uno stato coerente

  • 1, il che significa che il volume è probabilmente in uno stato incoerente

Le implementazioni devono impostare il valore di questo campo su 1 quando si verificano metadati del file system inconsistenibili che non risolvono. Se, durante il montaggio di un volume, il valore di questo campo è 1, solo le implementazioni che risolvono i metadati del file system possono cancellare il valore di questo campo su 0. Tali implementazioni cancellano solo il valore di questo campo a 0 dopo aver verificato che il file system sia in uno stato coerente.

Se, durante il montaggio di un volume, il valore di questo campo è 0, le implementazioni devono impostare questo campo su 1 prima di aggiornare i metadati del file system e cancellare questo campo su 0 in seguito, simile all'ordinamento di scrittura consigliato descritto nella sezione 8.1.

3.1.13.3 MediaFailure Field

Il campo MediaFailure descrive se un'implementazione ha rilevato errori multimediali o meno, come indicato di seguito:

  • 0, il che significa che il supporto di hosting non ha segnalato errori o eventuali errori noti sono già registrati nei cluster FAT come "cattivi"

  • 1, il che significa che il supporto di hosting ha segnalato errori (ad esempio le operazioni di lettura o scrittura non riuscite)

Un'implementazione deve impostare questo campo su 1 quando:

  1. Il supporto di hosting non riesce a tentare l'accesso a qualsiasi area nel volume

  2. L'implementazione ha esaurito gli algoritmi di ripetizione dei tentativi di accesso, se presenti

Se, durante il montaggio di un volume, il valore di questo campo è 1, le implementazioni che analizzano l'intero volume per errori multimediali e registrano tutti gli errori come cluster "cattivi" nel FAT (o in caso contrario risolvere gli errori multimediali) possono cancellare il valore di questo campo su 0.

3.1.13.4 ClearToZero Field

Il campo ClearToZero non ha un significato significativo in questa specifica.

I valori validi per questo campo sono:

  • 0, che non ha alcun significato particolare

  • 1, che significa che le implementazioni cancellano questo campo a 0 prima di modificare le strutture, le directory o i file del file system

3.1.14 BytePerSectorShift Campo

Il campo BytePerSectorShift descrive i byte per settore espressi come log2(N), dove N è il numero di byte per settore. Ad esempio, per 512 byte per settore, il valore di questo campo è 9.

L'intervallo di valori valido per questo campo deve essere:

  • Almeno 9 (dimensioni del settore di 512 byte), che è il settore più piccolo possibile per un volume exFAT

  • Al massimo 12 (dimensioni del settore di 4096 byte), ovvero le dimensioni della pagina di memoria delle CPU comuni nei computer personali

3.1.15 SettoriPerClusterShift Field

Il campo SectorsPerClusterShift descrive i settori per cluster espressi come log2(N), dove N è il numero di settori per cluster. Ad esempio, per 8 settori per cluster, il valore di questo campo è 3.

L'intervallo di valori valido per questo campo deve essere:

  • Almeno 0 (1 settore per cluster), che è il cluster più piccolo possibile

  • Al massimo 25 - BytePerSectorShift, che restituisce una dimensione del cluster di 32 MB

3.1.16 Campo NumberOfFats

Il campo NumberOfFats descrive il numero di unità fats e bitmap di allocazione che contiene il volume.

L'intervallo di valori valido per questo campo deve essere:

  • 1, che indica che il volume contiene solo la bitmap First FAT e First Allocation

  • 2, che indica che il volume contiene il Primo FAT, Secondo FAT, Prima bitmap di allocazione e Seconda bitmap di allocazione; questo valore è valido solo per i volumi TexFAT

3.1.17 DriveSelect Field

Il campo DriveSelect contiene il numero di unità INT 13h esteso, che aiuta l'avvio a strappare da questo volume usando INT 13h estesi nei computer personali.

Tutti i valori possibili per questo campo sono validi. Campi simili nei file system basati su FAT precedenti contengono spesso il valore 80h.

Campo 3.1.18 PercentInUse

Il campo PercentInUse descrive la percentuale di cluster nell'heap cluster allocata.

L'intervallo di valori valido per questo campo deve essere:

  • Compreso tra 0 e 100 inclusivi, ovvero la percentuale di cluster allocati nell'heap del cluster, arrotondata al numero intero più vicino

  • FFh, che indica la percentuale di cluster allocati nell'heap del cluster non è disponibile

Le implementazioni modificano il valore di questo campo in modo da riflettere le modifiche apportate all'allocazione dei cluster nell'heap del cluster o modificarlo in FFh.

Le implementazioni non includono questo campo quando si calcola il rispettivo checksum dell'avvio principale o dell'area di avvio di backup. Quando si fa riferimento al settore di avvio di backup, le implementazioni considerano questo campo come non aggiornato.

Campo BootCode 3.1.19

Il campo BootCode contiene istruzioni di avvio. Le implementazioni possono popolare questo campo con le istruzioni della CPU necessarie per l'avvio a strappo di un sistema computer. Le implementazioni che non forniscono istruzioni di avvio devono inizializzare ogni byte in questo campo a F4h (l'istruzione di arresto per CPU comuni nei computer personali) come parte dell'operazione di formato.

3.1.20 Campo BootSignature

Il campo BootSignature descrive se la finalità di un determinato settore è che sia un settore di avvio o meno.

Il valore valido per questo campo è AA55h. Qualsiasi altro valore in questo campo invalida il rispettivo settore di avvio. Le implementazioni devono verificare il contenuto di questo campo prima di dipendere da qualsiasi altro campo nel rispettivo settore di avvio.

3.2 Aree secondarie dei settori di avvio estesi e backup

Ogni settore dei principali settori di avvio esteso ha la stessa struttura; tuttavia, ogni settore può contenere istruzioni di avvio-strapping distinte (vedere Tabella 6). Gli agenti di avvio, ad esempio le istruzioni di strapping di avvio nel settore principale dell'avvio, le implementazioni alternative del BIOS o il firmware di un sistema incorporato, possono caricare questi settori ed eseguire le istruzioni che contengono.

I settori di avvio estesi di backup sono un backup dei principali settori di avvio esteso e hanno la stessa struttura (vedere La tabella 6).

Prima di eseguire le istruzioni dei settori di avvio esteso main o backup, le implementazioni devono verificare il loro contenuto assicurando che il campo ExtendedBootSignature di ogni settore contenga il valore previsto.

Anche se l'operazione di formato iniziale inizializza il contenuto dei settori di avvio esteso main e backup, le implementazioni possono aggiornare questi settori (e aggiorneranno anche i rispettivi checksum di avvio) in base alle esigenze.

Tabella 6 Struttura del settore di avvio esteso

Nome campo

Offset

(byte)

Dimensione

(byte)

 Commenti
ExtendedBootCode 0 2BytePerSectorShift - 4

Questo campo è obbligatorio e la sezione 3.2.1 definisce il contenuto.

Nota: i settori di avvio principale e di backup contengono entrambi il campo BytePerSectorShift.
ExtendedBootSignature 2BytePerSectorShift - 4 4

Questo campo è obbligatorio e la sezione 3.2.2 definisce il contenuto.

Nota: i settori di avvio principale e di backup contengono entrambi il campo BytePerSectorShift.

Campo ExtendedBootCode 3.2.1

Il campo ExtendedBootCode contiene istruzioni di avvio. Le implementazioni possono popolare questo campo con le istruzioni della CPU necessarie per l'avvio a strappo di un sistema computer. Le implementazioni che non forniscono istruzioni di strapping di avvio inizializzeranno ogni byte in questo campo fino a 00h nell'ambito dell'operazione di formato.

Campo ExtendedBootSignature 3.2.2

Il campo ExtendedBootSignature descrive se la finalità del settore specificato è che sia un settore di avvio esteso o meno.

Il valore valido per questo campo è AA550000h. Qualsiasi altro valore in questo campo invalida il rispettivo settore di avvio esteso main o backup. Le implementazioni devono verificare il contenuto di questo campo prima di dipendere da qualsiasi altro campo nel rispettivo settore di avvio esteso.

3.3 Parametri OEM principali e di backup

L'area secondaria Dei parametri OEM principale contiene dieci strutture di parametri che possono contenere informazioni specifiche del produttore (vedere Tabella 7). Ognuna delle dieci strutture dei parametri deriva dal modello Parametri generici (vedere la sezione 3.3.2). I produttori possono derivare strutture di parametri personalizzati dal modello Parametri generici. Questa specifica definisce due strutture di parametri: Parametri Null (vedere la sezione 3.3.3) e i parametri Flash (vedere la sezione 3.3.4).

I parametri OEM di backup sono un backup dei parametri OEM principali e hanno la stessa struttura (vedere Tabella 7).

Prima di usare il contenuto dei parametri OEM main o backup, le implementazioni verificheranno il contenuto convalidando il rispettivo checksum di avvio.

I produttori devono popolare i parametri OEM main e backup con le proprie strutture di parametri personalizzati, se presenti e qualsiasi altra struttura di parametri. Le operazioni di formato successive conservano il contenuto dei parametri OEM main e backup.

Le implementazioni possono aggiornare i parametri OEM main e backup in base alle esigenze e aggiornare anche i rispettivi checksum di avvio.

Tabella 7 Struttura dei parametri OEM

Nome campo

Offset

(byte)

Dimensione

(byte)

 Commenti
Parametri[0] 0 48 Questo campo è obbligatorio e la sezione 3.3.1 definisce il contenuto.

.

.

.

.

.

.

.

.

.

.

.

.
Parametri[9] 432 48 Questo campo è obbligatorio e la sezione 3.3.1 definisce il contenuto.
Riservato 480 2BytePerSectorShift - 480

Questo campo è obbligatorio e il relativo contenuto è riservato.

Nota: i settori di avvio principale e di backup contengono entrambi il campo BytePerSectorShift.

3.3.1 Parametri[0] ... Parametri[9]

Ogni campo Parametri in questa matrice contiene una struttura di parametri, che deriva dal modello Parametri generici (vedere sezione 3.3.2). Qualsiasi campo Parametri inutilizzati deve essere descritto come contenente una struttura Di parametri Null (vedere la sezione 3.3.3).

Modello di parametri generici 3.3.2

Il modello Parametri generici fornisce la definizione di base di una struttura di parametri (vedere Tabella 8). Tutte le strutture dei parametri derivano da questo modello. Il supporto per questo modello di parametri generici è obbligatorio.

Modello di parametri generici tabella 8

Nome campo

Offset

(byte)

Dimensione

(byte)

 Commenti
ParametriGuid 0 16 Questo campo è obbligatorio e la sezione 3.3.2.1 definisce il contenuto.
CustomDefined 16 32 Questo campo è obbligatorio e le strutture che derivano da questo modello definiscono il relativo contenuto.
Campo Parametri 3.3.2.1

Il campo ParametersGuid descrive un GUID che determina il layout del resto della struttura dei parametri specificati.

Tutti i valori possibili per questo campo sono validi; Tuttavia, i produttori devono usare uno strumento di generazione GUID, ad esempio GuidGen.exe, per selezionare un GUID durante la derivazione di strutture di parametri personalizzati da questo modello.

Parametri Null 3.3.3

La struttura Parametri Null deriva dal modello Parametri generici (vedere la sezione 3.3.2) e descrive un campo Parametri inutilizzati (vedere Tabella 9). Quando si crea o si aggiorna la struttura dei parametri OEM, le implementazioni popolano i campi Parametri inutilizzati con la struttura Parametri Null. Inoltre, quando si crea o si aggiorna la struttura dei parametri OEM, le implementazioni devono consolidare le strutture dei parametri Null alla fine della matrice, lasciando così tutte le altre strutture parametri all'inizio della struttura parametri OEM.

Il supporto per la struttura Parametri Null è obbligatorio.

Struttura parametri Null tabella 9

Nome campo

Offset

(byte)

Dimensione

(byte)

 Commenti
ParametriGuid 0 16 Questo campo è obbligatorio e la sezione 3.3.3.1 definisce il contenuto.
Riservato 16 32 Questo campo è obbligatorio e il relativo contenuto è riservato.
Campo Parametri 3.3.3.1

Il campo ParametersGuid deve essere conforme alla definizione fornita dal modello Parametri generici (vedere la sezione 3.3.2.1).

Il valore valido per questo campo, nella notazione GUID, è {00000000-0000-0000-0000-000000000000}.

3.3.4 Parametri flash

La struttura dei parametri Flash deriva dal modello Parametri generici (vedere la sezione 3.3.2) e contiene parametri per i supporti flash (vedere Tabella 10). I produttori di dispositivi di archiviazione basati su flash possono popolare un campo Parametri (preferibilmente il campo Parametri[0] con questa struttura di parametri. Le implementazioni possono usare le informazioni nella struttura Parametri Flash per ottimizzare le operazioni di accesso durante letture/scritture e per l'allineamento delle strutture del file system che durano la formattazione del supporto.

Il supporto per la struttura Parametri Flash è facoltativo.

Struttura parametri Flash tabella 10

Nome campo

Offset

(byte)

Dimensione

(byte)

 Commenti
ParametriGuid 0 16 Questo campo è obbligatorio e la sezione 3.3.4.1 definisce il contenuto.
CancelBlockSize 16 4 Questo campo è obbligatorio e la sezione 3.3.4.2 definisce il relativo contenuto.
PageSize 20 4 Questo campo è obbligatorio e la sezione 3.3.4.3 definisce il relativo contenuto.
SpareSectors 24 4 Questo campo è obbligatorio e la sezione 3.3.4.4 definisce il contenuto.
RandomAccessTime 28 4 Questo campo è obbligatorio e la sezione 3.3.4.5 definisce il contenuto.
ProgrammingTime 32 4 Questo campo è obbligatorio e la sezione 3.3.4.6 definisce il contenuto.
ReadCycle 36 4 Questo campo è obbligatorio e la sezione 3.3.4.7 definisce il contenuto.
WriteCycle 40 4 Questo campo è obbligatorio e la sezione 3.3.4.8 definisce il contenuto.
Riservato 44 4 Questo campo è obbligatorio e il relativo contenuto è riservato.

Tutti i valori possibili per tutti i campi Parametri Flash, ad eccezione del campo ParametersGuid, sono validi. Tuttavia, il valore 0 indica che il campo è effettivamente senza significato (le implementazioni ignorano il campo specificato).

Campo Parametri 3.3.4.1

Il campo ParametersGuid deve essere conforme alla definizione fornita nel modello Parametri generici (vedere la sezione 3.3.2.1).

Il valore valido per questo campo, nella notazione GUID, è {0A0C7E46-3399-4021-90C8-FA6D389C4BA2}.

Campo CancelBlockSize 3.3.4.2

Il campo CancelBlockSize descrive le dimensioni, in byte, del blocco di cancellazione del supporto flash.

Campo PageSize 3.3.4.3

Il campo PageSize descrive le dimensioni, in byte della pagina del supporto flash.

3.3.4.4 Campo SpareSectors

Il campo SpareSectors descrive il numero di settori disponibili per le sue operazioni interne di spaziatura.

Campo CasualAccessTime 3.3.4.5

Il campo RandomAccessTime descrive il tempo medio di accesso casuale del supporto flash, in nanosecondi.

Campo ProgrammingTime 3.3.4.6

Il campo ProgrammingTime descrive il tempo di programmazione medio del supporto flash, in nanosecondi.

Campo ReadCycle 3.3.4.7

Il campo ReadCycle descrive il tempo medio di lettura del supporto flash, in nanosecondi.

Campo WriteCycle 3.3.4.8

Il campo WriteCycle descrive il tempo medio del ciclo di scrittura, in nanosecondi.

3.4 Aree secondarie main e backup boot checksum

I checksum principale e di avvio di backup contengono uno schema ripetuto del checksum di quattro byte del contenuto di tutte le altre aree secondarie nelle rispettive aree di avvio. Il calcolo checksum non include i campi VolumeFlags e PercentInUse nel rispettivo settore di avvio (vedere la figura 1). Il modello ripetuto del checksum a quattro byte riempie il rispettivo sotto-area checksum di avvio dall'inizio alla fine dell'area secondaria.

Prima di usare il contenuto di una delle altre aree secondarie nelle aree di avvio principale o di backup, le implementazioni verificheranno il contenuto convalidando il rispettivo checksum di avvio.

Mentre l'operazione di formato iniziale popola sia i checksum principale che di backup con il modello di checksum ripetuto, le implementazioni aggiorneranno questi settori come contenuto degli altri settori nelle rispettive aree di avvio cambiano.

Figura 1 Calcolo checksum avvio

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 Area tabella allocazione file

L'area FAT (File Allocation Table) può contenere fino a due FTS, una nell'area secondaria FIRST FAT e un'altra nell'area secondaria FAT seconda. Il campo NumberOfFats descrive il numero di fats contenute in questa area. I valori validi per il campo NumberOfFats sono 1 e 2. Pertanto, la prima sotto-area FAT contiene sempre un FAT. Se il campo NumberOfFats è due, la seconda sotto-area FAT contiene anche un valore FAT.

Il campo ActiveFat del campo VolumeFlags descrive quale FAT è attivo. Solo il campo VolumeFlags nel settore principale di avvio è corrente. Le implementazioni considerano il FAT che non è attivo come non aggiornato. L'uso del FAT inattivo e il passaggio tra le reti FATS è specifico.

4.1 Prime e Second FAT Sub-regions

Un fat descrive le catene di cluster nell'heap cluster (vedere Tabella 11). Una catena di cluster è una serie di cluster che forniscono spazio per registrare il contenuto di file, directory e altre strutture del file system. Un FAT rappresenta una catena di cluster come elenco collegato in modo singly-linked di indici del cluster. Ad eccezione delle prime due voci, ogni voce in un FAT rappresenta esattamente un cluster.

Tabella 11 Struttura tabella allocazione file

Nome campo

Offset

(byte)

Dimensione

(byte)

 Commenti
FatEntry[0] 0 4 Questo campo è obbligatorio e la sezione 4.1.1 definisce il contenuto.
FatEntry[1] 4 4 Questo campo è obbligatorio e la sezione 4.1.2 definisce il contenuto.
FatEntry[2] 8 4 Questo campo è obbligatorio e la sezione 4.1.3 definisce il contenuto.

.

.

.

.

.

.

.

.

.

.

.

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

Questo campo è obbligatorio e la sezione 4.1.3 definisce il contenuto.

ClusterCount + 1 non può mai superare FFFFFFF6h.

Nota: i settori di avvio principale e di backup contengono entrambi il campo ClusterCount.
ExcessSpace (ClusterCount + 2) * 4 (FatLength * 2BytePerSectorShift) – ((ClusterCount + 2) * 4)

Questo campo è obbligatorio e il relativo contenuto, se presente, non sono definiti.

Nota: i settori di avvio principale e di backup contengono entrambi i campi ClusterCount, FatLength e BytesPerSectorShift.

4.1.1 Campo FatEntry[0]

Il campo FatEntry[0] descrive il tipo di supporto nel primo byte (byte più basso) e deve contenere FFh nei tre byte rimanenti.

Il tipo di supporto (il primo byte) deve essere F8h.

4.1.2 FatEntry[1] Campo

Il campo FatEntry[1] esiste solo a causa della precedenza storica e non descrive nulla di interesse.

Il valore valido per questo campo è FFFFFFFFh. Le implementazioni inizializzano questo campo al relativo valore prescritto e non devono usare questo campo per alcun scopo. Le implementazioni non devono interpretare questo campo e conservarne il contenuto tra operazioni che modificano i campi circostanti.

4.1.3 FatEntry[2] ... Campi FatEntry[ClusterCount+1]

Ogni campo FatEntry in questa matrice rappresenta un cluster nell'heap del cluster. FatEntry[2] rappresenta il primo cluster nell'heap cluster e FatEntry[ClusterCount+1] rappresenta l'ultimo cluster nell'heap del cluster.

L'intervallo valido di valori per questi campi deve essere:

  • Tra 2 e ClusterCount + 1, inclusivamente, che punta alla successiva fatEntry nella catena di cluster specificata; il dato FatEntry non punta ad alcun FatEntry che lo precede nella catena di cluster specificata

  • Esattamente FFFFFFFFF7h, che contrassegna il cluster corrispondente di FatEntry come "cattivo"

  • FFFFFFFFh, che contrassegna il cluster corrispondente di FatEntry come ultimo cluster di una catena di cluster; si tratta dell'unico valore valido per l'ultima fatEntry di qualsiasi catena di cluster specificata

5 Area dati

L'area Dati contiene l'heap cluster, che fornisce spazio gestito per strutture, directory e file del file system.

5.1 Area secondaria del cluster Heap

La struttura dell'Heap cluster è molto semplice (vedere Tabella 12); ogni serie consecutiva di settori descrive un cluster, come definisce il campo SectorsPerClusterShift. Importante, il primo cluster dell'heap cluster ha indice due, che corrisponde direttamente all'indice di FatEntry[2].

In un volume exFAT, una bitmap di allocazione (vedere la sezione 7.1.5) mantiene il record dello stato di allocazione di tutti i cluster. Si tratta di una differenza significativa rispetto ai predecessori di exFAT (FAT12, FAT16 e FAT32), in cui un FAT ha mantenuto un record dello stato di allocazione di tutti i cluster nell'heap del cluster.

Struttura heap cluster tabella 12

Nome campo

Offset

(settore)

Dimensione

(settori)

 Commenti
Cluster[2] ClusterHeapOffset 2SettoriPerClusterShift

Questo campo è obbligatorio e la sezione 5.1.1 definisce il contenuto.

Nota: i settori di avvio principale e di backup contengono entrambi i campi ClusterHeapOffset e SectorsPerClusterShift.

.

.

.

.

.

.

.

.

.

.

.

.
Cluster[ClusterCount+1] ClusterHeapOffset + (ClusterCount - 1) * 2SettoriPerClusterShift 2SettoriPerClusterShift

Questo campo è obbligatorio e la sezione 5.1.1 definisce il contenuto.

Nota: i settori di avvio principale e di backup contengono entrambi i campi ClusterCount, ClusterHeapOffset e SectorsPerClusterShift.

5.1.1 Cluster[2] ... Campi cluster[ClusterCount+1]

Ogni campo Cluster in questa matrice è una serie di settori contigui, le cui dimensioni sono definite dal campo SectorsPerClusterShift.

Struttura della directory 6

Il file system exFAT usa un approccio ad albero di directory per gestire le strutture e i file del file system presenti nell'heap del cluster. Le directory hanno una relazione uno-a-molti tra padre e figlio nell'albero della directory.

La directory a cui fa riferimento il campo FirstClusterOfRootDirectory è la radice dell'albero della directory. Tutte le altre directory derivano dalla directory radice in modo collegato in modo singly-linked.

Ogni directory è costituita da una serie di voci di directory (vedere Tabella 13).

Una o più voci di directory si combinano in un set di voci di directory che descrive un elemento di interesse, ad esempio una struttura del file system, una sotto directory o un file.

Tabella 13 Struttura directory

Nome campo

Offset

(byte)

Dimensione

(byte)

 Commenti
DirectoryEntry[0] 0 32 Questo campo è obbligatorio e la sezione 6.1 definisce il contenuto.

.

.

.

.

.

.

.

.

.

.

.

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

Questo campo è obbligatorio e la sezione 6.1 definisce il contenuto.

N, il numero di campi DirectoryEntry è la dimensione, in byte, della catena di cluster che contiene la directory specificata, suddivisa per le dimensioni di un campo DirectoryEntry, 32 byte.

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

Ogni campo DirectoryEntry in questa matrice deriva dal modello Generic DirectoryEntry (vedere la sezione 6.2).

6.2 Modello generico DirectoryEntry

Il modello Generic DirectoryEntry fornisce la definizione di base per le voci della directory (vedere Tabella 14). Tutte le strutture di voce della directory derivano da questo modello e solo le strutture di voce della directory definite da Microsoft sono valide (exFAT non dispone di provisioning per le strutture di voce della directory definite dal produttore, ad eccezione di quanto definito nella sezione 7.8 e sezione 7.9). La possibilità di interpretare il modello Generic DirectoryEntry è obbligatoria.

Tabella 14 Modello generico DirectoryEntry

Nome campo

Offset

(byte)

Dimensione

(byte)

 Commenti
Entrytype 0 1 Questo campo è obbligatorio e la sezione 6.2.1 definisce il contenuto.
CustomDefined 1 19 Questo campo è obbligatorio e le strutture che derivano da questo modello possono definire il relativo contenuto.
FirstCluster 20 4 Questo campo è obbligatorio e la sezione 6.2.2 definisce il contenuto.
Lunghezza dati 24 8 Questo campo è obbligatorio e la sezione 6.2.3 definisce il contenuto.

Campo EntryType 6.2.1

Il campo EntryType ha tre modalità di utilizzo che il valore del campo definisce (vedere l'elenco seguente).

  • 00h, che è un marcatore end-of-directory e le condizioni seguenti si applicano:

    • Tutti gli altri campi nella determinata DirectoryEntry sono effettivamente riservati

    • Tutte le voci di directory successive nella directory specificata sono anche indicatori end-of-directory

    • I marcatori di fine directory sono validi solo all'esterno dei set di voci di directory

    • Le implementazioni possono sovrascrivere i marcatori end-of-directory in base alle esigenze

  • Tra 01h e 7Fh inclusivamente, che è un marcatore di voce di directory inutilizzato e le condizioni seguenti si applicano:

    • Tutti gli altri campi nella determinata DirectoryEntry sono effettivamente non definiti

    • Le voci della directory inutilizzate sono valide solo all'esterno dei set di voci di directory

    • Le implementazioni possono sovrascrivere le voci di directory inutilizzate in base alle esigenze

    • Questo intervallo di valori corrisponde al campo InUse (vedere sezione 6.2.1.4) contenente il valore 0

  • Tra 81h e FFh inclusivamente, ovvero una voce di directory regolare e le condizioni seguenti si applicano:

    • Il contenuto del campo EntryType (vedere Tabella 15) determina il layout della struttura DirectoryEntry

    • Questo intervallo di valori e solo questo intervallo di valori, sono validi all'interno di un set di voci di directory

    • Questo intervallo di valori corrisponde direttamente al campo InUse (vedere la sezione 6.2.1.4) contenente il valore 1

Per evitare modifiche apportate al campo InUse (vedere sezione 6.2.1.4) erroneamente risultante da un marcatore di directory end-of-directory, il valore 80h non è valido.

Tabella 15 Struttura del campo EntryType generico

Nome campo

Offset

(bit)

Dimensione

(bit)

 Commenti
TypeCode 0 5 Questo campo è obbligatorio e la sezione 6.2.1.1 definisce il contenuto.
TypeImportance 5 1 Questo campo è obbligatorio e la sezione 6.2.1.2 definisce il contenuto.
TypeCategory 6 1 Questo campo è obbligatorio e la sezione 6.2.1.3 definisce il contenuto.
InUse 7 1 Questo campo è obbligatorio e la sezione 6.2.1.4 definisce il contenuto.
Campo TypeCode 6.2.1.1

Il campo TypeCode descrive parzialmente il tipo specifico della voce di directory specificata. Questo campo, oltre ai campi TypeImportance e TypeCategory (vedere la sezione 6.2.1.2 e la sezione 6.2.1.3, rispettivamente) identificare in modo univoco il tipo della voce di directory specificata.

Tutti i valori possibili di questo campo sono validi, a meno che i campi TypeImportance e TypeCategory contengano entrambi il valore 0; in questo caso, il valore 0 non è valido per questo campo.

Campo 6.2.1.2 TypeImportance

Il campo TypeImportance descrive l'importanza della voce di directory specificata.

I valori validi per questo campo devono essere:

Campo TypeCategory 6.2.1.3

Il campo TypeCategory descrive la categoria della voce di directory specificata.

I valori validi per questo campo devono essere:

  • 0, il che significa che la voce di directory specificata è primaria (vedere la sezione 6.3)

  • 1, che significa che la voce di directory specificata è secondaria (vedere la sezione 6.4)

Campo InUse 6.2.1.4

Il campo InUse descrive se la voce di directory specificata in uso o meno.

I valori validi per questo campo devono essere:

  • 0, che significa che la voce di directory specificata non è in uso; ciò significa che la struttura specificata è effettivamente una voce di directory inutilizzata

  • 1, il che significa che la voce di directory specificata è in uso; ciò significa che la struttura specificata è una voce di directory regolare

6.2.2 Campo FirstCluster

Il campo FirstCluster contiene l'indice del primo cluster di un'allocazione nell'heap cluster associato alla voce di directory specificata.

L'intervallo di valori valido per questo campo deve essere:

  • Esattamente 0, che significa che nessuna allocazione del cluster esiste

  • Tra 2 e ClusterCount + 1, ovvero l'intervallo di indici di cluster validi

Le strutture che derivano da questo modello possono ridefinire sia i campi FirstCluster che DataLength, se un'allocazione del cluster non è compatibile con la struttura derivata.

6.2.3 Campo DataLength

Il campo DataLength descrive le dimensioni, in byte, dei dati contenuti nell'allocazione del cluster associata.

L'intervallo di valori valido per questo campo è:

  • Almeno 0; se il campo FirstCluster contiene il valore 0, l'unico valore valido del campo è 0

  • Al massimo ClusterCount * 2SectorsPerClusterShift* 2BytePerSectorShift

Le strutture che derivano da questo modello possono ridefinire sia i campi FirstCluster che DataLength, se un'allocazione del cluster non è possibile per la struttura derivata.

6.3 Modello primario generico DirectoryEntry

La prima voce di directory in un set di voci di directory deve essere una voce di directory primaria. Tutte le voci di directory successive, se presenti, nel set di voci di voce della directory devono essere voci di directory secondarie (vedere la sezione 6.4).

La possibilità di interpretare il modello Generic Primary DirectoryEntry è obbligatoria.

Tutte le strutture di voce di directory primarie derivano dal modello Generic Primary DirectoryEntry (vedere Tabella 16), che deriva dal modello Generic DirectoryEntry (vedere sezione 6.2).

Tabella 16 Modello di directory primaria genericaEntry

Nome campo

Offset

(byte)

Dimensione

(byte)

 Commenti
Entrytype 0 1 Questo campo è obbligatorio e la sezione 6.3.1 definisce il contenuto.
SecondaryCount 1 1 Questo campo è obbligatorio e la sezione 6.3.2 definisce il contenuto.
SetChecksum 2 2 Questo campo è obbligatorio e la sezione 6.3.3 definisce il contenuto.
GeneralPrimaryFlags 4 2 Questo campo è obbligatorio e la sezione 6.3.4 definisce il contenuto.
CustomDefined 6 14 Questo campo è obbligatorio e strutture che derivano da questo modello definiscono il relativo contenuto.
FirstCluster 20 4 Questo campo è obbligatorio e la sezione 6.3.5 definisce il contenuto.
Lunghezza dati 24 8 Questo campo è obbligatorio e la sezione 6.3.6 definisce il contenuto.

Campo EntryType 6.3.1

Il campo EntryType deve essere conforme alla definizione fornita nel modello Generic DirectoryEntry (vedere la sezione 6.2.1).

Campo TypeCode 6.3.1.1

Il campo TypeCode deve essere conforme alla definizione fornita nel modello Generic DirectoryEntry (vedere la sezione 6.2.1.1).

Campo TypeImportance 6.3.1.2

Il campo TypeImportance deve essere conforme alla definizione fornita nel modello Generic DirectoryEntry (vedere la sezione 6.2.1.2).

6.3.1.2.1 Voci della directory primaria critica

Le voci della directory primaria critiche contengono informazioni critiche per la gestione corretta di un volume exFAT. Solo la directory radice contiene voci di directory primarie critiche (le voci della directory file sono un'eccezione, vedere Sezione 7.4).

La definizione delle voci di directory primaria critiche è correlata al numero di revisione exFAT principale. Le implementazioni supportano tutte le voci di directory primarie critiche e registrano solo le strutture di voce della directory primaria critiche definite da questa specifica.

6.3.1.2.2 Voci della directory primaria benigna

Le voci della directory primaria benigne contengono informazioni aggiuntive che possono essere utili per la gestione di un volume exFAT. Qualsiasi directory può contenere voci di directory primaria benigne.

La definizione delle voci della directory primaria benigna correla al numero di revisione exFAT secondario. Il supporto per qualsiasi voce di directory primaria benigna questa specifica o qualsiasi specifica successiva, definisce è facoltativo. Una voce di directory primaria non riconosciuta esegue il rendering dell'intera voce di directory impostata come non riconosciuta (oltre la definizione dei modelli di voci di directory applicabili).

Campo TypeCategory 6.3.3.3

Il campo TypeCategory deve essere conforme alla definizione fornita nel modello Generic DirectoryEntry (vedere la sezione 6.2.1.3).

Per questo modello, il valore valido per questo campo deve essere 0.

Campo InUse 6.3.1.4

Il campo InUse deve essere conforme alla definizione fornita nel modello Generic DirectoryEntry (vedere la sezione 6.2.1.4).

6.3.2 Campo secondarioCount

Il campo SecondaryCount descrive il numero di voci di directory secondarie che seguono immediatamente la voce di directory primaria specificata. Queste voci di directory secondarie, insieme alla voce di directory primaria specificata, costituiscono il set di voci di directory.

L'intervallo di valori valido per questo campo deve essere:

  • Almeno 0, il che significa che questa voce di directory primaria è l'unica voce nel set di voci di directory

  • Al massimo 255, ovvero le voci di directory successive 255 e questa voce di directory primaria include il set di voci di directory

Le strutture di voce della directory primaria critiche che derivano da questo modello possono ridefinire sia i campi SecondaryCount che SetChecksum.

Campo SetChecksum 6.3.3

Il campo SetChecksum contiene il checksum di tutte le voci della directory nel set di voci di directory specificato. Tuttavia, il checksum esclude questo campo (vedere la figura 2). Le implementazioni devono verificare che il contenuto di questo campo sia valido prima di usare qualsiasi altra voce di directory nel set di voci di directory specificato.

Le strutture di voce della directory primaria critiche che derivano da questo modello possono ridefinire sia i campi SecondaryCount che SetChecksum.

Figura 2 EntrySetChecksum Computation

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 GeneralePrimaryFlags Field

Il campo GeneralPrimaryFlags contiene flag (vedere Tabella 17).

Le strutture di voce della directory primaria critiche che derivano da questo modello possono ridefinire questo campo.

Tabella 17 Generic GeneralPrimaryFlags Field Structure

Nome campo

Offset

(bit)

Dimensione

(bit)

 Commenti
AllocazionePossible 0 1 Questo campo è obbligatorio e la sezione 6.3.4.1 definisce il contenuto.
NoFatChain 1 1 Questo campo è obbligatorio e la sezione 6.3.4.2 definisce il contenuto.
CustomDefined 2 14 Questo campo è obbligatorio e le strutture che derivano da questo modello possono definire questo campo.
6.3.4.1 Campo allocazionePossible

Il campo AllocationPossible descrive se un'allocazione nell'heap del cluster è possibile per la voce di directory specificata.

I valori validi per questo campo devono essere:

  • 0, il che significa che un'allocazione associata di cluster non è possibile e i campi FirstCluster e DataLength sono effettivamente non definiti (strutture che derivano da questo modello possono ridefinire tali campi)

  • 1, il che significa che è possibile un'allocazione associata dei cluster e i campi FirstCluster e DataLength sono definiti

Campo NoFatChain 6.3.4.2

Il campo NoFatChain indica se il fat attivo descrive la catena di cluster dell'allocazione specificata.

I valori validi per questo campo devono essere:

  • 0, che significa che le voci FAT corrispondenti per la catena di cluster di allocazione sono valide e le implementazioni devono interpretarle; se il campo AllocationPossible contiene il valore 0 o se il campo AllocationPossible contiene il valore 1 e il campo FirstCluster contiene il valore 0, l'unico valore valido del campo è 0

  • 1, il che significa che l'allocazione associata è una serie contigua di cluster; le voci FAT corrispondenti per i cluster non sono valide e le implementazioni non verranno interpretate; le implementazioni possono usare l'equazione seguente per calcolare le dimensioni dell'allocazione associata: DataLength / (2SectorsPerClusterShift* 2BytePerSectorShift) arrotondate fino all'intero più vicino

Se le strutture di voce della directory primaria critiche che derivano da questo modello ridefiniscono il campo GeneralPrimaryFlags, le voci FAT corrispondenti per la catena di cluster di allocazione associata sono valide.

6.3.5 Campo FirstCluster

Il campo FirstCluster è conforme alla definizione fornita nel modello Generic DirectoryEntry (vedere la sezione 6.2.2).

Se il bit NoFatChain è 1, FirstCluster deve puntare a un cluster valido nell'heap del cluster.

Le strutture di voce della directory primaria critiche che derivano da questo modello possono ridefinire i campi FirstCluster e DataLength. Altre strutture che derivano da questo modello possono ridefinire i campi FirstCluster e DataLength solo se il campo AllocationPossible contiene il valore 0.

6.3.6 Campo DataLength

Il campo DataLength deve essere conforme alla definizione fornita nel modello Generic DirectoryEntry (vedere la sezione 6.2.3).

Se il bit NoFatChain è 1, DataLength non deve essere zero. Se il campo FirstCluster è zero, DataLength deve anche essere zero.

Le strutture di voce della directory primaria critiche che derivano da questo modello possono ridefinire i campi FirstCluster e DataLength. Altre strutture che derivano da questo modello possono ridefinire i campi FirstCluster e DataLength solo se il campo AllocationPossible contiene il valore 0.

6.4 Modello di directory secondaria genericaEntry

Lo scopo centrale delle voci della directory secondaria consiste nel fornire informazioni aggiuntive su un set di voci di directory. La possibilità di interpretare il modello Generic Secondary DirectoryEntry è obbligatorio.

La definizione delle voci della directory secondaria critica e benigna correla al numero di revisione di exFAT secondario. Il supporto per qualsiasi voce di directory secondaria critica o benigna questa specifica, o le specifiche successive, definisce è facoltativo.

Tutte le strutture di voce di directory secondarie derivano dal modello Generic Secondary DirectoryEntry (vedere Tabella 18), che deriva dal modello Generic DirectoryEntry (vedere sezione 6.2).

Tabella 18 Modello di directory secondaria genericaEntry

Nome campo

Offset

(byte)

Dimensione

(byte)

 Commenti
Entrytype 0 1 Questo campo è obbligatorio e la sezione 6.4.1 definisce il contenuto.
GeneraleSecondaryFlags 1 1 Questo campo è obbligatorio e la sezione 6.4.2 definisce il contenuto.
CustomDefined 2 18 Questo campo è obbligatorio e strutture che derivano da questo modello definiscono il relativo contenuto.
FirstCluster 20 4 Questo campo è obbligatorio e la sezione 6.4.3 definisce il contenuto.
Lunghezza dati 24 8 Questo campo è obbligatorio e la sezione 6.4.4 definisce il contenuto.

Campo EntryType 6.4.1

Il campo EntryType deve essere conforme alla definizione fornita nel modello Generic DirectoryEntry (vedere la sezione 6.2.1)

Campo TypeCode 6.4.1.1

Il campo TypeCode deve essere conforme alla definizione fornita nel modello Generic DirectoryEntry (vedere la sezione 6.2.1.1).

Campo TypeImportance 6.4.1.2

Il campo TypeImportance deve essere conforme alla definizione fornita nel modello Generic DirectoryEntry (vedere la sezione 6.2.1.2).

6.4.1.2.1 Voci della directory secondaria critica

Le voci di directory secondarie critiche contengono informazioni critiche per la gestione corretta del set di voci di directory. Anche se il supporto per qualsiasi voce di directory secondaria critica specifica è facoltativo, una voce di directory critica non riconosciuta esegue il rendering dell'intero set di voci di directory come non riconosciuto (oltre la definizione dei modelli di voce di directory applicabili).

Tuttavia, se un set di voci di directory contiene almeno una voce di directory secondaria critica che un'implementazione non riconosce, l'implementazione interpreterà al massimo i modelli delle voci di directory nel set di voci di directory e non i dati associati ad alcuna voce di directory nel set di voci di directory contiene (le voci di directory sono un'eccezione, vedere la sezione 7.4).

6.4.1.2.2 Voci di directory secondarie non dannose

Le voci di directory secondarie non dannose contengono informazioni aggiuntive che possono essere utili per la gestione del set di voci di directory contenitore. Il supporto per qualsiasi voce di directory secondaria non dannosa specifica è facoltativo. Le voci di directory secondarie non riconosciute non riconosciute non eseguono il rendering dell'intera voce di directory impostata come non riconosciuta.

Le implementazioni possono ignorare qualsiasi voce secondaria non dannosa che non riconosce.

6.4.1.3 TypeCategory Field

Il campo TypeCategory deve essere conforme alla definizione fornita nel modello DirectoryEntry generico (vedere la sezione 6.2.1.3).

Per questo modello, il valore valido per questo campo è 1.

6.4.1.4 Campo Uso

Il campo InUse deve essere conforme alla definizione fornita nel modello DirectoryEntry generico (vedere la sezione 6.2.1.4).

6.4.2 Campo GeneraleSecondaryFlags

Il campo GeneralSecondaryFlags contiene flag (vedere la tabella 19).

Tabella 19 Generic GeneralSecondaryFlags Field Structure

Nome campo

Offset

(bit)

Dimensione

(bit)

 Commenti
AllocationPossible 0 1 Questo campo è obbligatorio e la sezione 6.4.2.1 ne definisce il contenuto.
NoFatChain 1 1 Questo campo è obbligatorio e la sezione 6.4.2.2 ne definisce il contenuto.
CustomDefined 2 6 Questo campo è obbligatorio e le strutture che derivano da questo modello possono definire questo campo.
6.4.2.1 Campo AllocationPossible

Il campo AllocationPossible deve avere la stessa definizione del campo con lo stesso nome nel modello Generic Primary DirectoryEntry (vedere la sezione 6.3.4.1).

Campo NoFatChain 6.4.2.2

Il campo NoFatChain avrà la stessa definizione del campo con lo stesso nome nel modello Generic Primary DirectoryEntry (vedere sezione 6.3.4.2).

6.4.3 Campo FirstCluster

Il campo FirstCluster deve essere conforme alla definizione fornita nel modello DirectoryEntry generico (vedere la sezione 6.2.2).

Se il bit NoFatChain è 1, FirstCluster deve puntare a un cluster valido nell'heap del cluster.

6.4.4 Campo DataLength

Il campo DataLength deve essere conforme alla definizione fornita nel modello DirectoryEntry generico (vedere la sezione 6.2.3).

Se il bit NoFatChain è 1, DataLength non deve essere zero. Se il campo FirstCluster è zero, DataLength deve anche essere zero.

7 Definizioni delle voci di directory

La revisione 1.00 del file system exFAT definisce le voci di directory seguenti:

7.1 Voce della directory bitmap di allocazione

Nel file system exFAT, un FAT non descrive lo stato di allocazione dei cluster; piuttosto, una bitmap di allocazione fa. Le bitmap di allocazione esistono nell'heap del cluster (vedere la sezione 7.1.5) e contengono voci di directory primarie critiche corrispondenti nella directory radice (vedere la tabella 20).

Il campo NumberOfFats determina il numero di voci di directory bitmap di allocazione valide nella directory radice. Se il campo NumberOfFats contiene il valore 1, l'unico numero valido di voci della directory Bitmap di allocazione è 1. Inoltre, la voce di directory Bitmap di allocazione è valida solo se descrive la prima bitmap di allocazione (vedere la sezione 7.1.2.1). Se il campo NumberOfFats contiene il valore 2, l'unico numero valido di voci della directory Bitmap di allocazione è 2. Inoltre, le due voci della directory Bitmap di allocazione sono valide solo se una descrive la prima bitmap di allocazione e l'altra descrive la seconda bitmap di allocazione.

Tabella 20 Struttura bitmap di allocazione

Nome campo

Offset

(byte)

Dimensione

(byte)

 Commenti
Entrytype 0 1 Questo campo è obbligatorio e la sezione 7.1.1 ne definisce il contenuto.
BitmapFlags 1 1 Questo campo è obbligatorio e la sezione 7.1.2 ne definisce il contenuto.
Riservato 2 18 Questo campo è obbligatorio e il relativo contenuto è riservato.
FirstCluster 20 4 Questo campo è obbligatorio e la sezione 7.1.3 ne definisce il contenuto.
Lunghezza dati 24 8 Questo campo è obbligatorio e la sezione 7.1.4 ne definisce il contenuto.

Campo EntryType 7.1.1

Il campo EntryType deve essere conforme alla definizione fornita nel modello Generic Primary DirectoryEntry (vedere la sezione 6.3.1).

Campo TypeCode 7.1.1.1

Il campo TypeCode deve essere conforme alla definizione fornita nel modello Generic Primary DirectoryEntry (vedere la sezione 6.3.1.1).

Per una voce di directory Bitmap di allocazione, il valore valido per questo campo è 1.

Campo TypeImportance 7.1.1.2

Il campo TypeImportance deve essere conforme alla definizione fornita nel modello Generic Primary DirectoryEntry (vedere la sezione 6.3.1.2).

Per una voce di directory Bitmap di allocazione, il valore valido per questo campo è 0.

Campo TypeCategory 7.1.1.3

Il campo TypeCategory deve essere conforme alla definizione fornita nel modello Generic Primary DirectoryEntry (vedere la sezione 6.3.1.3).

Campo InUse 7.1.1.1.4

Il campo InUse deve essere conforme alla definizione fornita nel modello Generic Primary DirectoryEntry (vedere la sezione 6.3.1.4).

7.1.2 Campo BitmapFlags

Il campo BitmapFlags contiene flag (vedere Tabella 21).

Tabella 21 Struttura campo BitmapFlags

Nome campo

Offset

(bit)

Dimensione

(bit)

 Commenti
BitmapIdentifier 0 1 Questo campo è obbligatorio e la sezione 7.1.2.1 definisce il contenuto.
Riservato 1 7 Questo campo è obbligatorio e il relativo contenuto è riservato.
Campo BitmapIdentifier 7.1.2.1

Il campo BitmapIdentifier indica quale bitmap di allocazione descrive la voce di directory specificata. Le implementazioni useranno la prima bitmap di allocazione insieme al Primo FAT e useranno la seconda bitmap di allocazione in combinazione con il secondo FAT. Il campo ActiveFat descrive quali bitmap DI FAT e allocazione sono attivi.

I valori validi per questo campo devono essere:

  • 0, che significa che la voce di directory specificata descrive la prima bitmap di allocazione

  • 1, ovvero la voce di directory specificata descrive la seconda bitmap di allocazione ed è possibile solo quando NumberOfFats contiene il valore 2

7.1.3 Campo FirstCluster

Il campo FirstCluster deve essere conforme alla definizione fornita nel modello Generic Primary DirectoryEntry (vedere la sezione 6.3.5).

Questo campo contiene l'indice del primo cluster della catena di cluster, come descritto da FAT, che ospita la bitmap di allocazione.

7.1.4 Campo DataLength

Il campo DataCluster deve essere conforme alla definizione fornita nel modello Generic Primary DirectoryEntry (vedere la sezione 6.3.6).

7.1.5 Bitmap allocazione

Una bitmap di allocazione registra lo stato di allocazione dei cluster nell'heap del cluster. Ogni bit in una bitmap di allocazione indica se il cluster corrispondente è disponibile per l'allocazione o meno.

Una bitmap di allocazione rappresenta i cluster dal livello più basso all'indice più alto (vedere Tabella 22). Per motivi cronologici, il primo cluster ha indice 2. Nota: il primo bit nella bitmap è il bit più basso del primo byte.

Tabella 22 Struttura bitmap di allocazione

Nome campo

Offset

(bit)

Dimensione

(bit)

 Commenti
BitmapEntry[2] 0 1 Questo campo è obbligatorio e la sezione 7.1.5.1 definisce il contenuto.

.

.

.

.

.

.

.

.

.

.

.

.
BitmapEntry[ClusterCount+1] ClusterCount - 1 1

Questo campo è obbligatorio e la sezione 7.1.5.1 definisce il contenuto.

Nota: i settori di avvio principale e di backup contengono entrambi il campo ClusterCount.
Riservato ClusterCount (DataLength * 8) - ClusterCount

Questo campo è obbligatorio e il relativo contenuto, se presente, sono riservati.

Nota: i settori di avvio principale e di backup contengono entrambi il campo ClusterCount.
7.1.5.1 BitmapEntry[2] ... Campi BitmapEntry[ClusterCount+1]

Ogni campo BitmapEntry in questa matrice rappresenta un cluster nell'heap del cluster. BitmapEntry[2] rappresenta il primo cluster nell'heap cluster e BitmapEntry[ClusterCount+1] rappresenta l'ultimo cluster nell'heap del cluster.

I valori validi per questi campi devono essere:

  • 0, che descrive il cluster corrispondente come disponibile per l'allocazione

  • 1, che descrive il cluster corrispondente come non disponibile per l'allocazione (un'allocazione del cluster può già utilizzare il cluster corrispondente o il fat attivo può descrivere il cluster corrispondente come non valido)

7.2 Voce della directory tabella up-case

La tabella up-case definisce la conversione da caratteri minuscoli a caratteri maiuscoli. Ciò è importante a causa della voce della directory Nome file (vedere la sezione 7.7) usando caratteri Unicode e il file system exFAT in caso di conservazione senza distinzione tra maiuscole e minuscole. La tabella up-case esiste nell'heap del cluster (vedere la sezione 7.2.5) e ha una voce di directory primaria critica corrispondente nella directory radice (vedere Tabella 23). Il numero valido di voci della directory tabella up-case è 1.

A causa della relazione tra la tabella up-case e i nomi di file, le implementazioni non devono modificare la tabella up-case, ad eccezione delle operazioni di formato.

Tabella 23 struttura DirectoryEntry di tabella up-case

Nome campo

Offset

(byte)

Dimensione

(byte)

 Commenti
Entrytype 0 1 Questo campo è obbligatorio e la sezione 7.2.1 definisce il contenuto.
Reserved1 1 3 Questo campo è obbligatorio e il relativo contenuto è riservato.
TableChecksum 4 4 Questo campo è obbligatorio e la sezione 7.2.2 definisce il contenuto.
Reserved2 8 12 Questo campo è obbligatorio e il relativo contenuto è riservato.
FirstCluster 20 4 Questo campo è obbligatorio e la sezione 7.2.3 definisce il contenuto.
Lunghezza dati 24 8 Questo campo è obbligatorio e la sezione 7.2.4 definisce il contenuto.

Campo EntryType 7.2.1

Il campo EntryType deve essere conforme alla definizione fornita nel modello Generic Primary DirectoryEntry (vedere la sezione 6.3.1).

Campo TypeCode 7.2.1.1

Il campo TypeCode deve essere conforme alla definizione fornita nel modello Generic Primary DirectoryEntry (vedere la sezione 6.3.1.1).

Per la voce della directory tabella up-case, il valore valido per questo campo è 2.

Campo TypeImportance 7.2.1.2

Il campo TypeImportance deve essere conforme alla definizione fornita nel modello Generic Primary DirectoryEntry (vedere la sezione 6.3.1.2).

Per la voce della directory tabella up-case, il valore valido per questo campo è 0.

Campo TypeCategory 7.2.1.3

Il campo TypeCategory deve essere conforme alla definizione fornita nel modello Generic Primary DirectoryEntry (vedere la sezione 6.3.1.3).

Campo InUse 7.2.1.4

Il campo InUse deve essere conforme alla definizione fornita nel modello Generic Primary DirectoryEntry (vedere la sezione 6.3.1.4).

Campo TableChecksum 7.2.2

Il campo TableChecksum contiene il checksum della tabella up-case (che descrivono i campi FirstCluster e DataLength). Le implementazioni devono verificare che il contenuto di questo campo sia valido prima di usare la tabella up-case.

Figura 3 Calcolo 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 Campo FirstCluster

Il campo FirstCluster deve essere conforme alla definizione fornita nel modello Generic Primary DirectoryEntry (vedere la sezione 6.3.5).

Questo campo contiene l'indice del primo cluster della catena di cluster, come descritto da FAT, che ospita la tabella up-case.

7.2.4 Campo DataLength

Il campo DataCluster deve essere conforme alla definizione fornita nel modello Generic Primary DirectoryEntry (vedere la sezione 6.3.6).

Tabella up-case 7.2.5

Una tabella up-case è una serie di mapping di caratteri Unicode. Un mapping di caratteri è costituito da un campo a 2 byte, con l'indice del campo nella tabella up-case che rappresenta il carattere Unicode da inserire in maiuscolo e il campo 2 byte che rappresenta il carattere Unicode in maiuscolo.

I primi 128 caratteri Unicode hanno mapping obbligatori (vedere Tabella 24). Una tabella up-case con qualsiasi altro mapping di caratteri per uno dei primi 128 caratteri Unicode non è valida.

Le implementazioni che supportano solo i caratteri dell'intervallo di mapping obbligatorio possono ignorare i mapping del resto della tabella up-case. Tali implementazioni usano solo i caratteri dell'intervallo di mapping obbligatorio durante la creazione o la ridenominazione dei file (tramite la voce directory Nome file, vedere Sezione 7.7). Quando si aggiornano i nomi di file esistenti, tali implementazioni non devono essere maiuscole e minuscole dall'intervallo di mapping non obbligatorio, ma le lasciano intatte nel nome del file con maiuscole e minuscole risultanti (si tratta di un'up-maiuscola parziale). Quando si confrontano nomi di file, tali implementazioni considerano nomi di file diversi dal nome in confronto solo da caratteri Unicode dall'intervallo di mapping non obbligatorio come equivalente. Anche se tali nomi di file sono solo potenzialmente equivalenti, tali implementazioni non possono garantire che il nome file completamente maiuscolo non si compara con il nome in confronto.

Tabella 24 Voci di tabella up case obbligatoria 128

Indice tabella + 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

(Nota: le voci con mapping up-case non identity sono in grassetto)

Dopo la formattazione di un volume, le implementazioni possono generare una tabella con maiuscole e minuscole in un formato compresso usando la compressione del mapping delle identità, poiché una grande parte dello spazio dei caratteri Unicode non ha alcun concetto di maiuscole e minuscole ( ovvero i caratteri "maiuscole" e "maiuscole" sono equivalenti). Le implementazioni comprimono una tabella up-case rappresentando una serie di mapping di identità con il valore FFFFh seguito con il numero di mapping delle identità.

Ad esempio, un'implementazione può rappresentare i primi 100 mapping di caratteri (64h) con le otto voci seguenti di una tabella con maiuscole e minuscole compresse:

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

Le prime due voci indicano i primi 97 caratteri (61h) (da 0000h a 0060h) hanno mapping di identità. I caratteri successivi, 0061h fino a 0063h, mappano rispettivamente a caratteri 0041h fino a 0043h.

La possibilità di fornire una tabella con maiuscole e minuscole compresse durante la formattazione di un volume è facoltativa. Tuttavia, la possibilità di interpretare sia una tabella non compressa che una tabella con maiuscole e minuscole compresse è obbligatoria. Il valore del campo TableChecksum è sempre conforme al modo in cui la tabella up-case esiste nel volume, che può essere in formato compresso o non compresso.

Quando si formatta un volume, le implementazioni devono registrare la tabella up case consigliata in formato compresso (vedere la tabella 25), per cui il valore del campo TableChecksum è E619D30Dh.

Se un'implementazione definisce la propria tabella di maiuscole e minuscole, compressa o non compressa, tale tabella includerà l'intervallo di caratteri Unicode completo (dai codici carattere 0000h all'inclusione FFFFh).