Specifica del file system exFAT

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 di grandi dimensioni. Il file system exFAT consente anche cluster di 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 progettazione, consentendo al file system di tenere il passo con le innovazioni nell'archiviazione e nelle modifiche nell'utilizzo.

1.2 Terminologia specifica

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

Tabella 1 definizione di termini che hanno 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 descrive questa specifica.
Facoltativo Questo termine descrive un campo o una struttura che un'implementazione può o meno supportare. Se un'implementazione supporta un determinato campo o struttura facoltativa, deve modificare e interpretare il campo o la struttura come descritto da 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 deve interpretare per contenere alcun significato specifico.
Riservato

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

  1. Inizializzarlo a zero e non deve essere utilizzato per alcun scopo

  2. Non deve 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 acronimi in uso comune nel settore del personal computer (vedere la tabella 2).

Tabella 2 full-text degli acronimi comuni

Acronimo Full-text
ASCII Codice standard americano per l'interscambio informativo
BIOS Sistema di output di input di base
CPU Unità di elaborazione centrale
exFAT Tabella di allocazione di 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 sicuro per le transazioni
UTC Coordinated Universal Time

1.4 Qualificatori predefiniti di campo e struttura

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

  1. Non firmato

  2. Utilizzare la notazione decimale per descrivere i valori, se non diversamente specificato; questa specifica usa la lettera di post-correzione "h" per indicare i numeri esadecimali e racchiudere i GUID tra 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 sopra il file system di base. TexFAT viene usato da Windows CE. TexFAT richiede l'uso delle due bitmap di allocazione e fat per l'uso nelle transazioni. Definisce anche diverse strutture aggiuntive, tra cui descrittori di spaziatura interna e descrittori di sicurezza.

Struttura del volume 2

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

Struttura del volume della tabella 3

Nome area secondaria

Offset

(settore)

Size

(settori)

Commenti
Area di avvio principale
Settore principale dell'avvio 0 1 Questa sotto-area è obbligatoria e la sezione 3.1 ne definisce il contenuto.
Principali settori di avvio esteso 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.
Backup area di avvio
Backup settore di avvio 12 1 Questa sotto-area è obbligatoria e la sezione 3.1 definisce il contenuto.
Backup settori di avvio estesi 13 8 Questa sotto-area è obbligatoria e la sezione 3.2 definisce il contenuto.
parametri OEM 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.
Backup checksum di avvio 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 main e Backup boot contengono entrambi il campo FatOffset.

Primo GRASSO FatOffset FatLength

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

Nota: i settori main e Backup boot 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 campi Main e Backup Boot Sectors 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 campi Main e Backup Boot Sectors contengono entrambi i campi FatOffset, FatLength, NumberOfFats e ClusterHeapOffset. I valori validi del campo NumberOfFats sono 1 e 2.

Cluster Heap ClusterHeapOffset ClusterCount * 2SectorsPerClusterShift

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

Nota: i campi Main e Backup Boot Sectors contengono entrambi i campi ClusterHeapOffset, ClusterCount e SectorsPerClusterShift.

Spazio in eccesso ClusterHeapOffset + ClusterCount * 2SectorsPerClusterShift VolumeLength : (ClusterHeapOffset + ClusterCount * 2SectorsPerClusterShift)

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

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

3 Aree di avvio principali e 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 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, le implementazioni non devono modificare il contenuto dell'area di avvio Backup.

3.1 Principali e Backup aree secondarie del settore di avvio

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 Backup settore di avvio è un backup del settore principale dell'avvio e ha la stessa struttura (vedere La tabella 4). Il Backup settore di avvio può aiutare le operazioni di recupero. Tuttavia, le implementazioni considerano il contenuto dei campi VolumeFlags e PercentInUse come non aggiornati.

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

Anche se l'operazione di formato iniziale inizializza il contenuto sia principale che Backup settori di avvio, le implementazioni possono aggiornare questi settori (e aggiornare anche i rispettivi 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 principale e Backup struttura del settore di avvio

Nome campo

Offset

(byte)

Size

