Specifica file system exFAT

1 Introduzione

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

1.1 Obiettivi di progettazione

Il modello exFAT file system tre obiettivi di progettazione centrali (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 relativa semplicità e facilità di implementazione. Nell'anima dei predecessori, gli implementatori dovrebbero trovare exFAT relativamente semplice e facile da implementare.

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

    L'file system exFAT usa 64 bit per descrivere le dimensioni del file, consentendo così applicazioni che dipendono da file di dimensioni molto grandi. L'file system exFAT consente anche cluster di dimensioni fino a 32 MB, consentendo in modo efficace dispositivi di archiviazione di grandi dimensioni.

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

    L'file system exFAT incorpora l'estendibilità nella progettazione, consentendo al file system di tenere il passo con le innovazioni nell'archiviazione e i cambiamenti 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 "deve" per descrivere un comportamento obbligatorio.
Dovrebbe Questa specifica usa il termine "should" per descrivere un comportamento fortemente consigliato, ma non 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 deve interpretare come descrive questa specifica.
Facoltativo Questo termine descrive un campo o una struttura che un'implementazione può supportare o meno. Se un'implementazione supporta un campo o una struttura facoltativa specifica, deve modificare e interpretare il campo o la struttura come descritto in 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, deselezionare zero quando si impostano i campi o le strutture circostanti) e non deve interpretare per contenere alcun significato specifico.
Riservato

Questo termine descrive il contenuto del campo o della struttura per le implementazioni seguenti:

  1. Deve inizializzare su zero e non deve essere utilizzato per alcun 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 Full text degli acronimi comuni

Questa specifica usa acronimi in uso comune nel settore personal computer (vedere la tabella 2).

Tabella 2 Full Text 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 sicuro per le transazioni
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 seguente), a meno che la specifica non venga indicata diversamente.

  1. Sono senza segno

  2. Usare la notazione decimale per descrivere i valori, se non diversamente specificato; questa specifica usa la lettera successiva alla correzione "h" per indicare i numeri esadecimali e racchiude i GUID tra parentesi graffe

  3. Sono in formato little-endian

  4. Non è necessario un carattere di terminazione Null per le stringhe

1.5 Windows CE e TexFAT

TexFAT è un'estensione di exFAT che aggiunge una semantica operativa sicura per le transazioni sulla base file system. TexFAT viene usato da Windows CE. TexFAT richiede l'uso dei due FAT e delle bitmap di allocazione da usare nelle transazioni. Definisce anche diverse strutture aggiuntive, tra cui descrittori di spaziatura interna e descrittori di sicurezza.

2 Struttura del volume

Un volume è il set di tutte le strutture file system dati 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 sotto-area è obbligatoria e la Sezione 3.1 ne definisce il contenuto.
Settori di avvio estesi principali 1 8 Questa sotto-area è obbligatoria e la sezione 3.2ne definisce il contenuto.
Parametri OEM principali 9 1 Questa sotto-area è obbligatoria e la sezione 3.3 ne definisce il contenuto.
Riservato principale 10 1 Questa area secondaria è obbligatoria e il relativo contenuto è riservato.
Checksum di avvio principale 11 1 Questa sotto-area è obbligatoria e la Sezione 3.4 ne definisce il contenuto.
Area di avvio del backup
Settore di avvio del backup 12 1 Questa sotto-area è obbligatoria e la Sezione 3.1 ne definisce il contenuto.
Settori di avvio estesi di backup 13 8 Questa sotto-area è obbligatoria e la sezione 3.2 ne definisce il contenuto.
Parametri OEM di backup 21 1 Questa sotto-area è obbligatoria e la sezione 3.3 ne definisce il contenuto.
Backup riservato 22 1 Questa area secondaria è obbligatoria e il relativo contenuto è riservato.
Checksum di avvio del backup 23 1 Questa sotto-area è 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 sotto-area è 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.

Seconda fat FatOffset + FatLength FatLength * (NumberOfFats – 1)

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

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

