Specifica file system exFAT

1 Introduzione

Il file system exFAT è il successore di FAT32 nella famiglia di file system FAT. Questa specifica descrive la file system exFAT e fornisce tutte le informazioni necessarie per l'implementazione del file system exFAT.

1,1 obiettivi di progettazione

Il file system exFAT presenta tre obiettivi di progettazione centrali (vedere l'elenco riportato di seguito).

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

    Due dei punti di forza dei file System basati su FAT sono la semplicità relativa e la semplicità di implementazione. Nello spirito dei suoi predecessori, i responsabili dell'implementazione dovrebbero trovare exFAT relativamente semplici e facili da implementare.

  2. Abilitare file e dispositivi di archiviazione di grandi dimensioni.

    Il file system exFAT utilizza 64 bit per descrivere le dimensioni del file, abilitando in questo modo le applicazioni che dipendono da file di grandi dimensioni. Il file system exFAT consente inoltre i cluster di dimensioni maggiori di 32 MB, abilitando efficacemente dispositivi di archiviazione di grandi dimensioni.

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

    Il exFAT file system incorpora l'estendibilità nella progettazione, consentendo al file system di rimanere al passo con le innovazioni di archiviazione e le modifiche all'utilizzo.

1,2 terminologia specifica

Nel contesto di questa specifica, determinati termini (vedere la tabella 1) presentano 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 "shall" per descrivere un comportamento obbligatorio.
Dovrebbe Questa specifica USA il termine "should" per descrivere un comportamento consigliato, 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 deve modificare e interpretare come descritto in questa specifica.
Facoltativo Questo termine descrive un campo o una struttura che un'implementazione può o meno supportare. Se un'implementazione supporta una determinata struttura o un campo facoltativo, deve modificare e interpretare il campo o la struttura come descritto in questa specifica.
Non definito Questo termine descrive il contenuto di un campo o di una struttura che può essere modificato in base alle esigenze, ad esempio da Clear a zero quando si impostano i campi o le strutture circostanti, e non deve interpretare per mantenere un significato specifico.
Riservato

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

  1. Deve essere inizializzato su zero e non deve essere usato per alcuno scopo

  2. Non deve interpretare, tranne quando si calcolano i checksum

  3. Deve mantenere tra 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 personal computer (vedere la tabella 2).

Tabella 2 testo completo degli acronimi comuni

Acronimo Full-text
ASCII American Standard Code for Information Interchange
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 di allocazione file, indici cluster a 12 bit
FAT16 Tabella di allocazione file, indici cluster a 16 bit
FAT32 Tabella di 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 indipendente dalle transazioni
UTC Ora UTC (Coordinated Universal Time)

1,4 qualificatori di campo e struttura predefiniti

I campi e le strutture in questa specifica hanno i qualificatori seguenti (vedere l'elenco riportato di seguito), a meno che non venga annotata diversamente dalla specifica.

  1. Non firmato

  2. Usare la notazione decimale per descrivere i valori, laddove non diversamente specificato; Questa specifica USA la lettera "h" post-correzione per indicare i numeri esadecimali e racchiude i GUID tra parentesi graffe

  3. Sono in formato little-endian

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

1,5 Windows CE e TexFAT

TexFAT è un'estensione di exFAT che aggiunge una semantica operativa indipendente dalle transazioni nella parte superiore del file system di base. TexFAT viene usato da Windows CE. TexFAT richiede l'utilizzo dei due grassi e delle bitmap di allocazione da utilizzare nelle transazioni. Definisce inoltre diverse strutture aggiuntive, tra cui descrittori di riempimento e descrittori di sicurezza.

2 struttura del volume

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

Tabella 3 struttura del volume

Nome dell'area secondaria

Offset

settore

Dimensioni

settori

Commenti
Area di avvio principale
Settore di avvio principale 0 1 Questa area secondaria è obbligatoria e la sezione 3,1 ne definisce il contenuto.
Principali settori di avvio esteso 1 8 Questa area secondaria è obbligatoria e la sezione 3,2) ne definisce il contenuto.
Parametri OEM principali 9 1 Questa area secondaria è obbligatoria e la sezione 3,3 ne definisce il contenuto.
Principale riservato 10 1 Questa area secondaria è obbligatoria e i relativi contenuti sono riservati.
Checksum di avvio principale 11 1 Questa area secondaria è obbligatoria e la sezione 3,4 ne definisce il contenuto.
Area di avvio del backup
Settore di avvio del backup 12 1 Questa area secondaria è obbligatoria e la sezione 3,1 ne definisce il contenuto.
Backup dei settori di avvio esteso 13 8 Questa area secondaria è obbligatoria e la sezione 3,2 ne definisce il contenuto.
Parametri OEM di backup 21 1 Questa area secondaria è obbligatoria e la sezione 3,3 ne definisce il contenuto.
Backup riservato 22 1 Questa area secondaria è obbligatoria e i relativi contenuti sono riservati.
Checksum di avvio di backup 23 1 Questa area secondaria è obbligatoria e la sezione 3,4 ne definisce il contenuto.
Area FAT
Allineamento FAT 24 FatOffset-24

Questa area secondaria è obbligatoria e il relativo contenuto, se presente, non è definito.

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

Primo FAT FatOffset FatLength

Questa area secondaria è obbligatoria e la sezione 4,1 ne definisce il contenuto.

Nota: i settori di avvio principale e di backup contengono entrambi i campi FatOffset e FatLength.

Secondo FAT FatOffset + FatLength FatLength * (NumberOfFats-1)

Questa area secondaria è obbligatoria e la sezione 4,1 ne definisce il contenuto, se disponibile.

Nota: i settori di avvio principale e di backup contengono entrambi i campi FatOffset, FatLength e NumberOfFats. Il campo NumberOfFats può conservare solo i valori 1 e 2.

Area dati
Allineamento heap cluster FatOffset + FatLength * NumberOfFats ClusterHeapOffset-(FatOffset + FatLength * NumberOfFats)

Questa area secondaria è obbligatoria e il relativo contenuto, se presente, non è definito.

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.

Heap cluster ClusterHeapOffset Clustercount-* 2SectorsPerClusterShift

Questa area secondaria è obbligatoria e la sezione 5,1 ne 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-* 2SectorsPerClusterShift VolumeLength – (ClusterHeapOffset + Clustercount-* 2SectorsPerClusterShift)

Questa area secondaria è obbligatoria e il relativo contenuto, se presente, non è definito.

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

3 aree di avvio principali e di backup

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

  1. Eseguire il Boot-strap di un sistema di computer da un volume exFAT.

  2. Identificare il file system nel volume come exFAT.

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

L'area di avvio del backup è un backup dell'area di avvio principale. Aiuta il ripristino del volume exFAT nel caso in cui l'area di avvio principale sia in uno stato incoerente. Tranne che in circostanze non frequenti, ad esempio l'aggiornamento delle istruzioni di strappo, le implementazioni non devono modificare il contenuto dell'area di avvio del backup.

3,1 aree secondarie del settore di avvio principale e di backup

Il settore di avvio principale contiene il codice per la reggiatura da un volume exFAT e i parametri di exFAT fondamentali che descrivono la struttura del volume (vedere la tabella 4). Gli agenti BIOS, MBR o di terze parti possono ispezionare questo settore e possono caricare ed eseguire tutte le istruzioni di strappo in esso contenute.

Il settore di avvio del backup è un backup del settore di avvio principale e ha la stessa struttura (vedere la tabella 4). Il settore di avvio del backup può facilitare le operazioni di ripristino; Tuttavia, le implementazioni devono trattare il contenuto dei campi VolumeFlags e PercentInUse come obsoleto.

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

Mentre l'operazione di formattazione iniziale Inizializza il contenuto dei settori di avvio principale e di backup, le implementazioni possono aggiornare questi settori (e aggiornare 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 del settore di avvio principale e di backup

Nome campo

Offset

byte

Dimensioni

byte

Commenti
JumpBoot 0 3 Questo campo è obbligatorio e la sezione 3.1.1 ne definisce il contenuto.
FileSystemName 3 8 Questo campo è obbligatorio e la sezione 3.1.2 ne 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 i relativi contenuti sono riservati.
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 2BytesPerSectorShift -512

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

Nota: i settori di avvio principale e 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 viene eseguita, "salta" la CPU per eseguire le istruzioni di strappo nel campo BootCode.

Il valore valido per questo campo è (in ordine di byte di ordine inferiore al byte più significativo) 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.

Campo MustBeZero 3.1.3

Il campo MustBeZero deve corrispondere direttamente all'intervallo di byte utilizzato dal blocco di parametri BIOS compresso sui 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 3.1.4 PartitionOffset

Il campo PartitionOffset descrivono l'offset del settore relativo ai supporti della partizione che ospita il volume exFAT specificato. Questo campo facilita l'avvio del volume usando INT 13h esteso nei personal computer.

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

Campo 3.1.5 VolumeLength

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

L'intervallo valido di valori per questo campo sarà:

  • Almeno 220/2BytesPerSectorShift, che garantisce che il volume minimo sia inferiore a 1 MB

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

Tuttavia, se le dimensioni dell'area secondaria dello spazio in eccesso sono pari a 0, il valore di questo campo è ClusterHeapOffset + (232-11) * 2SectorsPerClusterShift.

Campo 3.1.6 FatOffset

Il campo FatOffset descrivono l'offset di settore relativo al volume del primo FAT. Questo campo consente alle implementazioni di allineare il primo FAT alle caratteristiche del supporto di archiviazione sottostante.

L'intervallo valido di valori per questo campo sarà:

  • Almeno 24, che rappresenta i settori utilizzati dalle aree di avvio principale e di avvio del backup

  • Al massimo ClusterHeapOffset-(FatLength * NumberOfFats), che rappresenta i settori utilizzati dall'heap del cluster

Campo 3.1.7 FatLength

Il campo FatLength descrivono la lunghezza, in settori, di ogni tabella FAT (il volume può contenere un massimo di due grassi).

L'intervallo valido di valori per questo campo sarà:

  • Almeno (Clustercount-+ 2) * 22/2BytesPerSectorShiftarrotondato per eccesso al numero intero più vicino, che garantisce che ogni Fat disponga di spazio sufficiente per la descrizione di tutti i cluster nell'heap del cluster

  • Al massimo (ClusterHeapOffset-FatOffset)/NumberOfFats arrotondato per difetto al numero intero più vicino, che garantisce che i grassi esistano prima dell'heap del cluster

Questo campo può contenere un valore superiore al limite inferiore (come descritto in precedenza) per abilitare il secondo FAT, se presente, in modo da essere allineato anche alle caratteristiche del supporto di archiviazione sottostante. Il contenuto dello spazio che supera il contenuto del grasso necessario, se presente, non è definito.

Campo 3.1.8 ClusterHeapOffset

Il campo ClusterHeapOffset descrivono l'offset del settore relativo al volume dell'heap del cluster. Questo campo consente alle implementazioni di allineare l'heap del cluster alle caratteristiche del supporto di archiviazione sottostante.

L'intervallo valido di valori per questo campo sarà:

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

  • Al massimo 232-1 o VolumeLength-(Clustercount- * 2SectorsPerClusterShift), a seconda del calcolo minore

Campo 3.1.9 Clustercount-

Il campo Clustercount-descrive il numero di cluster contenuti nell'heap del cluster.

Il valore valido per questo campo sarà il minore dei seguenti:

  • (VolumeLength-ClusterHeapOffset)/2SectorsPerClusterShiftarrotondato per difetto all'intero più vicino, che corrisponde esattamente al numero di cluster che è possibile inserire tra l'inizio dell'heap del cluster e la fine del volume

  • 232-11, ovvero il numero massimo di cluster che possono essere descritti da un fat

Il valore del campo Clustercount-determina la dimensione minima di un FAT. Per evitare grassi 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 non più di 2 cluster24-2 nell'heap del cluster. Tuttavia, le implementazioni saranno in grado di gestire i volumi con un massimo di 2 cluster32-11 nell'heap del cluster.

Campo 3.1.10 FirstClusterOfRootDirectory

Il campo FirstClusterOfRootDirectory deve contenere l'indice del cluster del primo cluster della directory radice. Le implementazioni devono eseguire ogni sforzo per collocare il primo cluster della directory radice nel primo cluster non danneggiato dopo che i cluster hanno utilizzato la bitmap di allocazione e la tabella del case.

L'intervallo valido di valori per questo campo sarà:

  • 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 3.1.11 VolumeSerialNumber

Il campo VolumeSerialNumber deve contenere un numero di serie univoco. In questo modo, le implementazioni consentono di distinguere tra volumi exFAT diversi. 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 3.1.12 FileSystemRevision

Il campo FileSystemRevision descrivono i numeri di revisione principale e secondaria delle strutture exFAT nel volume specificato.

Il byte più significativo è il numero di revisione principale e il byte di ordine inferiore è il numero di revisione minore. Ad esempio, se il byte più significativo contiene il valore 01h e se il byte di ordine inferiore contiene il valore 05h, il campo FileSystemRevision descrive il numero di revisione 1,05. Analogamente, se il byte di ordine superiore contiene il valore 0Ah e se il byte di ordine inferiore contiene il valore 0Fh, il campo FileSystemRevision descrive il numero di revisione 10,15.

L'intervallo valido di valori per questo campo sarà:

  • Almeno 0 per il byte di ordine inferiore e 1 per il byte di ordine superiore

  • Al massimo 99 per il byte di ordine inferiore e 99 per il byte più significativo

Il numero di revisione di exFAT descritta in questa specifica è 1,00. Le implementazioni di questa specifica devono montare un volume exFAT con la revisione principale 1 e non devono montare alcun volume exFAT con altri numeri di revisione principali. Le implementazioni devono rispettare il numero di revisione secondaria e non devono eseguire operazioni né creare alcuna struttura di file system non descritta nella specifica corrispondente del numero di revisione secondaria specificato.

Campo 3.1.13 VolumeFlags

Il campo VolumeFlags deve contenere flag che indicano lo stato di varie strutture di file system nel volume exFAT (vedere la tabella 5).

Le implementazioni non includono questo campo durante il calcolo del rispettivo checksum principale dell'area di avvio o di backup. Quando si fa riferimento al settore di avvio del backup, le implementazioni devono considerare questo campo come non aggiornato.

Tabella 5 struttura del campo VolumeFlags

Nome campo

Offset

po'

Dimensioni

bit

Commenti
ActiveFat 0 1 Questo campo è obbligatorio e la sezione 3.1.13.1 ne definisce il contenuto.
VolumeDirty 1 1 Questo campo è obbligatorio e la sezione 3.1.13.2 ne definisce il contenuto.
MediaFailure 2 1 Questo campo è obbligatorio e la sezione 3.1.13.3 ne definisce il contenuto.
ClearToZero 3 1 Questo campo è obbligatorio e la sezione 3.1.13.4 ne definisce il contenuto.
Riservato 4 12 Questo campo è obbligatorio e i relativi contenuti sono riservati.
Campo 3.1.13.1 ActiveFat

Il campo ActiveFat descrivono quali bitmap di allocazione e FAT sono attive (e le implementazioni utilizzeranno), come indicato di seguito:

  • 0, che indica che la prima bitmap di allocazione e FAT è attiva

  • 1, che indica che la seconda bitmap di allocazione FAT e Second è attiva ed è possibile solo quando il campo NumberOfFats contiene il valore 2

Le implementazioni prendono in considerazione la bitmap di allocazione e FAT inattiva come obsoleto. Solo le implementazioni compatibili con TexFAT devono cambiare le bitmap di allocazione e FAT attive (vedere la sezione 7,1).

Campo 3.1.13.2 VolumeDirty

Il campo VolumeDirty indica se il volume è modificato o meno, come indicato di seguito:

  • 0, che indica 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 file system incoerenze dei metadati che non vengono risolte. Se, dopo il montaggio di un volume, il valore di questo campo è 1, solo le implementazioni che risolvono file system le incoerenze dei metadati potrebbero cancellare il valore di questo campo su 0. Tali implementazioni elimineranno solo il valore di questo campo su 0 dopo aver verificato che il file system sia in uno stato coerente.

Se, dopo il montaggio di un volume, il valore di questo campo è 0, le implementazioni devono impostare questo campo su 1 prima di aggiornare i metadati di file system e deselezionare il campo su 0 in seguito, in modo analogo all'ordine di scrittura consigliato descritto nella sezione 8,1.

Campo 3.1.13.3 MediaFailure

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

  • 0, il che significa che i supporti di hosting non hanno segnalato errori o che eventuali errori noti sono già registrati nel FAT come cluster "danneggiati"

  • 1, ovvero i supporti di hosting hanno segnalato errori, ovvero le operazioni di lettura o scrittura non sono riuscite.

Un'implementazione di deve impostare questo campo su 1 quando:

  1. Il supporto di hosting non riesce a eseguire tentativi di accesso a qualsiasi area del volume

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

Se, dopo il montaggio di un volume, il valore di questo campo è 1, le implementazioni che analizzano l'intero volume per gli errori dei supporti e registrano tutti gli errori come cluster "non corretti" nel FAT (o in caso contrario risoluzione degli errori dei supporti) potrebbero cancellare il valore di questo campo su 0.

Campo 3.1.13.4 ClearToZero

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

I valori validi per questo campo sono:

  • 0, che non ha un significato particolare

  • 1, che indica che le implementazioni devono cancellare questo campo su 0 prima di modificare eventuali strutture, directory o file file system

Campo 3.1.14 BytesPerSectorShift

Il campo BytesPerSectorShift descrivono i byte per settore espresso 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 valido di valori per questo campo sarà:

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

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

Campo 3.1.15 SectorsPerClusterShift

Il campo SectorsPerClusterShift descrive i settori per ogni cluster espresso 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 valido di valori per questo campo sarà:

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

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

Campo 3.1.16 NumberOfFats

Il campo NumberOfFats descrive il numero di grassi e le bitmap di allocazione contenuti nel volume.

L'intervallo valido di valori per questo campo sarà:

  • 1, che indica che il volume contiene solo la prima bitmap di allocazione FAT e FAT

  • 2, che indica che il volume contiene il primo bitmap FAT, Second FAT, First allocation e la seconda bitmap di allocazione; Questo valore è valido solo per i volumi TexFAT

Campo 3.1.17 DriveSelect

Il campo DriveSelect deve contenere il numero di unità 13h esteso INT, che facilita l'avvio da questo volume usando Extended INT 13h nei personal computer.

Tutti i valori possibili per questo campo sono validi. I campi simili nei file System precedenti basati su FAT contengono spesso il valore 80H.

Campo 3.1.18 PercentInUse

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

L'intervallo valido di valori per questo campo sarà:

  • Compreso tra 0 e 100, ovvero la percentuale di cluster allocati nell'heap del cluster, arrotondati per difetto all'intero più vicino

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

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

Le implementazioni non includono questo campo durante il calcolo del rispettivo checksum principale dell'area di avvio o di backup. Quando si fa riferimento al settore di avvio del backup, le implementazioni devono considerare questo campo come non aggiornato.

Campo 3.1.19 BootCode

Il campo BootCode deve contenere istruzioni di strappo di avvio. Le implementazioni possono popolare questo campo con le istruzioni della CPU necessarie per l'avvio di un sistema di computer. Le implementazioni che non forniscono istruzioni di strappo di avvio devono inizializzare ogni byte in questo campo su F4h (l'istruzione Halt per le CPU comuni nei personal computer) come parte dell'operazione di formattazione.