(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 2BytesPerSectorShift - 512

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

Nota: i settori principale e Backup boot 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:

  • Almeno 220/ 2BytesPerSectorShift, 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 sottoarea 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 valido di valori per questo campo deve essere:

  • Almeno 24, che rappresenta i settori che utilizzano l'avvio principale e le aree di avvio Backup

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

3.1.7 Campo FatLength

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

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

  • Almeno (ClusterCount + 2) * 22/ 2BytesPerSectorShiftrounded fino al numero intero più vicino, che garantisce che ogni FAT abbia spazio sufficiente per descrivere tutti i cluster nell'heap del cluster

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

Questo campo può contenere un valore superiore al 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 richiede il FAT stesso, 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 del cluster alle caratteristiche dei supporti di archiviazione sottostanti.

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

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

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

Campo ClusterCount 3.1.9

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

Il valore valido per questo campo è minore di quanto segue:

  • (VolumeLength - ClusterHeapOffset) / 2SectorsPerClusterShiftrounded fino al numero intero più vicino, che è esattamente il numero di cluster che possono rientrare tra l'inizio dell'heap del 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 fat 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 224-2 cluster nell'heap del cluster. Tuttavia, le implementazioni devono essere in grado di gestire volumi con un massimo di 232-11 cluster nell'heap del cluster.

3.1.10 Campo FirstClusterOfRootDirectory

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

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

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

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

Campo VolumeSerialNumber 3.1.11

Il campo VolumeSerialNumber deve contenere un numero di serie univoco. Ciò consente alle implementazioni di 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 la combinazione di 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 di ordine elevato è il numero di revisione principale e il byte di ordine basso è il numero di revisione minore. Ad esempio, se il byte di ordine elevato contiene il valore 01h e se il byte con ordine basso contiene il valore 05h, il campo FileSystemRevision descrive il numero di revisione 1.05. Analogamente, se il byte di ordine elevato contiene il valore 0Ah e se il byte con ordine basso contiene il valore 0Fh, il campo FileSystemRevision descrive il numero di revisione 10.15.

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

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

  • Al massimo 99 per il byte di ordine basso e 99 per il byte di ordine elevato

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

Campo VolumeFlags 3.1.13

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

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

Tabella 5 Struttura dei campi VolumeFlags

Nome campo

Offset

(bit)

Size

(bit)

Commenti
ActiveFat 0 1 Questo campo è obbligatorio e la sezione 3.1.13.1 definisce il relativo 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 il relativo contenuto è riservato.
Campo ActiveFat 3.1.13.1

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 bitmap First FAT e First Allocation Sono attive

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

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

Campo VolumeDirty 3.1.13.2

Il campo VolumeDirty descrive se il volume è dirty 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 in caso di incoerenze nei metadati del file system che non risolvono. Se, durante il montaggio di un volume, il valore di questo campo è 1, solo le implementazioni che risolvono le incoerenze dei metadati del file system possono cancellare il valore di questo campo su 0. Tali implementazioni devono cancellare solo il valore di questo campo su 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, analogamente all'ordinamento di scrittura consigliato descritto nella sezione 8.1.

Campo MediaFailure 3.1.13.3

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 nel fat come cluster "non valido"

  • 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 individuare eventuali errori multimediali e registrano tutti gli errori come cluster "non valido" nel fat (o in caso contrario risolvere gli errori multimediali) possono cancellare il valore di questo campo su 0.

3.1.13.4 Campo ClearToZero

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, il che significa che le implementazioni cancellano questo campo su 0 prima di modificare le strutture, le directory o i file del file system

Campo 3.1.14 BytePerSectorShift

Il campo BytesPerSectorShift 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 valido di valori per questo campo deve essere:

  • Almeno 9 (dimensione del settore di 512 byte), ovvero 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 personal computer

3.1.15 SectorsPerClusterShift 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 valido di valori per questo campo deve essere:

  • Almeno 0 (1 settore per cluster), ovvero 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 fat e bitmap di allocazione contenute nel volume.

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

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

  • 2, che indica che il volume contiene il primo FAT, il secondo FAT, la prima bitmap di allocazione e la seconda bitmap di allocazione; questo valore è valido solo per i volumi TexFAT

3.1.17 DriveSelect Field

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

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 allocati.

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

  • Tra 0 e 100 inclusi, ovvero la percentuale di cluster allocati nell'heap del cluster, arrotondata per difetto all'intero più vicino

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

Le implementazioni modificheranno 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'area principale o Backup'area di avvio. Quando si fa riferimento al settore Backup boot, le implementazioni considerano questo campo come obsoleto.

Campo BootCode 3.1.19

Il campo BootCode deve contenere istruzioni di strapping 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 avvio-strapping devono inizializzare ogni byte in questo campo a F4h (l'istruzione di interruzione per le CPU comuni nei personal computer) come parte dell'operazione di formato.

Campo BootSignature 3.1.20

Il campo BootSignature descrive se l'intento 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 principali e Backup settori di avvio estesi

Ogni settore dei principali settori di avvio esteso ha la stessa struttura; Tuttavia, ogni settore può contenere istruzioni distinte per l'strapping di avvio (vedere la tabella 6). Gli agenti di strapping di avvio, ad esempio le istruzioni di avvio nel settore main boot, le implementazioni alternative del BIOS o il firmware di un sistema incorporato, possono caricare questi settori ed eseguire le istruzioni contenute.

Il Backup settori di avvio esteso è un backup dei principali settori di avvio esteso e ha la stessa struttura (vedere la tabella 6).

Prima di eseguire le istruzioni di Main o Backup Extended Boot Sector, le implementazioni devono verificare il contenuto assicurando che il campo ExtendedBootSignature di ogni settore contenga il relativo valore prescritto.

Mentre l'operazione di formato iniziale inizializza il contenuto sia del main che del Backup settori di avvio esteso, le implementazioni possono aggiornare questi settori (e aggiorneranno anche il rispettivo checksum di avvio) in base alle esigenze.

Tabella 6 Struttura del settore di avvio esteso

Nome campo

Offset

(byte)

Size

(byte)

Commenti
ExtendedBootCode 0 2BytesPerSectorShift - 4

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

Nota: i settori principale e Backup boot 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 principale e Backup boot contengono entrambi il campo BytesPerSectorShift.

3.2.1 Campo ExtendedBootCode

Il campo ExtendedBootCode deve contenere istruzioni per l'strapping 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 strapping di avvio inizializzano ogni byte in questo campo a 00h come parte dell'operazione di formato.

3.2.2 Campo ExtendedBootSignature

Il campo ExtendedBootSignature descrive se l'intento di un determinato settore deve essere un settore di avvio esteso o meno.

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

3.3 Sotto-aree principali e Backup parametri OEM

La sotto-area Principale dei parametri OEM 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 Parametri generici (vedere la sezione 3.3.2). I produttori possono derivare le proprie strutture di parametri personalizzati dal modello Parametri generici. Questa specifica definisce due strutture di parametri: Parametri Null (vedere la sezione 3.3.3) e Flash parametri (vedere la sezione 3.3.4).

Il Backup parametri OEM è un backup dei parametri OEM principali e ha la stessa struttura (vedere la tabella 7).

Prima di usare il contenuto di Main o Backup parametri OEM, le implementazioni verificheranno il contenuto convalidando il rispettivo checksum di avvio.

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

Le implementazioni possono aggiornare i parametri Main e Backup OEM in base alle esigenze e aggiornare anche il rispettivo checksum di avvio.

Tabella 7 Struttura dei parametri OEM

Nome campo

Offset

(byte)

Size

(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 definisce il contenuto.
Riservato 480 2BytesPerSectorShift - 480

Questo campo è obbligatorio e il relativo contenuto è riservato.

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

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)

Size

(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)

Size

(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 dei parametri Flash per ottimizzare le operazioni di accesso durante le operazioni di lettura/scrittura e per l'allineamento delle strutture del file system che durano la formattazione del supporto.

Il supporto per la struttura parametri Flash è facoltativo.

Tabella 10 Flash Struttura parametri

Nome campo

Offset

(byte)

Size

(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 ne 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 privo di significato (le implementazioni ignorano il campo specificato).

3.3.4.1 Campo ParametersGuid

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}.

3.3.4.2 Campo EraseBlockSize

Il campo EraseBlockSize 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 che il supporto flash ha a disposizione per le sue operazioni interne di risparmio.

Campo RandomAccessTime 3.3.4.5

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

Campo ProgrammingTime 3.3.4.6

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

Campo ReadCycle 3.3.4.7

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

Campo WriteCycle 3.3.4.8

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

3.4 Aree secondarie main e Backup Boot Checksum

I checksum principale e Backup boot contengono uno schema ripetuto del checksum a quattro byte del contenuto di tutte le altre aree secondarie nelle rispettive aree di avvio. Il calcolo del 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 la rispettiva area secondaria del checksum di avvio dall'inizio alla fine della sottoarea.

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

Mentre l'operazione di formato iniziale popola sia main che Backup checksum di avvio con il modello di checksum ripetuto, le implementazioni aggiorneranno questi settori man mano che il contenuto degli altri settori nelle rispettive aree di avvio cambia.

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

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

Il campo ActiveFat del campo VolumeFlags descrive quale FAT è attivo. Solo il campo VolumeFlags nel settore principale è corrente. Le implementazioni devono considerare fat che non è attivo come obsoleto. L'uso del fat inattivo e il passaggio tra le FTS è specifico dell'implementazione.

4.1 Prima e Seconda sotto-aree FAT

Un FAT descrive le catene di cluster nell'heap 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 del file system. Un fat rappresenta una catena di cluster come elenco collegato in modo singly degli indici del cluster. Ad eccezione delle prime due voci, ogni voce in un fat rappresenta esattamente un cluster.

Tabella 11 Struttura della tabella di allocazione file

Nome campo

Offset

(byte)

Size

(byte)

Commenti
FatEntry[0] 0 4 Questo campo è obbligatorio e la sezione 4.1.1 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 principale e Backup di avvio contengono entrambi il campo ClusterCount.

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

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

Nota: i campi Main e Backup Boot Sectors 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 Campo FatEntry[1]

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

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

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

Ogni campo FatEntry in questa matrice deve rappresentare un cluster nell'heap del cluster. FatEntry[2] rappresenta il primo cluster nell'heap cluster e in 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, inclusi, 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 FFFFFFF7h, che contrassegna il cluster corrispondente di FatEntry specificato come "cattivo"

  • Esattamente FFFFFFFFh, che contrassegna il cluster corrispondente di FatEntry specificato come ultimo cluster di una catena di cluster; questo è l'unico valore valido per l'ultima fatEntry di una determinata catena di cluster

5 Area dati

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

5.1 Area secondaria dell'heap cluster

La struttura dell'heap cluster è molto semplice (vedere la tabella 12); ogni serie consecutiva di settori descrive un cluster, come definisce il campo SectorsPerClusterShift. È importante che il primo cluster dell'heap cluster abbia l'indice 2, 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 heap cluster

Nome campo

Offset

(settore)

Size

(settori)

Commenti
Cluster[2] ClusterHeapOffset 2SectorsPerClusterShift

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

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

.

.

.

.

.

.

.

.

.

.

.

.

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

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

Nota: i settori principale e Backup di avvio 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)

Size

(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)

Size

(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)

Size

(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* 2BytesPerSectorShift

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)

Size

(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.

6.3.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.3.2 Campo SecondaryCount

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 valido di valori 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 255 voci di directory successive e questa voce di directory primaria comprende il set di voci di directory

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

6.3.3 Campo SetChecksum

Il campo SetChecksum conterrà 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 verificheranno 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 immissione 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 Campo GeneralePrimaryFlags

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

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

Tabella 17 Generic GeneralPrimaryFlags - Struttura dei campi

Nome campo

Offset

(bit)

Size

(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 AllocationPossible 6.3.4.1

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

I valori validi per questo campo devono essere:

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

  • 1, ovvero un'allocazione associata di cluster è possibile e i campi FirstCluster e DataLength sono definiti

Campo NoFatChain 6.3.4.2

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

I valori validi per questo campo devono essere:

  • 0, il 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 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 devono interpretarle; Le implementazioni possono usare l'equazione seguente per calcolare le dimensioni dell'allocazione associata: DataLength / (2SectorsPerClusterShift* 2BytesPerSectorShift) arrotondata al numero intero più vicino

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

6.3.5 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.

Le strutture di immissione 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 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.

Le strutture di immissione 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 directory secondaria generica

Lo scopo centrale delle voci di directory secondarie è fornire informazioni aggiuntive su un set di voci di directory. La possibilità di interpretare il modello Generic Secondary DirectoryEntry è obbligatoria.

La definizione delle voci di directory secondarie critiche e non dannose è correlata al numero di revisione exFAT secondario. Il supporto per qualsiasi voce di directory secondaria critica o non dannosa questa specifica, o specifiche successive, definisce è facoltativo.

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

Tabella 18 Modello directory secondaria generica

Nome campo

Offset

(byte)

Size

(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 EntryType 6.4.1

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

Campo TypeCode 6.4.1.1

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

6.4.1.2 Campo Di importazione

Il campo TypeImportance deve essere conforme alla definizione fornita nel modello DirectoryEntry generico (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 fondamentali per la gestione corretta del set di voci di directory che lo contiene. 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)

Size

(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)

Size

(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)

Size

(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)

Size

(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 principale e Backup di avvio contengono entrambi il campo ClusterCount.

Riservato ClusterCount (DataLength * 8) - ClusterCount

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

Nota: i settori principale e Backup di avvio 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)

Size

(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 di maiuscole/minuscole non identity sono in grassetto)

Dopo la formattazione di un volume, le implementazioni possono generare una tabella in formato up-case 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 "minuscoli" e "maiuscoli" sono equivalenti. Le implementazioni comprimono una tabella up-case rappresentando una serie di mapping di identità con il valore FFFFh seguito dal 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/minuscole compresse:

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, da 0061 a 0063h, eseguono rispettivamente il mapping ai caratteri da 0041h a 0043h.

La possibilità di fornire una tabella up case compressa al momento della formattazione di un volume è facoltativa. Tuttavia, la possibilità di interpretare sia una tabella non compressa che una tabella up case compressa è 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 Tabella 25), per cui il valore del campo TableChecksum è E619D30Dh.

Se un'implementazione definisce la propria tabella up-case, compressa o non compressa, tale tabella copre l'intervallo di caratteri Unicode completo (dai codici di carattere 0000h all'inclusione FFFFh).