Area dati
Allineamento 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.

Cluster Heap ClusterHeapOffset ClusterCount * 2SectorsPerClusterShift

Questa sotto-area è 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 principale e di backup

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

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

  2. Identificare il file system nel volume come exFAT.

  3. Individuare la posizione delle strutture file system exFAT.

L'area Avvio backup è un backup dell'area avvio principale. Consente il ripristino del volume exFAT nel caso in cui l'area di avvio principale sia in uno stato incoerente. Ad eccezione di casi poco frequenti, ad esempio l'aggiornamento delle istruzioni di avvio, le implementazioni non devono modificare il contenuto dell'area Di avvio backup.

3.1 Sottoaree del settore di avvio principale e di backup

Il settore di avvio principale contiene il codice per l'avvio da un volume exFAT e i parametri exFAT fondamentali che descrivono la struttura del volume (vedere la tabella 4). BIOS, MBR o altri agenti di avvio possono esaminare questo settore e caricare ed eseguire le istruzioni di avvio contenute in tale settore.

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 trattano il contenuto dei campi VolumeFlags e PercentInUse come non obsoleti.

Prima di usare il contenuto del settore di avvio principale o di backup, le implementazioni devono verificarne il contenuto convalidando il checksum di avvio corrispondente e verificando che tutti i campi siano entro l'intervallo di valori validi.

Mentre l'operazione di formattazione iniziale iniziali inizialirà 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 checksum di avvio corrispondente (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.
Flag volume 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.
SettoriPerClusterShift 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.
Selezione unità 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.
Codice di avvio 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.
Spazio in eccesso 512 2BytesPerSectorShift – 512

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

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

3.1.1 JumpBoot Field

Il campo JumpBoot conterrà l'istruzione di salto per le CPU comuni nei personal computer, che, quando eseguita, "salta" la CPU per eseguire le istruzioni di avvio nel campo BootCode.

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

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

3.1.4 Campo PartitionOffset

Il campo PartitionOffset deve descrivere l'offset di settore relativo ai supporti della partizione che ospita il volume exFAT specificato. Questo campo favorisce l'avvio dal 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.

3.1.5 Campo VolumeLength

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

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

  • Almeno2 20/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 di questo campo è ClusterHeapOffset + (232- 11) * 2SectorsPerClusterShift.

3.1.6 Campo FatOffset

Il campo FatOffset descrive l'offset del settore relativo al volume della prima fat. Questo campo consente alle implementazioni di allineare la prima FAT alle caratteristiche del supporto di archiviazione sottostante.

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

  • Almeno 24, che rappresenta i settori utilizzati dall'avvio principale e dall'avvio di backup

  • Al massimo ClusterHeapOffset - (FatLength NumberOfFats), che rappresenta i settori utilizzati * dall'heap del 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 FAT).

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

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

  • Al massimo (ClusterHeapOffset - FatOffset) / NumberOfFats arrotondato per eccesso all'intero più vicino, che garantisce l'esistenza dei fat prima dell'heap del cluster

Questo campo può contenere un valore superiore al limite inferiore (come descritto in precedenza) per consentire anche l'allineamento della seconda FAT, se presente, alle caratteristiche del supporto di archiviazione sottostante. Il contenuto dello spazio che supera quello richiesto dalla fat stessa, se presente, non è definito.

3.1.8 Campo ClusterHeapOffset

Il campo ClusterHeapOffset descrive 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 deve essere:

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

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

3.1.9 Campo ClusterCount

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

Il valore valido per questo campo deve essere minore di quanto segue:

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

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

Il valore del campo ClusterCount determina le dimensioni minime di una 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 non più di 2cluster da 24a 2 nell'heap cluster. Tuttavia, le implementazioni devono essere in grado di gestire i volumi con un massimo di 2cluster da 32a 11 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 negativo dopo l'utilizzo della mappa di bit di allocazione e della tabella up case nei cluster.

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

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

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