Campo 3.1.20 BootSignature

Il campo BootSignature descrivono se lo scopo di un determinato settore è quello di essere un settore di avvio.

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 a seconda di qualsiasi altro campo nel rispettivo settore di avvio.

3,2 settori di avvio esteso principale e di backup per aree secondarie

Ogni settore dei principali settori di avvio esteso ha la stessa struttura; Tuttavia, in ogni settore possono essere contenute istruzioni di strappo di avvio separate (vedere la tabella 6). Gli agenti di strappo, ad esempio le istruzioni di strappo nel settore di avvio principale, le implementazioni BIOS alternative o il firmware di un sistema incorporato, possono caricare questi settori ed eseguire le istruzioni che contengono.

I settori di avvio esteso 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 principale o di avvio esteso di backup, le implementazioni devono verificare il contenuto assicurando che il campo ExtendedBootSignature di ogni settore contenga il valore previsto.

Mentre l'operazione di formattazione iniziale Inizializza il contenuto dei settori principale e di avvio esteso di backup, le implementazioni possono aggiornare questi settori (e aggiornare anche il rispettivo checksum di avvio) in base alle esigenze.

Tabella 6 struttura del settore di avvio esteso

Nome campo

Offset

byte

Dimensioni

byte

Commenti
ExtendedBootCode 0 2BytesPerSectorShift – 4

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

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