3.1.11 Campo VolumeSerialNumber

Il campo VolumeSerialNumber deve contenere un numero di serie univoco. Ciò consente alle implementazioni di distinguere tra i diversi volumi exFAT. Le implementazioni devono generare il numero di serie combinando la data e l'ora di formattazione del volume exFAT. Il meccanismo per combinare data e ora per formare un numero di serie è specifico dell'implementazione.

Tutti i valori possibili per questo campo sono validi.

3.1.12 Campo FileSystemRevision

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

Il byte più alto è il numero di revisione principale e il byte meno significativo è il numero di revisione secondario. Ad esempio, se il byte di ordine elevato contiene il valore 01h e se il byte di ordine più 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 di ordine più 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 meno significativo 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 montare alcun volume exFAT con altri numeri di revisione principali. Le implementazioni rispettano il numero di revisione secondario e non devono eseguire operazioni o creare strutture file system non descritte nella specifica corrispondente del numero di revisione secondario specificato.

3.1.13 Campo VolumeFlags

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

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

Tabella 5 Struttura dei campi VolumeFlags

Nome campo

Offset

(bit)

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 il relativo contenuto è riservato.
3.1.13.1 Campo ActiveFat

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

  • 0, ovvero la prima bitmap FAT e la prima bitmap di allocazione sono attive

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

Le implementazioni considerano inattivi FAT e Bitmap di allocazione come non obsoleti. Solo le implementazioni in grado di riconoscere TexFAT devono cambiare le bitmap fat e di allocazione attive (vedere la sezione 7.1).

3.1.13.2 Campo VolumeDirty

Il campo VolumeDirty deve indicare se il volume è dirty o meno, come indicato di seguito:

  • 0, ovvero il volume è probabilmente in uno stato coerente

  • 1, ovvero 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, al momento del montaggio di un volume, il valore di questo campo è 1, solo le implementazioni che risolvono file system incoerenze dei metadati possono cancellare il valore di questo campo su 0. Tali implementazioni devono cancellare il valore di questo campo su 0 solo dopo aver file system che si trova in uno stato coerente.

Se, al momento del 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 questo campo su 0 in seguito, in modo analogo all'ordinamento di scrittura consigliato descritto nella Sezione 8.1.

3.1.13.3 Campo MediaFailure

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

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

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

Un'implementazione deve impostare questo campo su 1 quando:

  1. Il supporto di hosting non riesce ad accedere a qualsiasi area nel volume

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

Se, al momento del montaggio di un volume, il valore di questo campo è 1, le implementazioni che analizzano l'intero volume alla ricerca di errori dei supporti e registrano tutti gli errori come cluster "non valido" nella FAT (o in caso contrario risolvono gli errori dei supporti) 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, ovvero le implementazioni devono cancellare il campo su 0 prima di modificare file system, directory o file

Campo BytesPerSectorShift 3.1.14

Il campo BytesPerSectorShift deve descrivere 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), che è il settore più piccolo possibile per un volume exFAT

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

3.1.15 SettoriPerClusterShift Campo

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), che è il cluster più piccolo possibile

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

3.1.16 Campo NumberOfFats

Il campo NumberOfFats deve descrivere il numero di fat e bitmap di allocazione contenuti nel volume.

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

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

  • 2, che indica che il volume contiene la prima fat, la seconda 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 consente l'avvio da questo volume usando INT 13h esteso nei personal computer.

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

3.1.18 Campo PercentInUse

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

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 esere al numero intero più vicino

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

Le implementazioni modificano il valore di questo campo per riflettere le modifiche nell'allocazione dei cluster nell'heap del cluster o lo modificano in FFh.

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

3.1.19 Campo BootCode

Il campo BootCode deve contenere istruzioni di boot-strapping. Le implementazioni possono popolare questo campo con le istruzioni della CPU necessarie per l'avvio di un sistema informatico. Le implementazioni che non forniscono istruzioni di boot-strapping devono inizializzare ogni byte in questo campo su F4h (l'istruzione di arresto per le CPU comuni nei personal computer) come parte del relativo funzionamento del formato.

3.1.20 Campo BootSignature

Il campo BootSignature descrive se lo scopo 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 a seconda di qualsiasi altro campo nel rispettivo settore di avvio.

3.2 Sottoreti principali e di backup dei settori di avvio estesi

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

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

Prima di eseguire le istruzioni dei settori di avvio principale o di backup esteso, le implementazioni devono verificarne il contenuto assicurando che il campo ExtendedBootSignature di ogni settore contenga il valore prescritto.

Mentre l'operazione di formattazione iniziale iniziali inizialirà il contenuto dei settori di avvio principale e di avvio esteso di backup, le implementazioni possono aggiornare questi settori (e aggiornano 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 avvio. Le implementazioni possono popolare questo campo con le istruzioni della CPU necessarie per l'avvio di un sistema informatico. Le implementazioni che non forniscono istruzioni 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 deve indicare se la finalità di un determinato settore è che sia un settore di avvio esteso o meno.

Il valore valido per questo campo è AA550000h. Qualsiasi altro valore in questo campo invalida il rispettivo settore di avvio principale o di backup esteso. 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 Sottoreti principali e parametri OEM di backup

La sotto-area 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 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 Parametri Flash (vedere La sezione 3.3.4).

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

Prima di usare il contenuto dei parametri OEM Main o Backup, le implementazioni devono verificarne il contenuto convalidando il checksum di avvio corrispondente.

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