ExtendedBootSignature 2BytesPerSectorShift – 4 4

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

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

3.2.1 campo ExtendedBootCode

Il campo ExtendedBootCode deve contenere istruzioni di strappo di avvio. Le implementazioni possono popolare questo campo con le istruzioni della CPU necessarie per l'avvio di un sistema di computer. Le implementazioni che non forniscono istruzioni di strappo di avvio devono inizializzare ogni byte in questo campo su 00h come parte dell'operazione di formattazione.

3.2.2 campo ExtendedBootSignature

Il campo ExtendedBootSignature descrive se lo scopo del settore specificato è quello di essere 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 principale o di backup. Le implementazioni devono verificare il contenuto di questo campo prima di a seconda di qualsiasi altro campo nel rispettivo settore di avvio esteso.

3,3 parametri OEM principali e di backup per le aree secondarie

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

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

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

I produttori devono popolare i parametri OEM principale e di backup con strutture di parametri personalizzate, se presenti, e qualsiasi altra struttura di parametri. Le operazioni di formato successive mantengono il contenuto dei parametri OEM principale e di backup.

Le implementazioni possono aggiornare i parametri OEM principale e di backup in base alle esigenze (e aggiornare anche il rispettivo checksum di avvio).

Tabella 7 struttura dei parametri OEM