Le implementazioni possono aggiornare i parametri OEM Principale e Backup in base alle esigenze (e devono anche aggiornare 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 il relativo contenuto è riservato.

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

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

Ogni campo Parameters in questa matrice contiene una struttura di parametri, che deriva dal modello Generic Parameters (vedere la sezione 3.3.2). Tutti i campi Parametri inutilizzati devono essere descritti come contenenti una struttura di parametri Null (vedere la sezione 3.3.3).

3.3.2 Modello di parametri generici

Il modello Parametri generici fornisce la definizione di base di una struttura di parametri (vedere la tabella 8). Tutte le strutture di parametri 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
Guida ai parametri 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.
3.3.2.1 Campo ParametersGuid

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

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

3.3.3 Parametri Null

La struttura Parametri Null deriva dal modello Parametri generici (vedere la sezione 3.3.2)e deve descrivere un campo Parametri inutilizzati (vedere la tabella 9). Quando si crea o si aggiorna la struttura dei parametri OEM, le implementazioni popolano i campi parameters inutilizzati con la struttura Parametri Null. Inoltre, durante la creazione o l'aggiornamento della struttura Parameters OEM, le implementazioni devono consolidare le strutture dei parametri Null alla fine della matrice, lasciando tutte le altre strutture Parameters all'inizio della struttura Parameters OEM.

Il supporto per la struttura Dei parametri Null è obbligatorio.

Struttura dei parametri Null della tabella 9

Nome campo

Offset

(byte)

Dimensioni

(byte)

Commenti
Guida ai parametri 0 16 Questo campo è obbligatorio e la sezione 3.3.3.1 ne definisce il contenuto.
Riservato 16 32 Questo campo è obbligatorio e il relativo contenuto è riservato.
3.3.3.1 Campo ParametersGuid

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 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 contenute nella struttura Parametri flash per ottimizzare le operazioni di accesso durante le operazioni di lettura/scrittura e per l'allineamento delle strutture file system che modificano la formattazione dei supporti.

Il supporto per la struttura Parametri Flash è facoltativo.

Tabella 10 Struttura dei parametri flash

Nome campo

Offset

(byte)

Dimensioni

(byte)

Commenti
Guida ai parametri 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 il relativo contenuto è riservato.

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

3.3.4.1 ParametersGuid Field

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.

3.3.4.3 Campo PageSize

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

3.3.4.4 Campo SpareSectors

Il campo SpareSectors descrive il numero di settori disponibili per le operazioni interne di sparing dei supporti flash.

3.3.4.5 Campo RandomAccessTime

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

3.3.4.6 Campo ProgrammingTime

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

3.3.4.7 Campo ReadCycle

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

3.3.4.8 Campo WriteCycle

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

3.4 Sottoreti principali e di checksum di avvio di backup

I checksum di avvio principale e di backup contengono ognuno un modello ripetuto del checksum a 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 sottoarea boot checksum dall'inizio alla fine dell'area secondaria.

Prima di usare il contenuto di una delle altre aree secondarie nelle aree Principale o Avvio backup, le implementazioni devono verificarne il contenuto convalidando il checksum di avvio corrispondente.

Mentre l'operazione di formattazione iniziale popola i checksum di avvio principale e di backup con il modello di checksum ripetuto, le implementazioni aggiornano questi settori quando 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 di allocazione file

L'area Tabella di allocazione file (FAT) può contenere fino a due fat, una nella prima sottoarea FAT e l'altra nella seconda sottoarea FAT. Il campo NumberOfFats descrive il numero di domande frequenti contenute in questa area. I valori validi per il campo NumberOfFats sono 1 e 2. Pertanto, la prima sottoarea FAT contiene sempre una fat. Se il campo NumberOfFats è due, anche la seconda sottoarea FAT contiene un file FAT.

Il campo ActiveFat del campo VolumeFlags descrive quale FAT è attivo. Solo il campo VolumeFlags nel settore di avvio principale è corrente. Le implementazioni trattano la FAT che non è attiva come non obsoleta. L'uso della FAT inattiva e il passaggio da un fat all'altro è specifico dell'implementazione.

4.1 Prime e seconde sottoaree FAT

Una FAT deve descrivere le catene di 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 file system strutture. Una FAT rappresenta una catena di cluster come elenco di indici del cluster collegati in modo singly. Ad eccezione delle prime due voci, ogni voce in una 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 Campo FatEntry [ 0 ]

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

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 alcun elemento di interesse.

Il valore valido per questo campo è FFFFFFFFh. Le implementazioni devono inizializzare questo campo sul valore prescritto e non devono usare questo campo per alcun scopo. Le implementazioni non devono interpretare questo campo e devono mantenere 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:

  • Tra 2 e ClusterCount + 1, inclusivamente, che punta al fatEntry successivo nella catena di cluster specificata; l'oggetto FatEntry specificato non deve puntare a fatEntry che lo precede nella catena di cluster specificata

  • Esattamente FFFFFFF7h, che contrassegna il cluster corrispondente di FatEntry specificato come "bad"

  • 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'ultimo FatEntry di una catena di cluster specificata

5 Area dati

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

5.1 Sotto-area heap cluster

La struttura dell'heap del cluster è molto semplice (vedere la tabella 12). ogni serie consecutiva di settori descrive un cluster, come definisce il campo SectorsPerClusterShift. È importante notare che il primo cluster dell'heap del cluster ha 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 una 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 [ Cluster ClusterCount+1 ]

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

6 Struttura di directory

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

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

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 qualcosa di interessante, ad esempio una file system, una sottodirectory o un file.

Tabella 13 Struttura della 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 le dimensioni di un campo DirectoryEntry, 32 byte.

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

Ogni campo DirectoryEntry in questa matrice deriva dal modello DirectoryEntry generico (vedere la Sezione 6.2).

6.2 Modello DirectoryEntry generico

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

Tabella 14 Modello 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 ha tre modalità di utilizzo definite dal valore del campo (vedere l'elenco seguente).

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

    • Tutti gli altri campi nell'oggetto DirectoryEntry specificato 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 in base alle esigenze

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

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

    • Le voci di directory non utilizzate sono valide solo al di fuori dei set di voci di directory

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

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

  • Tra 81h e FFh in modo inclusivo, che è una normale voce di directory e si applicano le condizioni seguenti:

    • Il contenuto del campo EntryType (vedere la tabella 15)determina il layout del resto 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 al campo InUse (vedere la Sezione 6.2.1.4)causando erroneamente un marcatore di fine directory, il valore 80h non è valido.

Tabella 15 Struttura del campo EntryType generico

Nome campo

Offset

(bit)

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.
6.2.1.1 Campo TypeCode

Il campo TypeCode descrive parzialmente il tipo specifico della voce di directory specificata. Questo campo, più i campi TypeImportance e TypeCategory (vedere rispettivamente Sezione 6.2.1.2 e Sezione 6.2.1.3)identificano in modo univoco il tipo di 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.

6.2.1.2 Campo TypeImportance

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

I valori validi per questo campo devono essere:

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

  • 1, ovvero la voce di directory specificata è benigna (vedere rispettivamente Sezione 6.3.1.2.2 e Sezione 6.4.1.2.2 per le voci di directory secondarie non dannose)

6.2.1.3 Campo TypeCategory

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

I valori validi per questo campo devono essere:

  • 0, ovvero la voce di directory specificata è primaria (vedere la Sezione 6.3)

  • 1, ovvero la voce di directory specificata è secondaria (vedere la Sezione 6.4)

6.2.1.4 Campo InUse

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

I valori validi per questo campo devono essere:

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

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

6.2.2 Campo FirstCluster

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

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

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

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

Le strutture che derivano da questo modello possono ridefinire entrambi 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 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 di questo campo è 0

  • Al massimo ClusterCount * 2SectorsPerClusterShift * 2BytesPerSectorShift

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

6.3 Modello directory primaria generica

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 directory devono essere voci di directory secondarie (vedere la Sezione 6.4).

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

Tutte le strutture di voci di directory primarie derivano dal modello DirectoryEntry primario generico (vedere la tabella 16),che deriva dal modello DirectoryEntry generico (vedere la Sezione 6.2).

Tabella 16 Generic Primary DirectoryEntry Template

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.

6.3.1 Campo EntryType

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

6.3.1.1 Campo TypeCode

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

6.3.1.2 Campo TypeImportance

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

6.3.1.2.1 Voci di directory primarie critiche

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

La definizione di voci di directory primarie critiche è correlata al numero di revisione exFAT principale. 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 Voci di directory primarie non valide

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

La definizione di voci di directory primarie non dannose è correlata al numero di revisione exFAT secondario. Il supporto per qualsiasi voce di directory primaria non valida definita da questa specifica o da qualsiasi specifica successiva è facoltativo. Una voce di directory primaria 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).

6.3.1.3 Campo TypeCategory

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 deve essere 0.

6.3.1.4 Campo InUse

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 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 deve essere:

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

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

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

6.3.3 Campo SetChecksum

Il campo SetChecksum 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 verificano 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 voci di directory primarie critiche che derivano da questo modello possono ridefinire entrambi i campi SecondaryCount e SetChecksum.

Figura 2 Calcolo entrySetChecksum

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

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

6.3.4 Campo 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 dei campi Generic GeneralPrimaryFlags

Nome campo

Offset

(bit)

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.
6.3.4.1 AllocationPossible Field

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 devono essere:

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

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

6.3.4.2 Campo NoFatChain

Il campo NoFatChain indica se la FAT attiva descrive o meno la catena di cluster dell'allocazione specificata.

I valori validi per questo campo devono essere:

  • 0, ovvero le voci FAT corrispondenti per la catena di cluster dell'allocazione sono valide e le implementazioni le interpretano; 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, ovvero 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) arrotondato per es.

Se le strutture di voci di directory primarie critiche che derivano da questo modello ridefinino il campo GeneralPrimaryFlags, le voci FAT corrispondenti per la catena di cluster dell'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 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 DirectoryEntry generico (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 di directory secondarie è 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 non dannose è correlata al numero di revisione secondario exFAT. Il supporto per qualsiasi voce di directory secondaria critica o non valida definita da questa specifica o da specifiche successive è facoltativo.

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

Tabella 18 Modello directory secondaria generica

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.

6.4.1 Campo EntryType

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

6.4.1.1 Campo TypeCode

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 TypeImportance

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 appropriata del relativo set di voci di directory contenitore. Anche se il supporto per qualsiasi voce di directory secondaria critica specifica è facoltativo, una voce di directory critica non riconosciuta rende non riconosciuto l'intero set di voci di directory (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 a qualsiasi voce di directory nel set di voci di directory (le voci della directory file 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 relativo set di voci di directory contenitore. Il supporto per qualsiasi voce di directory secondaria non dannosa specifica è facoltativo. Le voci di directory secondarie non riconoscite non vengono riconosciate come non riconoscite per l'intero set di voci di directory.

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

6.4.1.3 Campo TypeCategory

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 InUse

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

6.4.2 Campo GeneralSecondaryFlags

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

Tabella 19 Struttura dei campi Generic GeneralSecondaryFlags

Nome campo

Offset

(bit)

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

6.4.2.2 Campo 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).

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, anche DataLength deve 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 di directory bitmap di allocazione

Nella tabella exFAT file system fat non descrive lo stato di allocazione dei cluster. invece di una bitmap di allocazione. Le bitmap di allocazione sono presenti 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 di directory Allocation Bitmap valide nella directory radice. Se il campo NumberOfFats contiene il valore 1, l'unico numero valido di voci di directory Allocation Bitmap è 1. Inoltre, la voce di directory Allocation Bitmap (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 di directory Allocation Bitmap è 2. Inoltre, le due voci della directory Allocation Bitmap sono valide solo se una descrive la prima bitmap di allocazione e l'altra descrive la seconda bitmap di allocazione.

Tabella 20 Struttura DirectoryEntry della bitmap allocation

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

7.1.1 Campo EntryType

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

7.1.1.1 Campo TypeCode

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

Per una voce della directory Allocation Bitmap, il valore valido per questo campo è 1.

7.1.1.2 Campo TypeImportance

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

Per una voce della directory Allocation Bitmap, il valore valido per questo campo è 0.

7.1.1.3 Campo TypeCategory

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

7.1.1.4 Campo InUse

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

7.1.2 Campo BitmapFlags

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

Tabella 21 Struttura del campo BitmapFlags

Nome campo

Offset

(bit)

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 il relativo contenuto è riservato.
7.1.2.1 Campo BitmapIdentifier