Nome campo

Offset

byte

Dimensioni

byte

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

.

.

.

.

.

.

.

.

.

.

.

.

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

Questo campo è obbligatorio e i relativi contenuti sono riservati.

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

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

Ogni campo di parametri in questa matrice contiene una struttura di parametri, che deriva dal modello di parametri generici (vedere la sezione 3.3.2). Qualsiasi campo dei parametri non usati deve essere descritto come contenente una struttura di parametri null (vedere la sezione 3.3.3).

3.3.2 modello di parametri generici

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

Tabella 8 modello di parametri generici

Nome campo

Offset

byte

Dimensioni

byte

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

Il campo ParametersGuid descrivono un GUID, che determina il layout del resto della struttura dei parametri specificata.

Tutti i valori possibili per questo campo sono validi. Tuttavia, i costruttori devono usare uno strumento di generazione GUID, ad esempio GuidGen.exe, per selezionare un GUID quando si derivano le strutture di parametri personalizzati da questo modello.

3.3.3 parametri null

La struttura di parametri null deriva dal modello di parametri generici (vedere la sezione 3.3.2) e descrivono un campo di parametri non usati (vedere la tabella 9). Quando si crea o si aggiorna la struttura dei parametri OEM, le implementazioni devono popolare i campi dei parametri non utilizzati con la struttura dei parametri null. Inoltre, quando si crea o si aggiorna la struttura dei parametri OEM, le implementazioni devono consolidare le strutture di parametri null alla fine della matrice, lasciando in tal modo tutte le altre strutture di parametri all'inizio della struttura dei parametri OEM.

Il supporto per la struttura di parametri null è obbligatorio.

Struttura di parametri null della tabella 9

Nome campo

Offset

byte

Dimensioni

byte

Commenti
ParametersGuid 0 16 Questo campo è obbligatorio e la sezione 3.3.3.1 ne definisce il contenuto.
Riservato 16 32 Questo campo è obbligatorio e i relativi contenuti sono riservati.
Campo 3.3.3.1 ParametersGuid

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

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

Parametri flash 3.3.4