Il campo BitmapIdentifier indicherà la bitmap di allocazione descritta dalla voce di directory specificata. Le implementazioni devono usare la prima bitmap di allocazione in combinazione con il primo FAT e useranno la seconda bitmap di allocazione insieme al secondo FAT. Il campo ActiveFat descrive quali fat e bitmap di allocazione sono attivi.

I valori validi per questo campo devono essere:

  • 0, ovvero 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 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 primaria generica (vedere la sezione 6.3.6).

7.1.5 Bitmap di 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 dall'indice più basso a quello più alto (vedere la tabella 22). Per motivi cronologici, il primo cluster ha l'indice 2. Nota: il primo bit nella bitmap è il bit più basso del primo byte.

Tabella 22 Struttura della bitmap di allocazione

Nome campo

Offset

(bit)

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

Riservato ClusterCount (DataLength * 8) - ClusterCount

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

Nota: i settori principale e di avvio del 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 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 potrebbe già utilizzare il cluster corrispondente o il fat attivo può descrivere il cluster corrispondente come non eroso)

7.2 Voce della directory della tabella up-case

La tabella Up-case definisce la conversione da caratteri minuscoli a caratteri maiuscoli. Ciò è importante perché la voce di directory Nome file (vedere la sezione 7.7) usa caratteri Unicode e il file system exFAT non fa distinzione tra maiuscole e minuscole e non fa 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 la tabella 23). Il numero valido di voci della directory Tabella maiuscole/minuscole è 1.