La struttura del parametro Flash deriva dal modello di parametri generici (vedere la sezione 3.3.2) e contiene i parametri per i supporti Flash (vedere la 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 dei parametri flash per ottimizzare le operazioni di accesso durante le operazioni di lettura/scrittura e per l'allineamento delle strutture file system Durning la formattazione dei supporti.

Il supporto per la struttura dei parametri flash è facoltativo.

Tabella 10 struttura dei parametri flash

Nome campo

Offset

byte

Dimensioni

byte

Commenti
ParametersGuid 0 16 Questo campo è obbligatorio e la sezione 3.3.4.1 ne definisce il contenuto.
EraseBlockSize 16 4 Questo campo è obbligatorio e la sezione 3.3.4.2 ne definisce il contenuto.
PageSize 20 4 Questo campo è obbligatorio e la sezione 3.3.4.3 ne definisce il contenuto.
SpareSectors 24 4 Questo campo è obbligatorio e la sezione 3.3.4.4 ne definisce il contenuto.
RandomAccessTime 28 4 Questo campo è obbligatorio e la sezione 3.3.4.5 ne definisce il contenuto.
ProgrammingTime 32 4 Questo campo è obbligatorio e la sezione 3.3.4.6 ne definisce il contenuto.
ReadCycle 36 4 Questo campo è obbligatorio e la sezione 3.3.4.7 ne definisce il contenuto.
WriteCycle 40 4 Questo campo è obbligatorio e la sezione 3.3.4.8 ne definisce il contenuto.
Riservato 44 4 Questo campo è obbligatorio e i relativi contenuti sono riservati.

Tutti i valori possibili per tutti i campi dei parametri flash, ad eccezione del campo ParametersGuid, sono validi. Tuttavia, il valore 0 indica che il campo è effettivamente privo di significato (le implementazioni ignoreranno il campo specificato).

Campo 3.3.4.1 ParametersGuid

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

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

Campo 3.3.4.2 EraseBlockSize

Il campo EraseBlockSize descrive le dimensioni, in byte, del blocco Erase del supporto Flash.

3.3.4.3 campo PageSize

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

Campo 3.3.4.4 SpareSectors

Il campo SpareSectors descrive il numero di settori che i supporti flash sono disponibili per le operazioni di disuguaglianza interne.

Campo 3.3.4.5 RandomAccessTime

Il campo RandomAccessTime descrive il tempo medio di accesso casuale dei supporti flash, in nanosecondi.

Campo 3.3.4.6 ProgrammingTime

Il campo ProgrammingTime descrive il tempo medio di programmazione dei supporti flash, in nanosecondi.

Campo 3.3.4.7 ReadCycle

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

Campo 3.3.4.8 WriteCycle

Il campo WriteCycle descrive la durata media del ciclo di scrittura, in nanosecondi.

3,4 sottoaree di checksum di avvio principale e backup

I checksum di avvio principale e di backup contengono ciascuno un modello ripetuto del checksum di quattro byte del contenuto di tutte le altre aree secondarie nelle rispettive aree di avvio. Il calcolo del checksum non deve includere i campi VolumeFlags e PercentInUse nel rispettivo settore di avvio (vedere la Figura 1). Il modello ripetuto del checksum a quattro byte riempie la rispettiva area secondaria di checksum di avvio dall'inizio alla fine dell'area secondaria.

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

Mentre l'operazione di formattazione iniziale compilerà sia i checksum di avvio principale che quelli di backup con il modello di checksum ripetuto, le implementazioni dovranno aggiornare questi settori come il contenuto degli altri settori nelle rispettive aree di avvio cambiano.

Figura 1 calcolo del checksum di 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 di allocazione file

L'area della tabella di allocazione file (FAT) può contenere fino a due grassi, una nella prima area secondaria FAT e un'altra nella seconda area FAT. Il campo NumberOfFats descrive il numero di grassi contenuti in questa area. I valori validi per il campo NumberOfFats sono 1 e 2. Pertanto, la prima area secondaria FAT contiene sempre un valore FAT. Se il campo NumberOfFats è due, la seconda area secondaria FAT contiene anche un valore FAT.

Il campo ActiveFat del campo VolumeFlags descrive il FAT attivo. Solo il campo VolumeFlags nel settore di avvio principale è corrente. Le implementazioni devono trattare il FAT, che non è attivo come obsoleto. L'utilizzo del grasso inattivo e il cambio tra i grassi sono specifici dell'implementazione.

4,1 prime e seconde aree secondarie FAT

Un FAT descriva le catene del cluster nell'heap del cluster (vedere la tabella 11). Una catena di cluster è una serie di cluster che fornisce spazio per la registrazione del contenuto di file, directory e altre strutture di file system. Un FAT rappresenta una catena di cluster come un elenco collegato singolarmente di indici cluster. Fatta eccezione per le prime due voci, ogni voce di un valore FAT rappresenta esattamente un cluster.

Tabella 11 struttura della tabella di allocazione file

Nome campo

Offset

byte

Dimensioni

byte

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

.

.

.

.

.

.

.

.

.

.

.

.

FatEntry [Clustercount-+ 1] (Clustercount-+ 1) * 4 4

Questo campo è obbligatorio e la sezione 4.1.3 ne 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 * 2BytesPerSectorShift) – ((clustercount-+ 2) * 4)

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

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

4.1.1 FatEntry [ ] campo 0

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

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

4.1.2 [ campo FatEntry 1 ]

Il [ campo FatEntry 1 ] esiste solo a causa della precedenza cronologica e non descrive alcunché di interesse.

Il valore valido per questo campo è FFFFFFFFh. Le implementazioni devono inizializzare questo campo sul valore prescritto e non devono utilizzare questo campo per alcuno scopo. Le implementazioni non devono interpretare questo campo e conservarne il contenuto tra le operazioni che modificano i campi circostanti.

4.1.3 FatEntry [ 2 ] ... [Campi FatEntry clustercount-+ 1 ]

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

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

  • Compreso tra 2 e Clustercount-+ 1, incluso, che punta al FatEntry successivo nella catena del cluster specificata; il FatEntry specificato non deve puntare a nessun FatEntry che lo precede nella catena di cluster specificata

  • Esattamente FFFFFFF7h, che contrassegna il cluster corrispondente del FatEntry specificato come "non valido"

  • Esattamente FFFFFFFFh, che contrassegna il cluster corrispondente del FatEntry specificato come ultimo cluster di una catena di cluster. Questo è l'unico valore valido per l'ultimo FatEntry di una determinata catena di cluster

5 area dati

L'area dati contiene l'heap del cluster, che fornisce lo spazio gestito per le strutture, le directory e i file di file system.

area secondaria heap cluster 5,1

La struttura dell'heap del cluster è molto semplice (vedere la tabella 12); ogni serie consecutiva di settori descrive un cluster, come definito dal campo SectorsPerClusterShift. In particolare, il primo cluster dell'heap del cluster ha l'indice Two, 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.

Tabella 12 struttura dell'heap del cluster

Nome campo

Offset

settore

Dimensioni

settori

Commenti
Cluster [2] ClusterHeapOffset 2SectorsPerClusterShift

Questo campo è obbligatorio e la sezione 5.1.1 ne 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) * 2SectorsPerClusterShift 2SectorsPerClusterShift

Questo campo è obbligatorio e la sezione 5.1.1 ne 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 del cluster [ clustercount-+ 1 ]

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

6 struttura di directory

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

La directory a cui si riferisce il campo FirstClusterOfRootDirectory è la radice dell'albero di directory. Tutte le altre directory discendono dalla directory radice in un modo collegato singolarmente.

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

Una o più voci di directory vengono combinate in un set di voci di directory che descrive un elemento interessante, ad esempio una struttura file system, una sottodirectory o un file.

Tabella 13 struttura di directory

Nome campo

Offset

byte

Dimensioni

byte

Commenti
DirectoryEntry [0] 0 32 Questo campo è obbligatorio e la sezione 6,1 ne definisce il contenuto.

.

.

.

.

.

.

.

.

.

.

.

.

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

Questo campo è obbligatorio e la sezione 6,1 ne definisce il contenuto.

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

6,1 DirectoryEntry [ 0 ] ... DirectoryEntry [ N--1]

Ogni campo DirectoryEntry in questa matrice deriva dal modello generico DirectoryEntry (vedere la sezione 6,2).

6,2 modello DirectoryEntry generico

Il modello generico DirectoryEntry fornisce la definizione di base per le voci di directory (vedere la tabella 14). Tutte le strutture di immissione di directory derivano da questo modello e sono valide solo le strutture di immissione di directory definite da Microsoft (exFAT non contiene disposizioni per le strutture di immissione di directory definite dal produttore, tranne come definito nella sezione 7,8 e 7,9). La possibilità di interpretare il modello generico DirectoryEntry è obbligatoria.

Tabella 14 modello di DirectoryEntry generico

Nome campo

Offset

byte

Dimensioni

byte

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

6.2.1 campo EntryType

Il campo EntryType dispone di tre modalità di utilizzo che definiscono il valore del campo (vedere l'elenco riportato di seguito).

  • 00h, ovvero un marcatore di fine directory e si applicano le condizioni seguenti:

    • Tutti gli altri campi nel determinato DirectoryEntry sono effettivamente riservati

    • Anche tutte le voci di directory successive nella directory specificata sono marcatori di fine directory

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

    • Le implementazioni possono sovrascrivere i marcatori di fine directory se necessario

  • Compreso tra 01h e 7Fh, ovvero un marcatore di voce di directory inutilizzata e si applicano le condizioni seguenti:

    • Tutti gli altri campi nell'oggetto DirectoryEntry specificato non sono effettivamente definiti

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

    • Le implementazioni possono sovrascrivere le voci di directory inutilizzate se necessario

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

  • Compreso tra 81h e FFh, ovvero una voce di directory normale e si applicano le condizioni seguenti:

    • Il contenuto del campo EntryType (vedere la tabella 15) determina il layout della parte restante 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) che contiene il valore 1

Per evitare modifiche al campo InUse (vedere la sezione 6.2.1.4) che causa erroneamente un marcatore di fine directory, il valore 80H non è valido.

Tabella 15 struttura di campo EntryType generica

Nome campo

Offset

po'

Dimensioni

bit

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

Il campo TypeCode descrive parzialmente il tipo specifico della voce di directory specificata. Questo campo, più i campi TypeImportance e TypeCategory (vedere rispettivamente la sezione 6.2.1.2 e la sezione 6.2.1.3) identificano 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 tal caso, il valore 0 non è valido per questo campo.

Campo 6.2.1.2 TypeImportance

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

I valori validi per questo campo saranno:

  • 0, che indica che la voce di directory specificata è critica (vedere la sezione 6.3.1.2.1 e la sezione 6.4.1.2.1 per le voci di directory secondarie critiche e primarie, rispettivamente)

  • 1, il che significa che la voce di directory specificata è benigna (vedere la sezione 6.3.1.2.2 e la sezione 6.4.1.2.2 rispettivamente per le voci di directory secondarie benigne e secondarie benigne)

Campo 6.2.1.3 TypeCategory

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

I valori validi per questo campo saranno:

  • 0, che indica che la voce di directory specificata è primaria (vedere la sezione 6,3)

  • 1, che indica che la voce di directory specificata è secondaria (vedere la sezione 6,4)

Campo 6.2.1.4 InUse

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

I valori validi per questo campo saranno:

  • 0, che indica che la voce di directory specificata non è in uso. Ciò significa che la struttura specificata è effettivamente una voce di directory inutilizzata

  • 1, che indica che la voce di directory specificata è in uso. Ciò significa che la struttura specificata è una voce di directory normale

6.2.2 campo FirstCluster

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

L'intervallo valido di valori per questo campo sarà:

  • Esattamente 0, che significa che non esiste alcuna allocazione cluster

  • Compreso tra 2 e Clustercount-+ 1, ovvero l'intervallo di indici cluster validi

Le strutture che derivano da questo modello possono ridefinire i campi FirstCluster e 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 cluster associata.

L'intervallo valido di valori per questo campo è:

  • Almeno 0; Se il campo FirstCluster contiene il valore 0, l'unico valore valido di questo campo è 0

  • Al massimo Clustercount- * 2SectorsPerClusterShift * 2BytesPerSectorShift

Le strutture che derivano da questo modello possono ridefinire i campi FirstCluster e DATALENGTH, se non è possibile allocare un cluster per la struttura derivata.

6,3 modello DirectoryEntry primario generico

La prima voce di directory in un set di voci di directory deve essere una voce di directory primaria. Tutte le eventuali voci di directory successive nel set di voci di directory saranno voci di directory secondarie (vedere la sezione 6,4).

La possibilità di interpretare il modello DirectoryEntry primario generico è obbligatoria.

Tutte le strutture di immissione di directory primarie derivano dal modello DirectoryEntry primario generico (vedere la tabella 16), che deriva dal modello generico DirectoryEntry (vedere la sezione 6,2).

Tabella 16 modello DirectoryEntry primario generico

Nome campo

Offset

byte

Dimensioni

byte

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

Campo 6.3.1 EntryType

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

Campo TypeCode 6.3.1.1

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

Campo 6.3.1.2 TypeImportance

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

6.3.1.2.1 le voci di directory primarie critiche

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

La definizione delle voci di directory primarie critiche è correlata al numero di revisione principale di exFAT. Le implementazioni devono supportare tutte le voci di directory primarie critiche e devono registrare solo le strutture di voci di directory primarie critiche definite da questa specifica.

6.3.1.2.2 le voci di directory primarie benigne

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

La definizione di voci di directory primarie benigne è correlata al numero di revisione exFAT secondario. Supporto per qualsiasi voce di directory primaria benigna questa specifica, o qualsiasi specifica successiva, definisce è facoltativa. Una voce di directory primaria benigna non riconosciuta esegue il rendering dell'intero set di voci di directory come non riconosciuto (oltre alla definizione dei modelli di immissione di directory applicabili).

Campo 6.3.1.3 TypeCategory

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

Per questo modello, il valore valido per questo campo sarà 0.

Campo 6.3.1.4 InUse

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

Campo 6.3.2 SecondaryCount

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

L'intervallo valido di valori per questo campo sarà:

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

  • Al massimo 255, che indica le successive voci di directory 255 e questa voce di directory primaria comprende il set di voci di directory

Le strutture di voci di directory primarie critiche che derivano da questo modello possono ridefinire i campi SecondaryCount e sechequer.

6.3.3 (campo di controllo)

Il campo del controllo di accesso deve contenere il checksum di tutte le voci di 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 utilizzare qualsiasi altra voce di directory nel set di voci di directory specificato.

Le strutture di voci di directory primarie critiche che derivano da questo modello possono ridefinire i campi SecondaryCount e sechequer.

Figura 2 calcolo di EntrySetChecksum

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

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

Campo 6.3.4 GeneralPrimaryFlags

Il campo GeneralPrimaryFlags contiene flag (vedere la tabella 17).

Le strutture di voci di directory primarie critiche che derivano da questo modello possono ridefinire questo campo.