A causa della relazione tra la tabella Up-case e i nomi di file, le implementazioni non devono modificare la tabella Up-case, tranne in seguito a operazioni di formattazione.

Tabella 23 Struttura DirectoryEntry della tabella up case

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 il relativo contenuto è riservato.
TableChecksum 4 4 Questo campo è obbligatorio e la sezione 7.2.2 ne 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 ne definisce il contenuto.
Lunghezza dati 24 8 Questo campo è obbligatorio e la sezione 7.2.4 ne definisce il contenuto.

7.2.1 Campo EntryType

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

7.2.1.1 Campo TypeCode

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.

7.2.1.2 Campo 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 Tabella up case, il valore valido per questo campo è 0.

7.2.1.3 Campo TypeCategory

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

7.2.1.4 Campo InUse

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

7.2.2 Campo TableChecksum

Il campo TableChecksum contiene il checksum della tabella Up-case (descritta dai campi FirstCluster e DataLength). Le implementazioni verificano 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 dal 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).

7.2.5 Tabella up case

Una tabella up-case è una serie di mapping di caratteri Unicode. Un mapping dei caratteri è costituito da un campo a 2 byte, con l'indice del campo nella tabella maiuscole/minuscole che rappresenta il carattere Unicode di cui eseguire l'up-case e il campo a 2 byte che rappresenta il carattere Unicode con distinzione tra maiuscole e minuscole.

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

Le implementazioni che supportano solo caratteri dell'intervallo di mapping obbligatorio possono ignorare i mapping del resto della tabella up-case. Tali implementazioni devono usare solo caratteri dell'intervallo di mapping obbligatorio durante la creazione o la ridenominazione dei file (tramite la voce di directory Nome file, vedere la sezione 7.7). Quando si esegue l'up-casing dei nomi di file esistenti, tali implementazioni non devono eseguire l'up-case dei caratteri dell'intervallo di mapping non obbligatorio, ma devono lasciarli intatti nel nome file con distinzione tra maiuscole e minuscole risultante (si tratta di un up-casing parziale). Durante il confronto dei nomi di file, tali implementazioni devono considerare equivalenti i nomi di file che differiscono dal nome confrontato solo con i caratteri Unicode dell'intervallo di mapping non obbligatorio. Anche se tali nomi di file sono potenzialmente equivalenti, tali implementazioni non possono garantire che il nome di file completamente con distinzione tra maiuscole e minuscole non sia in conflitto con il nome in fase di confronto.

Tabella 24 Prime 128 voci obbligatorie della tabella up case

Indice 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 002 Dh 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 senza identità sono in grassetto.

Durante la formattazione di un volume, le implementazioni possono generare una tabella up-case in un formato compresso usando la compressione del mapping di identità, poiché gran parte dello spazio dei caratteri Unicode non ha alcun concetto di distinzione tra maiuscole e minuscole (il che significa che i caratteri "minuscoli" e "maiuscoli" sono equivalenti). Le implementazioni comprimeno una tabella up case rappresentando una serie di mapping di identità con il valore FFFFh seguito dal numero di mapping di identità.

Ad esempio, un'implementazione può rappresentare i primi mapping di 100 caratteri (64 ore) con le otto voci seguenti di una tabella up case compressa:

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

Le prime due voci indicano che i primi 97 (61h) caratteri (da 0000h a 0060h) hanno mapping di identità. I caratteri successivi, da 0061h a 0063h, vengono mappati rispettivamente 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 alla modalità di esistenza della tabella up case nel volume, che può essere in formato compresso o non compresso.

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

Se un'implementazione definisce la propria tabella up-case, compressa o non compressa, tale tabella dovrà coprire l'intervallo di caratteri Unicode completo (dai codici carattere 0000h a FFFFh inclusi).