Tabella 17 struttura di campo GeneralPrimaryFlags generica

Nome campo

Offset

po'

Dimensioni

bit

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

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

I valori validi per questo campo saranno:

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

  • 1, il che significa che è possibile allocare un cluster associato e che i campi FirstCluster e DATALENGTH sono definiti

Campo 6.3.4.2 NoFatChain

Il campo NoFatChain indicherà se il FAT attivo descrive la catena di cluster dell'allocazione specificata.

I valori validi per questo campo saranno:

  • 0, che indica che le voci FAT corrispondenti per la catena di cluster dell'allocazione sono valide e le implementazioni devono interpretarle; Se il campo AllocationPossible contiene il valore 0 oppure se il campo AllocationPossible contiene il valore 1 e il campo FirstCluster contiene il valore 0, il valore valido di questo 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 le interpretano; le implementazioni possono usare l'equazione seguente per calcolare le dimensioni dell'allocazione associata: DataLength/(2SectorsPerClusterShift * 2BytesPerSectorShift) arrotondate per eccesso al numero intero più vicino

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

Campo 6.3.5 FirstCluster

Il campo FirstCluster deve essere conforme alla definizione fornita nel modello generico 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 voci di directory primarie 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 generico DirectoryEntry (vedere la sezione 6.2.3).

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

Le strutture di voci di directory primarie 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 DirectoryEntry secondario generico

Lo scopo principale delle voci della directory secondaria è fornire informazioni aggiuntive su un set di voci di directory. La possibilità di interpretare il modello DirectoryEntry secondario generico è obbligatoria.

La definizione di voci di directory secondarie critiche e benigne è correlata al numero di revisione exFAT secondario. Supporto per qualsiasi voce di directory secondaria critica o benigna questa specifica o le specifiche successive, definisce è facoltativa.

Tutte le strutture di voci di directory secondarie derivano dal modello di DirectoryEntry secondario generico (vedere la tabella 18), che deriva dal modello generico DirectoryEntry (vedere la sezione 6,2).

Tabella 18 modello DirectoryEntry secondario generico

Nome campo

Offset

byte

Dimensioni

byte

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

Campo 6.4.1 EntryType

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

Campo TypeCode 6.4.1.1

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

Campo 6.4.1.2 TypeImportance

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

6.4.1.2.1 voci di directory secondarie critiche

Le voci di directory secondarie critiche contengono informazioni cruciali per la corretta gestione del set di voci di directory che lo contiene. Sebbene il supporto per una voce di directory secondaria critica specifica sia facoltativo, una voce di directory critica non riconosciuta esegue il rendering dell'intero set di voci di directory come non riconosciuto (oltre alla definizione dei modelli di immissione di directory applicabili).

Tuttavia, se un set di voci di directory contiene almeno una voce di directory secondaria critica che non viene riconosciuta da un'implementazione, l'implementazione deve interpretare al massimo i modelli delle voci di directory nel set di voci della directory e non i dati di allocazione associata a una voce di directory nel set di voci di directory contiene (le voci della directory di file sono un'eccezione, vedere la sezione 7,4

6.4.1.2.2 le voci di directory secondarie benigne

Le voci di directory secondarie benigne contengono informazioni aggiuntive che possono essere utili per la gestione del set di voci di directory che lo contiene. Il supporto per qualsiasi voce di directory secondaria benigna specifica è facoltativo. Le voci di directory secondarie benigne non riconosciute non eseguono il rendering dell'intero set di voci di directory come non riconosciuto.

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

Campo 6.4.1.3 TypeCategory

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

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

Campo 6.4.1.4 InUse

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

Campo 6.4.2 GeneralSecondaryFlags

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

Tabella 19 struttura di campo GeneralSecondaryFlags generica

Nome campo

Offset

po'

Dimensioni

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.
Campo 6.4.2.1 AllocationPossible

Il campo AllocationPossible deve avere la stessa definizione del campo con lo stesso nome nel modello DirectoryEntry primario generico. vedere la sezione 6.3.4.1.

Campo 6.4.2.2 NoFatChain

Il campo NoFatChain deve avere la stessa definizione del campo con lo stesso nome nel modello DirectoryEntry primario generico. vedere la sezione 6.3.4.2.

Campo 6.4.3 FirstCluster

Il campo FirstCluster deve essere conforme alla definizione fornita nel modello generico DirectoryEntry (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 generico DirectoryEntry (vedere la sezione 6.2.3).

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

7 definizioni voce di directory

La revisione 1,00 della file system exFAT definisce le voci di directory seguenti:

7,1 voce di directory bitmap di allocazione

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

Il campo NumberOfFats determina il numero di voci della 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 della directory di una 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 allocazione bitmap struttura DirectoryEntry

Nome campo

Offset

byte

Dimensioni

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 i relativi contenuti sono riservati.
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 DirectoryEntry primario generico. vedere la sezione 6.3.1.

Campo TypeCode 7.1.1.1

Il campo TypeCode deve essere conforme alla definizione fornita nel modello DirectoryEntry primario generico. vedere la sezione 6.3.1.1.

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

Campo 7.1.1.2 TypeImportance

Il campo TypeImportance deve essere conforme alla definizione fornita nel modello DirectoryEntry primario generico. vedere la sezione 6.3.1.2.

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

Campo 7.1.1.3 TypeCategory

Il campo TypeCategory deve essere conforme alla definizione fornita nel modello DirectoryEntry primario generico. vedere la sezione 6.3.1.3.

Campo 7.1.1.4 InUse

Il campo InUse deve essere conforme alla definizione fornita nel modello DirectoryEntry primario generico. vedere la sezione 6.3.1.4.

Campo 7.1.2 BitmapFlags

Il campo BitmapFlags contiene flag (vedere la tabella 21).

Tabella 21 struttura di campo BitmapFlags

Nome campo

Offset

po'

Dimensioni

bit

Commenti
BitmapIdentifier 0 1 Questo campo è obbligatorio e la sezione 7.1.2.1 ne definisce il contenuto.
Riservato 1 7 Questo campo è obbligatorio e i relativi contenuti sono riservati.
Campo 7.1.2.1 BitmapIdentifier

Il campo BitmapIdentifier indicherà la bitmap di allocazione descritta dalla voce di directory specificata. Le implementazioni utilizzeranno la prima bitmap di allocazione insieme al primo FAT e utilizzeranno la seconda bitmap di allocazione insieme al secondo FAT. Il campo ActiveFat descrive quali bitmap di allocazione e FAT sono attive.

I valori validi per questo campo saranno:

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

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

Campo 7.1.3 FirstCluster

Il campo FirstCluster deve essere conforme alla definizione fornita nel modello DirectoryEntry primario generico. vedere la sezione 6.3.5.

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

7.1.4-campo DataLength

Il campo datacluster deve essere conforme alla definizione fornita nel modello DirectoryEntry primario generico. vedere la sezione 6.3.6.

Bitmap di allocazione 7.1.5

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 o meno per l'allocazione.

Una bitmap di allocazione rappresenta i cluster dall'indice più basso a quello più alto (vedere la tabella 22). Per motivi cronologici, il primo cluster dispone dell'indice 2. Nota: il primo bit della bitmap è il bit di ordine più basso del primo byte.

Tabella 22 struttura bitmap di allocazione

Nome campo

Offset

po'

Dimensioni

bit

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

.

.

.

.

.

.

.

.

.

.

.

.

BitmapEntry [Clustercount-+ 1] Clustercount--1 1

Questo campo è obbligatorio e la sezione 7.1.5.1 ne 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, è riservato.

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 del cluster e BitmapEntry [ clustercount-+ 1 ] rappresenta l'ultimo cluster nell'heap del cluster.

I valori validi per questi campi saranno:

  • 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 cluster può già usare il cluster corrispondente o il FAT attivo può descrivere il cluster corrispondente come danneggiato)

7,2 voce di directory della tabella del case

La tabella del case del case definisce la conversione da caratteri minuscoli a caratteri maiuscoli. Questo aspetto è importante a causa della voce di directory del nome file (vedere la sezione 7,7) che usa i caratteri Unicode e exFAT file system l'indistinzione tra maiuscole e minuscole e la conservazione del case. La tabella del case è presente nell'heap del cluster (vedere la sezione 7.2.5) e include una voce di directory primaria critica corrispondente nella directory radice (vedere la tabella 23). Il numero valido di voci della directory della tabella dei case è 1.

A causa della relazione tra la tabella del case e i nomi file, le implementazioni non devono modificare la tabella del case, ad eccezione di come risultato delle operazioni di formattazione.

Tabella 23 tabella del case in maiuscolo, struttura DirectoryEntry

Nome campo

Offset

byte

Dimensioni

byte

Commenti
EntryType 0 1 Questo campo è obbligatorio e la sezione 7.2.1 ne definisce il contenuto.
Reserved1 1 3 Questo campo è obbligatorio e i relativi contenuti sono riservati.
TableChecksum 4 4 Questo campo è obbligatorio e la sezione 7.2.2 ne definisce il contenuto.
Reserved2 8 12 Questo campo è obbligatorio e i relativi contenuti sono riservati.
FirstCluster 20 4 Questo campo è obbligatorio e la sezione 7.2.3 ne definisce il contenuto.
Lunghezza dati 24 8 Questo campo è obbligatorio e la sezione 7.2.4 ne definisce il contenuto.

Campo 7.2.1 EntryType

Il campo EntryType deve essere conforme alla definizione fornita nel modello DirectoryEntry primario generico. vedere la sezione 6.3.1.

Campo TypeCode 7.2.1.1

Il campo TypeCode deve essere conforme alla definizione fornita nel modello DirectoryEntry primario generico. vedere la sezione 6.3.1.1.

Per la voce della directory della tabella dei casi, il valore valido per questo campo è 2.

Campo 7.2.1.2 TypeImportance

Il campo TypeImportance deve essere conforme alla definizione fornita nel modello DirectoryEntry primario generico. vedere la sezione 6.3.1.2.

Per la voce della directory della tabella dei casi, il valore valido per questo campo è 0.

Campo 7.2.1.3 TypeCategory

Il campo TypeCategory deve essere conforme alla definizione fornita nel modello DirectoryEntry primario generico. vedere la sezione 6.3.1.3.

Campo 7.2.1.4 InUse

Il campo InUse deve essere conforme alla definizione fornita nel modello DirectoryEntry primario generico. vedere la sezione 6.3.1.4.

Campo 7.2.2 TableChecksum

Il campo TableChecksum contiene il checksum della tabella del case che descrive i campi FirstCluster e DATALENGTH. Le implementazioni devono verificare che il contenuto di questo campo sia valido prima di utilizzare la tabella del case.

Figura 3 calcolo di 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;
}

Campo 7.2.3 FirstCluster

Il campo FirstCluster deve essere conforme alla definizione fornita nel modello DirectoryEntry primario generico. vedere la sezione 6.3.5.

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

7.2.4-campo DataLength

Il campo datacluster deve essere conforme alla definizione fornita nel modello DirectoryEntry primario generico. vedere la sezione 6.3.6.

7.2.5-tabella del case

Una tabella del 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 del case che rappresenta il carattere Unicode per cui deve essere eseguita la combinazione di maiuscole e minuscole e il campo a 2 byte che rappresenta il carattere Unicode in maiuscolo.

I primi 128 caratteri Unicode hanno mapping obbligatori (vedere la tabella 24). Una tabella del 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 potrebbero ignorare i mapping del resto della tabella del case. Tali implementazioni utilizzeranno solo i caratteri dell'intervallo di mapping obbligatorio durante la creazione o la ridenominazione dei file (tramite la voce di directory del nome file, vedere la sezione 7,7). Quando si esegue il decompressione di nomi di file esistenti, tali implementazioni non devono essere presenti nell'intervallo di mapping non obbligatorio, ma devono essere manomesse nel nome del file in maiuscolo e minuscolo risultante. si tratta di una maiuscola parziale. Quando si confrontano i nomi di file, tali implementazioni tratteranno i nomi di file che differiscono dal nome sotto il confronto solo per i caratteri Unicode dall'intervallo di mapping non obbligatorio come equivalente. Sebbene tali nomi di file siano potenzialmente equivalenti, tali implementazioni non possono garantire che il nome del file con il nome completo non entri in conflitto con il nome sotto il confronto.

Tabella 24 voci della tabella iniziale obbligatoria prima 128

Indice tabella Voci di 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 dei case non di identità sono in grassetto.

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

Un'implementazione, ad esempio, può rappresentare i primi mapping di caratteri 100 (64H) con le otto voci seguenti di una tabella del case in formato compresso:

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

Le prime due voci indicano che i primi 97 caratteri (61H) (da 0000h a 0060h) hanno mapping di identità. I caratteri successivi, 0061h tramite 0063h, vengono mappati ai caratteri rispettivamente 0041h tramite 0043h.

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

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

Se un'implementazione definisce la propria tabella del case, compressa o non compressa, la tabella coprirà l'intervallo di caratteri Unicode completo (dai codici carattere 0000h a FFFFh inclusivo).