Especificação do sistema de arquivos exFAT

  • Artigo

1 Introdução

O sistema de arquivos exFAT é o sucessor de FAT32 na família FAT de sistemas de arquivos. Essa especificação descreve o sistema de arquivos exFAT e fornece todas as informações necessárias para implementar o sistema de arquivos exFAT.

1.1 Metas de design

O sistema de arquivos exFAT tem três metas de design centrais (veja a lista abaixo).

  1. Mantenha a simplicidade dos sistemas de arquivos baseados em FAT.

    Dois dos pontos fortes dos sistemas de arquivos baseados em FAT são a simplicidade relativa e a facilidade de implementação. No espírito de seus antecessores, os implementadores devem achar o exFAT relativamente simples e fácil de implementar.

  2. Habilite arquivos muito grandes e dispositivos de armazenamento.

    O sistema de arquivos exFAT usa 64 bits para descrever o tamanho do arquivo, permitindo assim aplicativos que dependem de arquivos muito grandes. O sistema de arquivos exFAT também permite clusters de até 32 MB, habilitando efetivamente dispositivos de armazenamento muito grandes.

  3. Incorporar extensibilidade para inovação futura.

    O sistema de arquivos exFAT incorpora extensibilidade em seu design, permitindo que o sistema de arquivos acompanhe as inovações no armazenamento e as alterações no uso.

1.2 Terminologia específica

No contexto dessa especificação, determinados termos (consulte Tabela 1) têm um significado específico para o design e a implementação do sistema de arquivos exFAT.

Tabela 1 Definição de termos que têm um significado muito específico

Termo Definição
Deve Essa especificação usa o termo "deve" para descrever um comportamento obrigatório.
Recomendável Essa especificação usa o termo "deveria" para descrever um comportamento que ele recomenda fortemente, mas não torna obrigatório.
Mai Essa especificação usa o termo "pode" para descrever um comportamento opcional.
Obrigatório Este termo descreve um campo ou estrutura que uma implementação deve modificar e deve interpretar como esta especificação descreve.
Opcional Este termo descreve um campo ou estrutura que uma implementação pode ou não dar suporte. Se uma implementação der suporte a um determinado campo ou estrutura opcional, ela deverá modificar e interpretar o campo ou a estrutura como essa especificação descreve.
Indefinido Este termo descreve o conteúdo de campo ou estrutura que uma implementação pode modificar conforme necessário (ou seja, limpar para zero ao definir campos ou estruturas ao redor) e não deve interpretar para manter qualquer significado específico.
Reservado

Este termo descreve o conteúdo do campo ou da estrutura que implementa:

  1. Deve inicializar como zero e não deve ser usado para nenhuma finalidade

  2. Não deve interpretar, exceto ao calcular somas de verificação

  3. Deve preservar entre operações que modificam campos ou estruturas ao redor

1.3 Texto completo de acrônimos comuns

Essa especificação usa acrônimos em uso comum no setor de computadores pessoais (consulte a Tabela 2).

Tabela 2 Texto completo de acrônimos comuns

Acrônimo Texto Completo
ASCII Código padrão americano para intercâmbio de informações
BIOS Sistema de saída de entrada básico
CPU Unidade de Processamento Central
exFAT Tabela de alocação de arquivo extensível
FAT Tabela de alocação de arquivo
FAT12 Tabela de alocação de arquivo, índices de cluster de 12 bits
FAT16 Tabela de alocação de arquivo, índices de cluster de 16 bits
FAT32 Tabela de alocação de arquivo, índices de cluster de 32 bits
GPT Tabela de partição GUID
GUID Identificador Global exclusivo (consulte a Seção 10.1)
INT Interrupção
ativa a MBR (Registro Mestre de Inicialização)
Texfat ExFAT com segurança de transação
UTC Tempo Universal Coordenado UTC

1.4 Qualificadores padrão de campo e estrutura

Campos e estruturas nessa especificação têm os seguintes qualificadores (veja a lista abaixo), a menos que a especificação observe o contrário.

  1. Não assinados

  2. Use a notação decimal para descrever valores, em que não foi anotado de outra forma; esta especificação usa a letra pós-correção "h" para indicar números hexadecimais e inclui GUIDs em chaves

  3. Estão no formato little-endian

  4. Não exigir um caractere de terminação nula para cadeias de caracteres

1.5 Windows CE e TexFAT

TexFAT é uma extensão para exFAT que adiciona semântica operacional segura para transações sobre o sistema de arquivos base. TexFAT é usado por Windows CE. O TexFAT requer o uso das duas FATs e bitmaps de alocação para uso em transações. Ele também define várias estruturas adicionais, incluindo descritores de preenchimento e descritores de segurança.

2 Estrutura de Volume

Um volume é o conjunto de todas as estruturas do sistema de arquivos e o espaço de dados necessário para armazenar e recuperar dados do usuário. Todos os volumes exFAT contêm quatro regiões (consulte Tabela 3).

Estrutura de volume da Tabela 3

Nome da sub-região

Deslocamento

(setor)

Tamanho

(setores)

 Comentários
Região de Inicialização Principal
Setor de Inicialização Principal 0 1 Essa sub-região é obrigatória e a Seção 3.1 define seu conteúdo.
Principais setores de inicialização estendida 1 8 Essa sub-região é obrigatória e a Seção 3.2) define seu conteúdo.
Principais parâmetros OEM 9 1 Essa sub-região é obrigatória e a Seção 3.3 define seu conteúdo.
Principal Reservado 10 1 Essa sub-região é obrigatória e seu conteúdo é reservado.
Soma de verificação de inicialização principal 11 1 Essa sub-região é obrigatória e a Seção 3.4 define seu conteúdo.
Região de inicialização de backup
Setor de Inicialização de Backup 12 1 Essa sub-região é obrigatória e a Seção 3.1 define seu conteúdo.
Setores de inicialização estendida de backup 13 8 Essa sub-região é obrigatória e a Seção 3.2 define seu conteúdo.
Parâmetros OEM de backup 21 1 Essa sub-região é obrigatória e a Seção 3.3 define seu conteúdo.
Backup Reservado 22 1 Essa sub-região é obrigatória e seu conteúdo é reservado.
Soma de verificação de inicialização de backup 23 1 Essa sub-região é obrigatória e a Seção 3.4 define seu conteúdo.
Região FAT
Alinhamento fat 24 FatOffset – 24

Essa sub-região é obrigatória e seu conteúdo, se houver, é indefinido.

Observação: os setores Principal e inicialização de backup contêm o campo FatOffset.
Primeiro FAT FatOffset FatLength

Essa sub-região é obrigatória e a Seção 4.1 define seu conteúdo.

Observação: os setores Principal e inicialização de backup contêm os campos FatOffset e FatLength.
Segunda FAT FatOffset + FatLength FatLength * (NumberOfFats – 1)

Essa sub-região é obrigatória e a Seção 4.1 define seu conteúdo, se houver.

Observação: os setores Principal e inicialização de backup contêm os campos FatOffset, FatLength e NumberOfFats. O campo NumberOfFats só pode conter os valores 1 e 2.
Região de Dados
Alinhamento do heap de cluster FatOffset + FatLength * NumberOfFats ClusterHeapOffset – (FatOffset + FatLength * NumberOfFats)

Essa sub-região é obrigatória e seu conteúdo, se houver, é indefinido.

Observação: os setores Principal e inicialização de backup contêm os campos FatOffset, FatLength, NumberOfFats e ClusterHeapOffset. Os valores válidos do campo NumberOfFats são 1 e 2.
Cluster Heap ClusterHeapOffset ClusterCount * 2SetoresPerClusterShift

Essa sub-região é obrigatória e a Seção 5.1 define seu conteúdo.

Observação: os setores Principal e inicialização de backup contêm os campos ClusterHeapOffset, ClusterCount e SectorsPerClusterShift.
Excesso de espaço ClusterHeapOffset + ClusterCount * 2SetoresPerClusterShift VolumeLength – (ClusterHeapOffset + ClusterCount * 2SetoresPerClusterShift)

Essa sub-região é obrigatória e seu conteúdo, se houver, é indefinido.

Observação: os setores Principal e inicialização de backup contêm os campos ClusterHeapOffset, ClusterCount, SectorsPerClusterShift e VolumeLength.

3 Regiões principais e de inicialização de backup

A região inicialização principal fornece todas as instruções necessárias de inicialização, informações de identificação e parâmetros do sistema de arquivos para permitir que uma implementação execute o seguinte:

  1. Alça de inicialização de um sistema de computador de um volume exFAT.

  2. Identifique o sistema de arquivos no volume como exFAT.

  3. Descubra o local das estruturas do sistema de arquivos exFAT.

A região inicialização de backup é um backup da região inicialização principal. Ele auxilia na recuperação do volume exFAT no caso da região de Inicialização Principal estar em um estado inconsistente. Exceto em circunstâncias pouco frequentes, como atualizar instruções de inicialização, as implementações não devem modificar o conteúdo da região de Inicialização de Backup.

3.1 Sub-regiões do setor de inicialização principal e de backup

O Setor de Inicialização Principal contém código para inicialização de um volume exFAT e parâmetros de exFAT fundamentais que descrevem a estrutura de volume (consulte Tabela 4). BIOS, MBR ou outros agentes de inicialização podem inspecionar esse setor e podem carregar e executar quaisquer instruções de inicialização contidas nele.

O Setor de Inicialização de Backup é um backup do Setor de Inicialização Principal e tem a mesma estrutura (consulte Tabela 4). O Setor de Inicialização de Backup pode ajudar nas operações de recuperação; no entanto, as implementações devem tratar o conteúdo dos campos VolumeFlags e PercentInUse como obsoletos.

Antes de usar o conteúdo do Setor principal ou de inicialização de backup, as implementações devem verificar seu conteúdo validando sua respectiva Soma de Verificação de Inicialização e garantindo que todos os campos estejam dentro do intervalo de valores válido.

Embora a operação de formato inicial inicialize o conteúdo dos setores de inicialização principal e de backup, as implementações podem atualizar esses setores (e também atualizarão sua respectiva Soma de Verificação de Inicialização) conforme necessário. No entanto, as implementações podem atualizar os campos VolumeFlags ou PercentInUse sem atualizar sua respectiva Soma de Verificação de Inicialização (a soma de verificação exclui especificamente esses dois campos).

Estrutura do setor de inicialização principal e de backup da Tabela 4

Nome do Campo

Deslocamento

(byte)

Tamanho

(bytes)

 Comentários
JumpBoot 0 3 Esse campo é obrigatório e a Seção 3.1.1 define seu conteúdo.
FileSystemName 3 8 Esse campo é obrigatório e a Seção 3.1.2 define seu conteúdo.
MustBeZero 11 53 Esse campo é obrigatório e a Seção 3.1.3 define seu conteúdo.
PartitionOffset 64 8 Esse campo é obrigatório e a Seção 3.1.4 define seu conteúdo.
VolumeLength 72 8 Esse campo é obrigatório e a Seção 3.1.5 define seu conteúdo.
FatOffset 80 4 Esse campo é obrigatório e a Seção 3.1.6 define seu conteúdo.
FatLength 84 4 Esse campo é obrigatório e a Seção 3.1.7 define seu conteúdo.
ClusterHeapOffset 88 4 Esse campo é obrigatório e a Seção 3.1.8 define seu conteúdo.
ClusterCount 92 4 Esse campo é obrigatório e a Seção 3.1.9 define seu conteúdo.
FirstClusterOfRootDirectory 96 4 Esse campo é obrigatório e a Seção 3.1.10 define seu conteúdo.
VolumeSerialNumber 100 4 Esse campo é obrigatório e a Seção 3.1.11 define seu conteúdo.
FileSystemRevision 104 2 Esse campo é obrigatório e a Seção 3.1.12 define seu conteúdo.
VolumeFlags 106 2 Esse campo é obrigatório e a Seção 3.1.13 define seu conteúdo.
BytesPerSectorShift 108 1 Esse campo é obrigatório e a Seção 3.1.14 define seu conteúdo.
SectorsPerClusterShift 109 1 Esse campo é obrigatório e a Seção 3.1.15 define seu conteúdo.
NumberOfFats 110 1 Esse campo é obrigatório e a Seção 3.1.16 define seu conteúdo.
DriveSelect 111 1 Esse campo é obrigatório e a Seção 3.1.17 define seu conteúdo.
PercentInUse 112 1 Esse campo é obrigatório e a Seção 3.1.18 define seu conteúdo.
Reservado 113 7 Esse campo é obrigatório e seu conteúdo é reservado.
BootCode 120 390 Esse campo é obrigatório e a Seção 3.1.19 define seu conteúdo.
BootSignature 510 2 Esse campo é obrigatório e a Seção 3.1.20 define seu conteúdo.
ExcessSpace 512 2BytesPerSectorShift – 512

Esse campo é obrigatório e seu conteúdo, se houver, é indefinido.

Observação: os setores Principal e Inicialização de Backup contêm o campo BytesPerSectorShift.

3.1.1 Campo JumpBoot

O campo JumpBoot deve conter a instrução de salto para CPUs comuns em computadores pessoais, que, quando executadas, "pula" a CPU para executar as instruções de inicialização no campo BootCode.

O valor válido para esse campo é (na ordem de byte de baixa ordem para byte de alta ordem) EBh 76h 90h.

3.1.2 Campo FileSystemName

O campo FileSystemName deve conter o nome do sistema de arquivos no volume.

O valor válido para esse campo é, em caracteres ASCII, "EXFAT", que inclui três espaços em branco à direita.

3.1.3 Campo MustBeZero

O campo MustBeZero deve corresponder diretamente ao intervalo de bytes que o bloco de parâmetro BIOS empacotado consome em volumes FAT12/16/32.

O valor válido para esse campo é 0, o que ajuda a impedir que implementações FAT12/16/32 montem erroneamente um volume exFAT.

Campo PartitionOffset 3.1.4

O campo PartitionOffset deve descrever o deslocamento do setor relativo à mídia da partição que hospeda o volume exFAT fornecido. Esse campo auxilia na inicialização do volume usando INT estendido 13h em computadores pessoais.

Todos os valores possíveis para esse campo são válidos; no entanto, o valor 0 indica que as implementações devem ignorar esse campo.

3.1.5 Campo VolumeLength

O campo VolumeLength deve descrever o tamanho do volume exFAT determinado em setores.

O intervalo válido de valores para este campo deve ser:

  • Pelo menos 2BytesPerSectorShift de20/2, o que garante que o menor volume não seja inferior a 1 MB

  • No máximo 264-1, o maior valor que esse campo pode descrever.

    No entanto, se o tamanho da sub-região Espaço Em Excesso for 0, o maior valor desse campo será ClusterHeapOffset + (232- 11) * 2SetoresPerClusterShift.

3.1.6 Campo FatOffset

O campo FatOffset deve descrever o deslocamento do setor relativo ao volume do Primeiro FAT. Esse campo permite que as implementações alinhem o First FAT às características da mídia de armazenamento subjacente.

O intervalo válido de valores para este campo deve ser:

  • Pelo menos 24, que são responsáveis pelos setores que as regiões inicialização principal e inicialização de backup consomem

  • No máximo, ClusterHeapOffset - (FatLength * NumberOfFats), que contabiliza os setores que o Heap de Cluster consome

3.1.7 Campo FatLength

O campo FatLength deve descrever o comprimento, em setores, de cada tabela FAT (o volume pode conter até duas FATs).

O intervalo válido de valores para este campo deve ser:

  • Pelo menos (ClusterCount + 2) *2 2/ 2BytesPerSectorShiftarredondado até o inteiro mais próximo, o que garante que cada FAT tenha espaço suficiente para descrever todos os clusters no Heap de Cluster

  • No máximo (ClusterHeapOffset - FatOffset) / NumberOfFats arredondado para baixo até o inteiro mais próximo, o que garante que as FATs existam antes do Heap de Cluster

Esse campo pode conter um valor acima de seu limite inferior (conforme descrito acima) para permitir que a Segunda FAT, se presente, também seja alinhada às características da mídia de armazenamento subjacente. O conteúdo do espaço que excede o que o próprio FAT requer, se houver, é indefinido.

3.1.8 Campo ClusterHeapOffset

O campo ClusterHeapOffset deve descrever o deslocamento do setor relativo ao volume do Heap de Cluster. Esse campo permite que as implementações alinhem o Heap de Cluster às características da mídia de armazenamento subjacente.

O intervalo válido de valores para este campo deve ser:

  • Pelo menos FatOffset + FatLength * NumberOfFats, para considerar os setores que todas as regiões anteriores consomem

  • No máximo 232- 1 ou VolumeLength - (ClusterCount * 2SetoresPerClusterShift), qualquer cálculo é menor

3.1.9 Campo ClusterCount

O campo ClusterCount deve descrever o número de clusters que o Heap de Cluster contém.

O valor válido para esse campo deve ser o menor dos seguintes:

  • (VolumeLength - ClusterHeapOffset) / 2SetoresPerClusterShiftarredondado para baixo até o inteiro mais próximo, que é exatamente o número de clusters que podem caber entre o início do Heap de Cluster e o final do volume

  • 232-11, que é o número máximo de clusters que um FAT pode descrever

O valor do campo ClusterCount determina o tamanho mínimo de uma FAT. Para evitar FATs extremamente grandes, as implementações podem controlar o número de clusters no Heap de Cluster aumentando o tamanho do cluster (por meio do campo SectorsPerClusterShift). Essa especificação recomenda não mais do que 2 clusters24-2 no Heap de Cluster. No entanto, as implementações poderão lidar com volumes com até 2 clustersde 32 a 11 no Heap de Cluster.

3.1.10 FirstClusterOfRootDirectory Field

O campo FirstClusterOfRootDirectory deve conter o índice de cluster do primeiro cluster do diretório raiz. As implementações devem fazer todos os esforços para colocar o primeiro cluster do diretório raiz no primeiro cluster não inválido após os clusters que o Bitmap de Alocação e a Tabela de Casos Acima consomem.

O intervalo válido de valores para este campo deve ser:

  • Pelo menos 2, o índice do primeiro cluster no Heap de Cluster

  • No máximo ClusterCount + 1, o índice do último cluster no Heap de Cluster

Campo VolumeSerialNumber 3.1.11

O campo VolumeSerialNumber deve conter um número de série exclusivo. Isso ajuda as implementações a distinguir entre diferentes volumes exFAT. As implementações devem gerar o número de série combinando a data e a hora da formatação do volume exFAT. O mecanismo para combinar data e hora para formar um número de série é específico da implementação.

Todos os valores possíveis para esse campo são válidos.

3.1.12 Campo FileSystemRevision

O campo FileSystemRevision deve descrever os números de revisão principais e secundários das estruturas exFAT no volume especificado.

O byte de alta ordem é o número de revisão principal e o byte de baixa ordem é o número de revisão secundário. Por exemplo, se o byte de alta ordem contiver o valor 01h e se o byte de ordem baixa contiver o valor 05h, o campo FileSystemRevision descreverá o número de revisão 1,05. Da mesma forma, se o byte de alta ordem contiver o valor 0Ah e se o byte de ordem baixa contiver o valor 0Fh, o campo FileSystemRevision descreverá o número de revisão 10.15.

O intervalo válido de valores para este campo deve ser:

  • Pelo menos 0 para o byte de baixa ordem e 1 para o byte de alta ordem

  • No máximo 99 para o byte de baixa ordem e 99 para o byte de alta ordem

O número de revisão do exFAT que essa especificação descreve é 1,00. As implementações dessa especificação devem montar qualquer volume exFAT com o número de revisão principal 1 e não devem montar nenhum volume exFAT com qualquer outro número de revisão principal. As implementações devem respeitar o número de revisão secundário e não devem executar operações ou criar estruturas do sistema de arquivos não descritas na especificação correspondente do número de revisão secundária.

3.1.13 Campo VolumeFlags

O campo VolumeFlags deve conter sinalizadores que indicam o status de várias estruturas do sistema de arquivos no volume exFAT (consulte Tabela 5).

As implementações não devem incluir esse campo ao calcular sua respectiva soma de verificação da região inicialização principal ou de inicialização de backup. Ao se referir ao Setor de Inicialização de Backup, as implementações devem tratar esse campo como obsoleto.

Estrutura de campo VolumeFlags da Tabela 5

Nome do Campo

Deslocamento

(bit)

Tamanho

(bits)

 Comentários
ActiveFat 0 1 Esse campo é obrigatório e a Seção 3.1.13.1 define seu conteúdo.
VolumeDirty 1 1 Esse campo é obrigatório e a Seção 3.1.13.2 define seu conteúdo.
MediaFailure 2 1 Esse campo é obrigatório e a Seção 3.1.13.3 define seu conteúdo.
ClearToZero 3 1 Esse campo é obrigatório e a Seção 3.1.13.4 define seu conteúdo.
Reservado 4 12 Esse campo é obrigatório e seu conteúdo é reservado.
3.1.13.1 Campo ActiveFat

O campo ActiveFat deve descrever qual FAT e Bitmap de Alocação estão ativos (e as implementações devem ser usadas), da seguinte maneira:

  • 0, o que significa que o Primeiro FAT e o Primeiro Bitmap de Alocação estão ativos

  • 1, o que significa que o Bitmap segunda fat e segunda alocação estão ativos e só é possível quando o campo NumberOfFats contém o valor 2

As implementações devem considerar o FAT inativo e o Bitmap de Alocação como obsoletos. Somente implementações com reconhecimento de TexFAT devem alternar os Bitmaps ativos de FAT e Alocação (consulte a Seção 7.1).

3.1.13.2 Campo VolumeDirty

O campo VolumeDirty deve descrever se o volume é sujo ou não, da seguinte maneira:

  • 0, o que significa que o volume provavelmente está em um estado consistente

  • 1, o que significa que o volume provavelmente está em um estado inconsistente

As implementações devem definir o valor desse campo como 1 ao encontrar inconsistências de metadados do sistema de arquivos que não resolve. Se, ao montar um volume, o valor desse campo for 1, somente as implementações que resolve inconsistências de metadados do sistema de arquivos poderão limpar o valor desse campo como 0. Essas implementações só devem limpar o valor desse campo para 0 depois de garantir que o sistema de arquivos esteja em um estado consistente.

Se, ao montar um volume, o valor desse campo for 0, as implementações deverão definir esse campo como 1 antes de atualizar os metadados do sistema de arquivos e desmarcar esse campo para 0 posteriormente, semelhante à ordenação de gravação recomendada descrita na Seção 8.1.

3.1.13.3 Campo MediaFailure

O campo MediaFailure deve descrever se uma implementação descobriu falhas de mídia ou não, da seguinte maneira:

  • 0, o que significa que a mídia de hospedagem não relatou falhas ou quaisquer falhas conhecidas já estão registradas no FAT como clusters "ruins"

  • 1, o que significa que a mídia de hospedagem relatou falhas (ou seja, falhou nas operações de leitura ou gravação)

Uma implementação deve definir esse campo como 1 quando:

  1. A mídia de hospedagem falha nas tentativas de acesso a qualquer região no volume

  2. A implementação esgotou os algoritmos de repetição de acesso, se houver

Se, ao montar um volume, o valor desse campo for 1, as implementações que verificam todo o volume em busca de falhas de mídia e registram todas as falhas como clusters "inválidos" no FAT (ou de outra forma resolve falhas de mídia) podem limpar o valor desse campo como 0.

3.1.13.4 Campo ClearToZero

O campo ClearToZero não tem significado significativo nessa especificação.

Os valores válidos para este campo são:

  • 0, que não tem nenhum significado específico

  • 1, o que significa que as implementações devem limpar esse campo para 0 antes de modificar quaisquer estruturas, diretórios ou arquivos do sistema de arquivos

3.1.14 BytesPerSectorShift Field

O campo BytesPerSectorShift deve descrever os bytes por setor expressos como log2(N), em que N é o número de bytes por setor. Por exemplo, para 512 bytes por setor, o valor desse campo é 9.

O intervalo válido de valores para este campo deve ser:

  • Pelo menos 9 (tamanho do setor de 512 bytes), que é o menor setor possível para um volume exFAT

  • No máximo 12 (tamanho do setor de 4096 bytes), que é o tamanho da página de memória de CPUs comuns em computadores pessoais

3.1.15 SetoresPerClusterShift Field

O campo SectorsPerClusterShift deve descrever os setores por cluster expressos como log2(N), em que N é o número de setores por cluster. Por exemplo, para 8 setores por cluster, o valor desse campo é 3.

O intervalo válido de valores para este campo deve ser:

  • Pelo menos 0 (1 setor por cluster), que é o menor cluster possível

  • No máximo 25 – BytesPerSectorShift, que é avaliado como um tamanho de cluster de 32 MB

3.1.16 Campo NumberOfFats

O campo NumberOfFats deve descrever o número de FATs e bitmaps de alocação que o volume contém.

O intervalo válido de valores para este campo deve ser:

  • 1, que indica que o volume contém apenas o Primeiro Bitmap fat e first allocation

  • 2, que indica que o volume contém o Primeiro FAT, o Segundo FAT, o Primeiro Bitmap de Alocação e o Segundo Bitmap de Alocação; esse valor só é válido para volumes TexFAT

3.1.17 DriveSelect Field

O campo DriveSelect deve conter o número estendido da unidade INT 13h, que auxilia na inicialização desse volume usando INT 13h estendido em computadores pessoais.

Todos os valores possíveis para esse campo são válidos. Campos semelhantes em sistemas de arquivos baseados em FAT anteriores frequentemente continham o valor 80h.

3.1.18 PercentInUse Field

O campo PercentInUse deve descrever o percentual de clusters no Heap de Cluster alocado.

O intervalo válido de valores para este campo deve ser:

  • Entre 0 e 100 inclusive, que é o percentual de clusters alocados no Heap de Cluster, arredondado para baixo até o inteiro mais próximo

  • Exatamente FFh, que indica que o percentual de clusters alocados no Heap de Cluster não está disponível

As implementações devem alterar o valor desse campo para refletir as alterações na alocação de clusters no Heap de Cluster ou alterá-lo para FFh.

As implementações não devem incluir esse campo ao calcular sua respectiva soma de verificação da região inicialização principal ou de inicialização de backup. Ao se referir ao Setor de Inicialização de Backup, as implementações devem tratar esse campo como obsoleto.

Campo BootCode 3.1.19

O campo BootCode deve conter instruções de inicialização. As implementações podem preencher esse campo com as instruções de CPU necessárias para a inicialização de um sistema de computador. As implementações que não fornecem instruções de inicialização devem inicializar cada byte nesse campo para F4h (a instrução de parada para CPUs comuns em computadores pessoais) como parte de sua operação de formato.

3.1.20 BootSignature Field

O campo BootSignature deve descrever se a intenção de um determinado setor é que ele seja um Setor de Inicialização ou não.

O valor válido para esse campo é AA55h. Qualquer outro valor nesse campo invalida seu respectivo Setor de Inicialização. As implementações devem verificar o conteúdo desse campo antes de depender de qualquer outro campo em seu respectivo Setor de Inicialização.

3.2 Sub-regiões principais e de backup de setores de inicialização estendida

Cada setor dos Principais Setores de Inicialização Estendida tem a mesma estrutura; no entanto, cada setor pode conter instruções distintas de inicialização (consulte Tabela 6). Agentes de inicialização, como as instruções de inicialização no Setor de Inicialização Principal, implementações alternativas de BIOS ou firmware de um sistema inserido, podem carregar esses setores e executar as instruções que contêm.

Os Setores de Inicialização Estendida de Backup são um backup dos Principais Setores de Inicialização Estendida e têm a mesma estrutura (consulte Tabela 6).

Antes de executar as instruções dos Setores de Inicialização Estendida Principal ou Backup, as implementações devem verificar seu conteúdo garantindo que o campo ExtendedBootSignature de cada setor contenha seu valor prescrito.

Embora a operação de formato inicialize o conteúdo dos Setores de Inicialização Estendida Principal e Backup, as implementações podem atualizar esses setores (e também atualizarão sua respectiva Soma de Verificação de Inicialização) conforme necessário.

Estrutura do setor de inicialização estendida da Tabela 6

Nome do Campo

Deslocamento

(byte)

Tamanho

(bytes)

 Comentários
ExtendedBootCode 0 2BytesPerSectorShift – 4

Esse campo é obrigatório e a Seção 3.2.1 define seu conteúdo.

Observação: os setores Principal e inicialização de backup contêm o campo BytesPerSectorShift.
ExtendedBootSignature 2BytesPerSectorShift – 4 4

Esse campo é obrigatório e a Seção 3.2.2 define seu conteúdo.

Observação: os setores Principal e inicialização de backup contêm o campo BytesPerSectorShift.

3.2.1 Campo ExtendedBootCode

O campo ExtendedBootCode deve conter instruções de inicialização. As implementações podem preencher esse campo com as instruções de CPU necessárias para a inicialização de um sistema de computador. As implementações que não fornecem instruções de inicialização devem inicializar cada byte nesse campo para 00h como parte de sua operação de formato.

3.2.2 Campo ExtendedBootSignature

O campo ExtendedBootSignature deve descrever se a intenção de determinado setor é que ele seja um Setor de Inicialização Estendida ou não.

O valor válido para esse campo é AA550000h. Qualquer outro valor nesse campo invalida seu respectivo Setor de Inicialização Estendida Principal ou Backup. As implementações devem verificar o conteúdo desse campo antes de depender de qualquer outro campo em seu respectivo Setor de Inicialização Estendida.

3.3 Sub-regiões de parâmetros OEM principais e de backup

A sub-região Parâmetros OEM Principais contém dez estruturas de parâmetros que podem conter informações específicas do fabricante (consulte Tabela 7). Cada uma das dez estruturas de parâmetros deriva do modelo De parâmetros genéricos (consulte a Seção 3.3.2). Os fabricantes podem derivar suas próprias estruturas de parâmetros personalizados do modelo Parâmetros Genéricos. Essa especificação em si define duas estruturas de parâmetros: Parâmetros nulos (consulte Seção 3.3.3) e Parâmetros Flash (consulte Seção 3.3.4).

Os Parâmetros OEM de Backup são um backup dos principais parâmetros OEM e têm a mesma estrutura (consulte Tabela 7).

Antes de usar o conteúdo dos parâmetros Principal ou OEM de Backup, as implementações devem verificar seu conteúdo validando sua respectiva Soma de Verificação de Inicialização.

Os fabricantes devem preencher os Parâmetros OEM principal e de backup com suas próprias estruturas de parâmetros personalizados, se houver, e quaisquer outras estruturas de parâmetro. As operações de formato subsequentes devem preservar o conteúdo dos Parâmetros OEM principal e de backup.

As implementações podem atualizar os parâmetros Main e Backup OEM conforme necessário (e também devem atualizar sua respectiva Soma de Verificação de Inicialização).

Estrutura de parâmetros OEM da Tabela 7

Nome do Campo

Deslocamento

(byte)

Tamanho

(bytes)

 Comentários
Parâmetros[0] 0 48 Esse campo é obrigatório e a Seção 3.3.1 define seu conteúdo.

.

.

.

.

.

.

.

.

.

.

.

.
Parâmetros[9] 432 48 Esse campo é obrigatório e a Seção 3.3.1 define seu conteúdo.
Reservado 480 2BytesPerSectorShift – 480

Esse campo é obrigatório e seu conteúdo é reservado.

Observação: os setores Principal e inicialização de backup contêm o campo BytesPerSectorShift.

3.3.1 Parâmetros[0] ... Parâmetros[9]

Cada campo Parâmetros nessa matriz contém uma estrutura de parâmetros, que deriva do modelo Parâmetros Genéricos (consulte a Seção 3.3.2). Qualquer campo Parâmetros não utilizados deve ser descrito como contendo uma estrutura parâmetros nulos (consulte a Seção 3.3.3).

Modelo de parâmetros genéricos 3.3.2

O modelo Parâmetros Genéricos fornece a definição base de uma estrutura de parâmetros (consulte Tabela 8). Todas as estruturas de parâmetros derivam desse modelo. O suporte para este modelo de Parâmetros Genéricos é obrigatório.

Modelo de parâmetros genéricos da Tabela 8

Nome do Campo

Deslocamento

(byte)

Tamanho

(bytes)

 Comentários
ParametersGuid 0 16 Esse campo é obrigatório e a Seção 3.3.2.1 define seu conteúdo.
CustomDefined 16 32 Esse campo é obrigatório e as estruturas derivadas desse modelo definem seu conteúdo.
3.3.2.1 ParametersGuid Field

O campo ParametersGuid deve descrever um GUID, que determina o layout do restante da estrutura de parâmetros fornecida.

Todos os valores possíveis para esse campo são válidos; no entanto, os fabricantes devem usar uma ferramenta de geração de GUID, como GuidGen.exe, para selecionar um GUID ao derivar estruturas de parâmetros personalizados desse modelo.

3.3.3 Parâmetros nulos

A estrutura Parâmetros Nulos deriva do modelo Parâmetros Genéricos (consulte a Seção 3.3.2) e deve descrever um campo Parâmetros não utilizados (consulte Tabela 9). Ao criar ou atualizar a estrutura Parâmetros OEM, as implementações devem preencher campos parâmetros não utilizados com a estrutura Parâmetros Null. Além disso, ao criar ou atualizar a estrutura parâmetros OEM, as implementações devem consolidar estruturas de Parâmetros Nulos no final da matriz, deixando assim todas as outras estruturas de Parâmetros no início da estrutura Parâmetros OEM.

O suporte para a estrutura Parâmetros Nulos é obrigatório.

Estrutura de parâmetros nulos da Tabela 9

Nome do Campo

Deslocamento

(byte)

Tamanho

(bytes)

 Comentários
ParametersGuid 0 16 Esse campo é obrigatório e a Seção 3.3.3.1 define seu conteúdo.
Reservado 16 32 Esse campo é obrigatório e seu conteúdo é reservado.
3.3.3.1 ParametersGuid Field

O campo ParametersGuid deve estar em conformidade com a definição fornecida pelo modelo Parâmetros Genéricos (consulte a Seção 3.3.2.1).

O valor válido para esse campo, na notação GUID, é {00000000-0000-0000-0000-000000000000}.

3.3.4 Parâmetros flash

A estrutura parâmetro flash deriva do modelo Parâmetros Genéricos (consulte Seção 3.3.2) e contém parâmetros para mídia flash (consulte Tabela 10). Os fabricantes de dispositivos de armazenamento baseados em flash podem preencher um campo Parâmetros (preferencialmente o campo Parâmetros[0] com essa estrutura de parâmetros. As implementações podem usar as informações na estrutura Parâmetros flash para otimizar as operações de acesso durante leituras/gravações e para alinhamento das estruturas do sistema de arquivos que duram a formatação da mídia.

O suporte para a estrutura parâmetros flash é opcional.

Estrutura de parâmetros flash da Tabela 10

Nome do Campo

Deslocamento

(byte)

Tamanho

(bytes)

 Comentários
ParametersGuid 0 16 Esse campo é obrigatório e a Seção 3.3.4.1 define seu conteúdo.
EraseBlockSize 16 4 Esse campo é obrigatório e a Seção 3.3.4.2 define seu conteúdo.
PageSize 20 4 Esse campo é obrigatório e a Seção 3.3.4.3 define seu conteúdo.
SpareSectors 24 4 Esse campo é obrigatório e a Seção 3.3.4.4 define seu conteúdo.
RandomAccessTime 28 4 Esse campo é obrigatório e a Seção 3.3.4.5 define seu conteúdo.
ProgrammingTime 32 4 Esse campo é obrigatório e a Seção 3.3.4.6 define seu conteúdo.
ReadCycle 36 4 Esse campo é obrigatório e a Seção 3.3.4.7 define seu conteúdo.
WriteCycle 40 4 Esse campo é obrigatório e a Seção 3.3.4.8 define seu conteúdo.
Reservado 44 4 Esse campo é obrigatório e seu conteúdo é reservado.

Todos os valores possíveis para todos os campos parâmetros flash, exceto para o campo ParametersGuid, são válidos. No entanto, o valor 0 indica que o campo não tem sentido (as implementações devem ignorar o campo fornecido).

3.3.4.1 ParametersGuid Field

O campo ParametersGuid deve estar em conformidade com a definição fornecida no modelo Parâmetros Genéricos (consulte a Seção 3.3.2.1).

O valor válido para esse campo, na notação GUID, é {0A0C7E46-3399-4021-90C8-FA6D389C4BA2}.

3.3.4.2 EraseBlockSize Field

O campo EraseBlockSize deve descrever o tamanho, em bytes, do bloco de apagamento da mídia flash.

3.3.4.3 PageSize Field

O campo PageSize deve descrever o tamanho, em bytes da página da mídia flash.

3.3.4.4 Campo SpareSectors

O campo SpareSectors deve descrever o número de setores que a mídia flash tem disponíveis para suas operações de moderação internas.

3.3.4.5 Campo RandomAccessTime

O campo RandomAccessTime deve descrever o tempo médio de acesso aleatório da mídia flash, em nanossegundos.

Campo ProgrammingTime 3.3.4.6

O campo ProgrammingTime deve descrever o tempo médio de programação da mídia flash, em nanossegundos.

3.3.4.7 Campo ReadCycle

O campo ReadCycle deve descrever o tempo médio do ciclo de leitura da mídia flash, em nanossegundos.

Campo WriteCycle 3.3.4.8

O campo WriteCycle deve descrever o tempo médio do ciclo de gravação, em nanossegundos.

3.4 Sub-regiões principais e de soma de verificação de inicialização de backup

As somas de verificação de inicialização principal e de backup contêm um padrão repetido da soma de verificação de quatro bytes do conteúdo de todas as outras sub-regiões em suas respectivas regiões de inicialização. O cálculo da soma de verificação não deve incluir os campos VolumeFlags e PercentInUse em seu respectivo Setor de Inicialização (consulte a Figura 1). O padrão de repetição da soma de verificação de quatro bytes preenche sua respectiva sub-região de Soma de Verificação de Inicialização do início ao final da sub-região.

Antes de usar o conteúdo de qualquer uma das outras sub-regiões nas regiões Principal ou Inicialização de Backup, as implementações devem verificar seu conteúdo validando sua respectiva Soma de Verificação de Inicialização.

Embora a operação de formato inicial preencha as somas de verificação de inicialização principal e de backup com o padrão de soma de verificação recorrente, as implementações devem atualizar esses setores à medida que o conteúdo dos outros setores em suas respectivas regiões de inicialização mudar.

Figura 1 Computação de Soma de Verificação de Inicialização

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 Região da Tabela de Alocação de Arquivos

A região fat (tabela de alocação de arquivo) pode conter até duas FATs, uma na primeira sub-região FAT e outra na segunda sub-região FAT. O campo NumberOfFats descreve quantas FATs essa região contém. Os valores válidos para o campo NumberOfFats são 1 e 2. Portanto, a primeira sub-região FAT sempre contém um FAT. Se o campo NumberOfFats for dois, a segunda sub-região FAT também conterá um FAT.

O campo ActiveFat do campo VolumeFlags descreve qual FAT está ativo. Somente o campo VolumeFlags no Setor de Inicialização Principal é atual. As implementações devem tratar o FAT que não está ativo como obsoleto. O uso do FAT inativo e a alternância entre FATs são específicos da implementação.

4.1 Primeira e Segunda Sub-regiões FAT

Um FAT deve descrever as cadeias de cluster no Heap de Cluster (consulte a Tabela 11). Uma cadeia de clusters é uma série de clusters que fornece espaço para registrar o conteúdo de arquivos, diretórios e outras estruturas do sistema de arquivos. Um FAT representa uma cadeia de clusters como uma lista vinculada de índices de cluster. Com exceção das duas primeiras entradas, cada entrada em um FAT representa exatamente um cluster.

Estrutura da tabela de alocação de arquivo da tabela 11

Nome do Campo

Deslocamento

(byte)

Tamanho

(bytes)

 Comentários
FatEntry[0] 0 4 Esse campo é obrigatório e a Seção 4.1.1 define seu conteúdo.
FatEntry[1] 4 4 Esse campo é obrigatório e a Seção 4.1.2 define seu conteúdo.
FatEntry[2] 8 4 Esse campo é obrigatório e a Seção 4.1.3 define seu conteúdo.

.

.

.

.

.

.

.

.

.

.

.

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

Esse campo é obrigatório e a Seção 4.1.3 define seu conteúdo.

ClusterCount + 1 nunca pode exceder FFFFFFF6h.

Observação: os setores Principal e Inicialização de Backup contêm o campo ClusterCount.
ExcessSpace (ClusterCount + 2) * 4 (FatLength * 2BytesPerSectorShift) – ((ClusterCount + 2) * 4)

Esse campo é obrigatório e seu conteúdo, se houver, é indefinido.

Observação: os setores inicialização principal e de backup contêm os campos ClusterCount, FatLength e BytesPerSectorShift.

4.1.1 FatEntry[0] Campo

O campo FatEntry[0] deve descrever o tipo de mídia no primeiro byte (o byte de ordem mais baixo) e deve conter FFh nos três bytes restantes.

O tipo de mídia (o primeiro byte) deve ser F8h.

4.1.2 FatEntry[1] Campo

O campo FatEntry[1] existe apenas devido à precedência histórica e não descreve nada de interesse.

O valor válido para esse campo é FFFFFFFFh. As implementações devem inicializar esse campo com seu valor prescrito e não devem usar esse campo para nenhuma finalidade. As implementações não devem interpretar esse campo e devem preservar seu conteúdo entre operações que modificam campos ao redor.

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

Cada campo FatEntry nessa matriz deve representar um cluster no Heap de Cluster. FatEntry[2] representa o primeiro cluster no Heap de Cluster e FatEntry[ClusterCount+1] representa o último cluster no Heap de Cluster.

O intervalo válido de valores para esses campos deve ser:

  • Entre 2 e ClusterCount + 1, inclusive, que aponta para a próxima FatEntry na cadeia de cluster fornecida; o FatEntry determinado não deve apontar para qualquer FatEntry que o precede na cadeia de cluster fornecida

  • Exatamente FFFFFFF7h, que marca o cluster correspondente do FatEntry como "ruim"

  • Exatamente FFFFFFFFh, que marca o cluster correspondente do FatEntry como o último cluster de uma cadeia de clusters; esse é o único valor válido para o último FatEntry de qualquer cadeia de cluster fornecida

5 Região de Dados

A região Dados contém o Heap de Cluster, que fornece espaço gerenciado para estruturas, diretórios e arquivos do sistema de arquivos.

5.1 Sub-região do Heap de Cluster

A estrutura do Heap de Cluster é muito simples (consulte Tabela 12); cada série consecutiva de setores descreve um cluster, como define o campo SectorsPerClusterShift. É importante ressaltar que o primeiro cluster do Heap de Cluster tem o índice dois, que corresponde diretamente ao índice de FatEntry[2].

Em um volume exFAT, um Bitmap de Alocação (consulte a Seção 7.1.5) mantém o registro do estado de alocação de todos os clusters. Essa é uma diferença significativa em relação aos predecessores do exFAT (FAT12, FAT16 e FAT32), nos quais um FAT manteve um registro do estado de alocação de todos os clusters no Heap de Cluster.

Estrutura de heap de cluster da Tabela 12

Nome do Campo

Deslocamento

(setor)

Tamanho

(setores)

 Comentários
Cluster[2] ClusterHeapOffset 2setoresPerClusterShift

Esse campo é obrigatório e a Seção 5.1.1 define seu conteúdo.

Observação: os setores inicialização principal e de backup contêm os campos ClusterHeapOffset e SectorsPerClusterShift.

.

.

.

.

.

.

.

.

.

.

.

.
Cluster[ClusterCount+1] ClusterHeapOffset + (ClusterCount – 1) * 2SetoresPerClusterShift 2setoresPerClusterShift

Esse campo é obrigatório e a Seção 5.1.1 define seu conteúdo.

Observação: os setores inicialização principal e de backup contêm os campos ClusterCount, ClusterHeapOffset e SectorsPerClusterShift.

5.1.1 Cluster[2] ... Cluster[ClusterCount+1] Campos

Cada campo Cluster nessa matriz é uma série de setores contíguos, cujo tamanho é definido pelo campo SectorsPerClusterShift.

6 Estrutura de Diretório

O sistema de arquivos exFAT usa uma abordagem de árvore de diretório para gerenciar as estruturas e arquivos do sistema de arquivos que existem no Heap de Cluster. Os diretórios têm uma relação um-para-muitos entre pai e filho na árvore de diretórios.

O diretório ao qual o campo FirstClusterOfRootDirectory se refere é a raiz da árvore de diretório. Todos os outros diretórios são descendentes do diretório raiz de maneira vinculada.

Cada diretório consiste em uma série de entradas de diretório (consulte a Tabela 13).

Uma ou mais entradas de diretório são combinadas em um conjunto de entradas de diretório que descreve algo de interesse, como uma estrutura do sistema de arquivos, subdiretório ou arquivo.

Estrutura do Diretório da Tabela 13

Nome do Campo

Deslocamento

(byte)

Tamanho

(byte)

 Comentários
DirectoryEntry[0] 0 32 Esse campo é obrigatório e a Seção 6.1 define seu conteúdo.

.

.

.

.

.

.

.

.

.

.

.

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

Esse campo é obrigatório e a Seção 6.1 define seu conteúdo.

N, o número de campos DirectoryEntry, é o tamanho, em bytes, da cadeia de clusters que contém o diretório especificado, dividido pelo tamanho de um campo DirectoryEntry, 32 bytes.

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

Cada campo DirectoryEntry nessa matriz deriva do modelo Generic DirectoryEntry (consulte a Seção 6.2).

6.2 Modelo de DirectoryEntry Genérico

O modelo Generic DirectoryEntry fornece a definição base para entradas de diretório (consulte a Tabela 14). Todas as estruturas de entrada de diretório derivam desse modelo e apenas as estruturas de entrada de diretório definidas pela Microsoft são válidas (o exFAT não tem provisionamentos para estruturas de entrada de diretório definidas pelo fabricante, exceto conforme definido na Seção 7.8 e na Seção 7.9). A capacidade de interpretar o modelo Generic DirectoryEntry é obrigatória.

Tabela 14 Generic DirectoryEntry Template

Nome do Campo

Deslocamento

(byte)

Tamanho

(byte)

 Comentários
Entrytype 0 1 Esse campo é obrigatório e a Seção 6.2.1 define seu conteúdo.
CustomDefined 1 19 Esse campo é obrigatório e as estruturas derivadas desse modelo podem definir seu conteúdo.
FirstCluster 20 4 Esse campo é obrigatório e a Seção 6.2.2 define seu conteúdo.
Datalength 24 8 Esse campo é obrigatório e a Seção 6.2.3 define seu conteúdo.

Campo EntryType 6.2.1

O campo EntryType tem três modos de uso definidos pelo valor do campo (veja a lista abaixo).

  • 00h, que é um marcador de fim de diretório e as seguintes condições se aplicam:

    • Todos os outros campos no DirectoryEntry especificado são realmente reservados

    • Todas as entradas de diretório subsequentes no diretório especificado também são marcadores de fim de diretório

    • Os marcadores de fim de diretório são válidos apenas fora dos conjuntos de entradas de diretório

    • As implementações podem substituir marcadores de fim de diretório conforme necessário

  • Entre 01h e 7Fh inclusive, que é um marcador de entrada de diretório não utilizado e as seguintes condições se aplicam:

    • Todos os outros campos no DirectoryEntry especificado são, na verdade, indefinidos

    • Entradas de diretório não utilizados são válidas apenas fora dos conjuntos de entradas de diretório

    • As implementações podem substituir entradas de diretório não usadas conforme necessário

    • Esse intervalo de valores corresponde ao campo InUse (consulte Seção 6.2.1.4) que contém o valor 0

  • Entre 81h e FFh, inclusive, que é uma entrada de diretório regular e as seguintes condições se aplicam:

    • O conteúdo do campo EntryType (consulte Tabela 15) determina o layout do restante da estrutura DirectoryEntry

    • Esse intervalo de valores e somente esse intervalo de valores são válidos dentro de um conjunto de entradas de diretório

    • Esse intervalo de valores corresponde diretamente ao campo InUse (consulte a Seção 6.2.1.4) que contém o valor 1

Para evitar modificações no campo InUse (consulte a Seção 6.2.1.4) erroneamente, resultando em um marcador de fim de diretório, o valor 80h é inválido.

Estrutura de campo EntryType genérica da tabela 15

Nome do Campo

Deslocamento

(bit)

Tamanho

(bits)

 Comentários
TypeCode 0 5 Esse campo é obrigatório e a Seção 6.2.1.1 define seu conteúdo.
TypeImportance 5 1 Esse campo é obrigatório e a Seção 6.2.1.2 define seu conteúdo.
TypeCategory 6 1 Esse campo é obrigatório e a Seção 6.2.1.3 define seu conteúdo.
InUse 7 1 Esse campo é obrigatório e a Seção 6.2.1.4 define seu conteúdo.
Campo TypeCode 6.2.1.1

O campo TypeCode descreve parcialmente o tipo específico da entrada de diretório fornecida. Esse campo, mais os campos TypeImportance e TypeCategory (consulte Seção 6.2.1.2 e Seção 6.2.1.3, respectivamente) identificam exclusivamente o tipo da entrada de diretório fornecida.

Todos os valores possíveis desse campo são válidos, a menos que os campos TypeImportance e TypeCategory contenham o valor 0; nesse caso, o valor 0 é inválido para esse campo.

6.2.1.2 TypeImportance Field

O campo TypeImportance deve descrever a importância da entrada de diretório fornecida.

Os valores válidos para este campo devem ser:

  • 0, o que significa que a entrada de diretório fornecida é crítica (consulte Seção 6.3.1.2.1 e Seção 6.4.1.2.1 para entradas críticas de diretório secundário primário e crítico, respectivamente)

  • 1, o que significa que a entrada de diretório fornecida é benigna (consulte Seção 6.3.1.2.2 e Seção 6.4.1.2.2 para entradas benignas de diretório secundário primário e benigno, respectivamente)

6.2.1.3 TypeCategory Field

O campo TypeCategory deve descrever a categoria da entrada de diretório fornecida.

Os valores válidos para este campo devem ser:

  • 0, o que significa que a entrada de diretório fornecida é primária (consulte a Seção 6.3)

  • 1, o que significa que a entrada de diretório fornecida é secundária (consulte a Seção 6.4)

6.2.1.4 InUse Field

O campo InUse deve descrever se a entrada de diretório fornecida em uso ou não.

Os valores válidos para este campo devem ser:

  • 0, o que significa que a entrada de diretório fornecida não está em uso; isso significa que a estrutura fornecida é, na verdade, uma entrada de diretório não utilizado

  • 1, o que significa que a entrada de diretório fornecida está em uso; isso significa que a estrutura fornecida é uma entrada de diretório regular

Campo FirstCluster 6.2.2

O campo FirstCluster deve conter o índice do primeiro cluster de uma alocação no Heap de Cluster associado à entrada de diretório fornecida.

O intervalo válido de valores para este campo deve ser:

  • Exatamente 0, o que significa que nenhuma alocação de cluster existe

  • Entre 2 e ClusterCount + 1, que é o intervalo de índices de cluster válidos

Estruturas derivadas desse modelo podem redefinir os campos FirstCluster e DataLength, se uma alocação de cluster não for compatível com a estrutura derivada.

6.2.3 Campo DataLength

O campo DataLength descreve o tamanho, em bytes, dos dados que a alocação de cluster associada contém.

O intervalo de valor válido para este campo é:

  • Pelo menos 0; se o campo FirstCluster contiver o valor 0, o único valor válido desse campo será 0

  • No máximo ClusterCount * 2SetoresPerClusterShift* 2BytesPerSectorShift

Estruturas derivadas desse modelo podem redefinir os campos FirstCluster e DataLength, se uma alocação de cluster não for possível para a estrutura derivada.

6.3 Modelo de Diretório Primário Genérico

A primeira entrada de diretório em um conjunto de entradas de diretório deve ser uma entrada de diretório primário. Todas as entradas de diretório subsequentes, se houver, no conjunto de entradas de diretório devem ser entradas de diretório secundário (consulte a Seção 6.4).

A capacidade de interpretar o modelo Generic Primary DirectoryEntry é obrigatória.

Todas as estruturas de entrada de diretório primário derivam do modelo Generic Primary DirectoryEntry (consulte Tabela 16), que deriva do modelo Generic DirectoryEntry (consulte Seção 6.2).

Modelo de Diretório Primário Genérico da Tabela 16

Nome do Campo

Deslocamento

(byte)

Tamanho

(byte)

 Comentários
Entrytype 0 1 Esse campo é obrigatório e a Seção 6.3.1 define seu conteúdo.
SecondaryCount 1 1 Esse campo é obrigatório e a Seção 6.3.2 define seu conteúdo.
SetChecksum 2 2 Esse campo é obrigatório e a Seção 6.3.3 define seu conteúdo.
GeneralPrimaryFlags 4 2 Esse campo é obrigatório e a Seção 6.3.4 define seu conteúdo.
CustomDefined 6 14 Esse campo é obrigatório e as estruturas derivadas desse modelo definem seu conteúdo.
FirstCluster 20 4 Esse campo é obrigatório e a Seção 6.3.5 define seu conteúdo.
Datalength 24 8 Esse campo é obrigatório e a Seção 6.3.6 define seu conteúdo.

Campo EntryType 6.3.1

O campo EntryType deve estar em conformidade com a definição fornecida no modelo Generic DirectoryEntry (consulte Seção 6.2.1).

Campo TypeCode 6.3.1.1

O campo TypeCode deve estar em conformidade com a definição fornecida no modelo Generic DirectoryEntry (consulte Seção 6.2.1.1).

6.3.1.2 TypeImportance Field

O campo TypeImportance deve estar em conformidade com a definição fornecida no modelo Generic DirectoryEntry (consulte Seção 6.2.1.2).

6.3.1.2.1 Entradas críticas de diretório primário

As entradas críticas do diretório primário contêm informações que são essenciais para o gerenciamento adequado de um volume exFAT. Somente o diretório raiz contém entradas críticas de diretório primário (entradas de diretório de arquivo são uma exceção, consulte Seção 7.4).

A definição de entradas críticas do diretório primário se correlaciona ao número de revisão do exFAT principal. As implementações devem dar suporte a todas as entradas críticas do diretório primário e devem registrar apenas as estruturas críticas de entrada de diretório primário que essa especificação define.

6.3.1.2.2 Entradas benignas de diretório primário

As entradas de diretório primário benigno contêm informações adicionais que podem ser úteis para gerenciar um volume exFAT. Qualquer diretório pode conter entradas benignas de diretório primário.

A definição de entradas benignas do diretório primário se correlaciona ao número de revisão do exFAT secundário. O suporte para qualquer entrada de diretório primário benigno que essa especificação, ou qualquer especificação subsequente, define é opcional. Uma entrada de diretório primário benigno não reconhecida renderiza todo o conjunto de entradas de diretório como não reconhecido (além da definição dos modelos de entrada de diretório aplicáveis).

6.3.1.3 TypeCategory Field

O campo TypeCategory deve estar em conformidade com a definição fornecida no modelo Generic DirectoryEntry (consulte Seção 6.2.1.3).

Para este modelo, o valor válido para este campo será 0.

6.3.1.4 InUse Field

O campo InUse deve estar em conformidade com a definição fornecida no modelo Generic DirectoryEntry (consulte Seção 6.2.1.4).

6.3.2 Campo SecondaryCount

O campo SecondaryCount deve descrever o número de entradas de diretório secundário que seguem imediatamente a entrada de diretório primário fornecida. Essas entradas de diretório secundário, juntamente com a entrada de diretório primário fornecida, compõem o conjunto de entradas de diretório.

O intervalo válido de valores para este campo deve ser:

  • Pelo menos 0, o que significa que essa entrada de diretório primário é a única entrada no conjunto de entradas de diretório

  • No máximo 255, o que significa que as próximas 255 entradas de diretório e essa entrada de diretório primário compõem o conjunto de entradas de diretório

Estruturas críticas de entrada de diretório primário derivadas desse modelo podem redefinir os campos SecondaryCount e SetChecksum.

6.3.3 Campo SetChecksum

O campo SetChecksum deve conter a soma de verificação de todas as entradas de diretório no conjunto de entradas de diretório especificado. No entanto, a soma de verificação exclui esse campo (consulte Figura 2). As implementações devem verificar se o conteúdo desse campo é válido antes de usar qualquer outra entrada de diretório no conjunto de entradas de diretório especificado.

Estruturas críticas de entrada de diretório primário derivadas desse modelo podem redefinir os campos SecondaryCount e 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 GeneralPrimaryFlags

O campo GeneralPrimaryFlags contém sinalizadores (consulte Tabela 17).

Estruturas críticas de entrada de diretório primário derivadas desse modelo podem redefinir esse campo.

Estrutura de campo GeneralPrimaryFlags genérica da Tabela 17

Nome do Campo

Deslocamento

(bit)

Tamanho

(bits)

 Comentários
AllocationPossible 0 1 Esse campo é obrigatório e a Seção 6.3.4.1 define seu conteúdo.
NoFatChain 1 1 Esse campo é obrigatório e a Seção 6.3.4.2 define seu conteúdo.
CustomDefined 2 14 Esse campo é obrigatório e as estruturas derivadas desse modelo podem definir esse campo.
6.3.4.1 Campo AllocationPossible

O campo AllocationPossible deve descrever se uma alocação no Heap de Cluster é possível ou não para a entrada de diretório fornecida.

Os valores válidos para este campo devem ser:

  • 0, o que significa que uma alocação associada de clusters não é possível e os campos FirstCluster e DataLength são realmente indefinidos (estruturas derivadas desse modelo podem redefinir esses campos)

  • 1, o que significa que uma alocação associada de clusters é possível e os campos FirstCluster e DataLength são definidos

6.3.4.2 Campo NoFatChain

O campo NoFatChain deve indicar se o FAT ativo descreve ou não a cadeia de cluster da alocação fornecida.

Os valores válidos para este campo devem ser:

  • 0, o que significa que as entradas FAT correspondentes para a cadeia de cluster da alocação são válidas e as implementações devem interpretá-las; se o campo AllocationPossible contiver o valor 0 ou se o campo AllocationPossible contiver o valor 1 e o campo FirstCluster contiver o valor 0, o único valor válido desse campo será 0

  • 1, o que significa que a alocação associada é uma série contígua de clusters; as entradas FAT correspondentes para os clusters são inválidas e as implementações não devem interpretá-las; as implementações podem usar a seguinte equação para calcular o tamanho da alocação associada: DataLength/ (2SetoresPerClusterShift* 2BytesPerSectorShift) arredondado para o inteiro mais próximo

Se as estruturas críticas de entrada de diretório primário derivadas desse modelo redefinirem o campo GeneralPrimaryFlags, as entradas FAT correspondentes para a cadeia de cluster de qualquer alocação associada serão válidas.

Campo FirstCluster 6.3.5

O campo FirstCluster deve estar em conformidade com a definição fornecida no modelo Generic DirectoryEntry (consulte Seção 6.2.2).

Se o bit NoFatChain for 1, o FirstCluster deverá apontar para um cluster válido no heap de cluster.

Estruturas críticas de entrada de diretório primário derivadas desse modelo podem redefinir os campos FirstCluster e DataLength. Outras estruturas derivadas desse modelo podem redefinir os campos FirstCluster e DataLength somente se o campo AllocationPossible contiver o valor 0.

6.3.6 Campo DataLength

O campo DataLength deve estar em conformidade com a definição fornecida no modelo Generic DirectoryEntry (consulte a Seção 6.2.3).

Se o bit NoFatChain for 1, o DataLength não deverá ser zero. Se o campo FirstCluster for zero, DataLength também deverá ser zero.

Estruturas críticas de entrada de diretório primário derivadas desse modelo podem redefinir os campos FirstCluster e DataLength. Outras estruturas derivadas desse modelo podem redefinir os campos FirstCluster e DataLength somente se o campo AllocationPossible contiver o valor 0.

6.4 Generic Secondary DirectoryEntry Template

A finalidade central das entradas de diretório secundário é fornecer informações adicionais sobre um conjunto de entradas de diretório. A capacidade de interpretar o modelo Generic Secondary DirectoryEntry é obrigatória.

A definição de entradas de diretório secundário críticas e benignas correlaciona-se ao número de revisão do exFAT secundário. O suporte para qualquer entrada de diretório secundário crítica ou benigna que essa especificação, ou especificações subsequentes, define é opcional.

Todas as estruturas de entrada de diretório secundário derivam do modelo Generic Secondary DirectoryEntry (consulte Tabela 18), que deriva do modelo Generic DirectoryEntry (consulte Seção 6.2).

Tabela 18 Generic Secondary DirectoryEntry Template

Nome do Campo

Deslocamento

(byte)

Tamanho

(byte)

 Comentários
Entrytype 0 1 Esse campo é obrigatório e a Seção 6.4.1 define seu conteúdo.
GeneralSecondaryFlags 1 1 Esse campo é obrigatório e a Seção 6.4.2 define seu conteúdo.
CustomDefined 2 18 Esse campo é obrigatório e as estruturas derivadas desse modelo definem seu conteúdo.
FirstCluster 20 4 Esse campo é obrigatório e a Seção 6.4.3 define seu conteúdo.
Datalength 24 8 Esse campo é obrigatório e a Seção 6.4.4 define seu conteúdo.

Campo EntryType 6.4.1

O campo EntryType deve estar em conformidade com a definição fornecida no modelo Generic DirectoryEntry (consulte Seção 6.2.1)

Campo TypeCode 6.4.1.1

O campo TypeCode deve estar em conformidade com a definição fornecida no modelo Generic DirectoryEntry (consulte Seção 6.2.1.1).

6.4.1.2 TypeImportance Field

O campo TypeImportance deve estar em conformidade com a definição fornecida no modelo Generic DirectoryEntry (consulte Seção 6.2.1.2).

6.4.1.2.1 Entradas críticas de diretório secundário

As entradas críticas do diretório secundário contêm informações que são essenciais para o gerenciamento adequado de seu conjunto de entradas de diretório que contém. Embora o suporte para qualquer entrada de diretório secundário crítica específica seja opcional, uma entrada de diretório crítico não reconhecida renderiza todo o conjunto de entradas de diretório como não reconhecido (além da definição dos modelos de entrada de diretório aplicáveis).

No entanto, se um conjunto de entradas de diretório contiver pelo menos uma entrada de diretório secundário crítica que uma implementação não reconhece, a implementação deverá, no máximo, interpretar os modelos das entradas de diretório no conjunto de entradas de diretório e não os dados que qualquer alocação associada a qualquer entrada de diretório no conjunto de entradas de diretório contém (entradas de diretório de arquivo são uma exceção, consulte a Seção 7.4).

6.4.1.2.2 Entradas benignas do diretório secundário

Entradas benignas de diretório secundário contêm informações adicionais que podem ser úteis para gerenciar o conjunto de entradas de diretório que o contém. O suporte para qualquer entrada de diretório secundário benigno específica é opcional. As entradas de diretório secundário benigno não reconhecidas não renderizam todo o conjunto de entradas de diretório como não reconhecido.

As implementações podem ignorar qualquer entrada secundária benigna que ela não reconhece.

6.4.1.3 Campo TypeCategory

O campo TypeCategory deve estar em conformidade com a definição fornecida no modelo Generic DirectoryEntry (consulte a Seção 6.2.1.3).

Para este modelo, o valor válido para esse campo é 1.

6.4.1.4 InUse Field

O campo InUse deve estar em conformidade com a definição fornecida no modelo Generic DirectoryEntry (consulte a Seção 6.2.1.4).

6.4.2 GeneralSecondaryFlags Field

O campo GeneralSecondaryFlags contém sinalizadores (consulte Tabela 19).

Tabela 19 GeneralSecondaryFlags Estrutura de Campo

Nome do Campo

Deslocamento

(bit)

Tamanho

(bits)

 Comentários
AllocationPossible 0 1 Esse campo é obrigatório e a Seção 6.4.2.1 define seu conteúdo.
NoFatChain 1 1 Esse campo é obrigatório e a Seção 6.4.2.2 define seu conteúdo.
CustomDefined 2 6 Esse campo é obrigatório e as estruturas derivadas desse modelo podem definir esse campo.
6.4.2.1 Campo AllocationPossible

O campo AllocationPossible deve ter a mesma definição que o campo de mesmo nome no modelo Generic Primary DirectoryEntry (consulte a Seção 6.3.4.1).

6.4.2.2 Campo NoFatChain

O campo NoFatChain deve ter a mesma definição que o campo de mesmo nome no modelo Generic Primary DirectoryEntry (consulte a Seção 6.3.4.2).

Campo FirstCluster 6.4.3

O campo FirstCluster deve estar em conformidade com a definição fornecida no modelo Generic DirectoryEntry (consulte a Seção 6.2.2).

Se o bit NoFatChain for 1, o FirstCluster deverá apontar para um cluster válido no heap de cluster.

6.4.4 Campo DataLength

O campo DataLength deve estar em conformidade com a definição fornecida no modelo Generic DirectoryEntry (consulte a Seção 6.2.3).

Se o bit NoFatChain for 1, o DataLength não deverá ser zero. Se o campo FirstCluster for zero, DataLength também deverá ser zero.

7 Definições de entrada de diretório

A revisão 1.00 do sistema de arquivos exFAT define as seguintes entradas de diretório:

7.1 Entrada de diretório de bitmap de alocação

No sistema de arquivos exFAT, um FAT não descreve o estado de alocação de clusters; em vez disso, um Bitmap de Alocação faz. Bitmaps de alocação existem no Heap de Cluster (consulte a Seção 7.1.5) e têm entradas de diretório primário críticas correspondentes no diretório raiz (consulte Tabela 20).

O campo NumberOfFats determina o número de entradas de diretório bitmap de alocação válidas no diretório raiz. Se o campo NumberOfFats contiver o valor 1, o único número válido de entradas de diretório bitmap de alocação será 1. Além disso, a entrada de diretório bitmap de alocação só será válida se descrever o Primeiro Bitmap de Alocação (consulte a Seção 7.1.2.1). Se o campo NumberOfFats contiver o valor 2, o único número válido de entradas de diretório bitmap de alocação será 2. Além disso, as duas entradas de diretório bitmap de alocação só serão válidas se uma descrever o Primeiro Bitmap de Alocação e a outra descrever o Segundo Bitmap de Alocação.

Tabela 20 Diretório de Bitmap de AlocaçãoEstrutura de Credenciais

Nome do Campo

Deslocamento

(byte)

Tamanho

(byte)

 Comentários
Entrytype 0 1 Esse campo é obrigatório e a Seção 7.1.1 define seu conteúdo.
BitmapFlags 1 1 Esse campo é obrigatório e a Seção 7.1.2 define seu conteúdo.
Reservado 2 18 Esse campo é obrigatório e seu conteúdo é reservado.
FirstCluster 20 4 Esse campo é obrigatório e a Seção 7.1.3 define seu conteúdo.
Datalength 24 8 Esse campo é obrigatório e a Seção 7.1.4 define seu conteúdo.

Campo EntryType 7.1.1

O campo EntryType deve estar em conformidade com a definição fornecida no modelo Generic Primary DirectoryEntry (consulte a Seção 6.3.1).

Campo TypeCode 7.1.1.1

O campo TypeCode deve estar em conformidade com a definição fornecida no modelo Generic Primary DirectoryEntry (consulte a Seção 6.3.1.1).

Para uma entrada de diretório bitmap de alocação, o valor válido para esse campo é 1.

7.1.1.2 TypeImportance Field

O campo TypeImportance deve estar em conformidade com a definição fornecida no modelo Generic Primary DirectoryEntry (consulte Seção 6.3.1.2).

Para uma entrada de diretório bitmap de alocação, o valor válido para esse campo é 0.

7.1.1.3 TypeCategory Field

O campo TypeCategory deve estar em conformidade com a definição fornecida no modelo Generic Primary DirectoryEntry (consulte Seção 6.3.1.3).

7.1.1.4 InUse Field

O campo InUse deve estar em conformidade com a definição fornecida no modelo Generic Primary DirectoryEntry (consulte Seção 6.3.1.4).

Campo BitmapFlags 7.1.2

O campo BitmapFlags contém sinalizadores (consulte Tabela 21).

Estrutura de campo BitmapFlags da Tabela 21

Nome do Campo

Deslocamento

(bit)

Tamanho

(bits)

 Comentários
BitmapIdentifier 0 1 Esse campo é obrigatório e a Seção 7.1.2.1 define seu conteúdo.
Reservado 1 7 Esse campo é obrigatório e seu conteúdo é reservado.
7.1.2.1 Campo BitmapIdentifier

O campo BitmapIdentifier deve indicar qual Bitmap de Alocação a entrada de diretório especificada descreve. As implementações devem usar o Primeiro Bitmap de Alocação em conjunto com o Primeiro FAT e devem usar o Bitmap de Segunda Alocação em conjunto com o Segundo FAT. O campo ActiveFat descreve qual FAT e Bitmap de Alocação estão ativos.

Os valores válidos para este campo devem ser:

  • 0, o que significa que a entrada de diretório fornecida descreve o Primeiro Bitmap de Alocação

  • 1, o que significa que a entrada de diretório fornecida descreve o Bitmap de Segunda Alocação e é possível somente quando NumberOfFats contém o valor 2

Campo FirstCluster 7.1.3

O campo FirstCluster deve estar em conformidade com a definição fornecida no modelo Generic Primary DirectoryEntry (consulte Seção 6.3.5).

Esse campo contém o índice do primeiro cluster da cadeia de cluster, como descreve o FAT, que hospeda o Bitmap de Alocação.

7.1.4 Campo DataLength

O campo DataCluster deve estar em conformidade com a definição fornecida no modelo Generic Primary DirectoryEntry (consulte Seção 6.3.6).

7.1.5 Bitmap de alocação

Um Bitmap de Alocação registra o estado de alocação dos clusters no Heap de Cluster. Cada bit em um Bitmap de Alocação indica se o cluster correspondente está disponível para alocação ou não.

Um Bitmap de Alocação representa clusters do índice mais baixo para o mais alto (consulte Tabela 22). Por motivos históricos, o primeiro cluster tem o índice 2. Observação: o primeiro bit no bitmap é o bit de ordem mais baixa do primeiro byte.

Estrutura de bitmap de alocação da Tabela 22

Nome do Campo

Deslocamento

(bit)

Tamanho

(bits)

 Comentários
BitmapEntry[2] 0 1 Esse campo é obrigatório e a Seção 7.1.5.1 define seu conteúdo.

.

.

.

.

.

.

.

.

.

.

.

.
BitmapEntry[ClusterCount+1] ClusterCount - 1 1

Esse campo é obrigatório e a Seção 7.1.5.1 define seu conteúdo.

Observação: os setores Principal e Inicialização de Backup contêm o campo ClusterCount.
Reservado ClusterCount (DataLength * 8) – ClusterCount

Esse campo é obrigatório e seu conteúdo, se houver, é reservado.

Observação: os setores Principal e Inicialização de Backup contêm o campo ClusterCount.
7.1.5.1 BitmapEntry[2] ... BitmapEntry[ClusterCount+1] Campos

Cada campo BitmapEntry nesta matriz representa um cluster no Heap de Cluster. BitmapEntry[2] representa o primeiro cluster no Heap de Cluster e BitmapEntry[ClusterCount+1] representa o último cluster no Heap de Cluster.

Os valores válidos para esses campos devem ser:

  • 0, que descreve o cluster correspondente como disponível para alocação

  • 1, que descreve o cluster correspondente como não disponível para alocação (uma alocação de cluster já pode consumir o cluster correspondente ou o FAT ativo pode descrever o cluster correspondente como inválido)

7.2 Entrada de diretório de tabela de caso acima

A Tabela de Maiúsculas e Minúsculas define a conversão de caracteres de letras minúsculas para maiúsculas e minúsculas. Isso é importante devido à entrada do diretório Nome do Arquivo (consulte Seção 7.7) usando caracteres Unicode e o sistema de arquivos exFAT não diferencia maiúsculas de minúsculas e preservação de maiúsculas e minúsculas. A Tabela De Maiúsculas e Minúsculas existe no Heap de Cluster (consulte a Seção 7.2.5) e tem uma entrada de diretório primário crítica correspondente no diretório raiz (consulte Tabela 23). O número válido de entradas de diretório tabela de maiúsculas e minúsculas é 1.

Devido à relação entre os nomes de arquivo e tabela de maiúsculas e minúsculas, as implementações não devem modificar a tabela de maiúsculas e minúsculas, exceto como resultado de operações de formato.

Table 23 Up-case Table DirectoryEntry Structure

Nome do Campo

Deslocamento

(byte)

Tamanho

(byte)

 Comentários
Entrytype 0 1 Esse campo é obrigatório e a Seção 7.2.1 define seu conteúdo.
Reserved1 1 3 Esse campo é obrigatório e seu conteúdo é reservado.
TableChecksum 4 4 Esse campo é obrigatório e a Seção 7.2.2 define seu conteúdo.
Reserved2 8 12 Esse campo é obrigatório e seu conteúdo é reservado.
FirstCluster 20 4 Esse campo é obrigatório e a Seção 7.2.3 define seu conteúdo.
Datalength 24 8 Esse campo é obrigatório e a Seção 7.2.4 define seu conteúdo.

Campo EntryType 7.2.1

O campo EntryType deve estar em conformidade com a definição fornecida no modelo Generic Primary DirectoryEntry (consulte Seção 6.3.1).

Campo TypeCode 7.2.1.1

O campo TypeCode deve estar em conformidade com a definição fornecida no modelo Generic Primary DirectoryEntry (consulte Seção 6.3.1.1).

Para a entrada do diretório Tabela de maiúsculas e minúsculas, o valor válido para esse campo é 2.

7.2.1.2 TypeImportance Field

O campo TypeImportance deve estar em conformidade com a definição fornecida no modelo Generic Primary DirectoryEntry (consulte Seção 6.3.1.2).

Para a entrada do diretório Tabela de maiúsculas e minúsculas, o valor válido para esse campo é 0.

7.2.1.3 TypeCategory Field

O campo TypeCategory deve estar em conformidade com a definição fornecida no modelo Generic Primary DirectoryEntry (consulte Seção 6.3.1.3).

7.2.1.4 InUse Field

O campo InUse deve estar em conformidade com a definição fornecida no modelo Generic Primary DirectoryEntry (consulte Seção 6.3.1.4).

7.2.2 Campo TableChecksum

O campo TableChecksum contém a soma de verificação da tabela up-case (que os campos FirstCluster e DataLength descrevem). As implementações devem verificar se o conteúdo desse campo é válido antes de usar a Tabela de Maiúsculas e Minúsculas.

Figura 3 TableChecksum Computation

UInt32 TableChecksum
(
    UCHAR  * Table,    // points to an in-memory copy of the up-case table
    UInt64   DataLength
)
{
    UInt32 Checksum = 0;
    UInt64 Index;

    for (Index = 0; Index < DataLength; Index++)
    {
        Checksum = ((Checksum&1) ? 0x80000000 : 0) + (Checksum>>1) + (UInt32)Table[Index];
    }

    return Checksum;
}

Campo FirstCluster 7.2.3

O campo FirstCluster deve estar em conformidade com a definição fornecida no modelo Generic Primary DirectoryEntry (consulte Seção 6.3.5).

Esse campo contém o índice do primeiro cluster da cadeia de cluster, como descreve o FAT, que hospeda a Tabela de Maiúsculas e Minúsculas.

7.2.4 Campo DataLength

O campo DataCluster deve estar em conformidade com a definição fornecida no modelo Generic Primary DirectoryEntry (consulte Seção 6.3.6).

7.2.5 Tabela de maiúsculas e minúsculas

Uma tabela de maiúsculas e minúsculas é uma série de mapeamentos de caracteres Unicode. Um mapeamento de caracteres consiste em um campo de 2 bytes, com o índice do campo na tabela de maiúsculas e minúsculas representando o caractere Unicode a ser cased e o campo de 2 bytes que representa o caractere Unicode com maiúsculas e minúsculas.

Os primeiros 128 caracteres Unicode têm mapeamentos obrigatórios (consulte Tabela 24). Uma tabela de maiúsculas e minúsculas que tem qualquer outro mapeamento de caracteres para qualquer um dos primeiros 128 caracteres Unicode é inválida.

Implementações que dão suporte apenas a caracteres do intervalo de mapeamento obrigatório podem ignorar os mapeamentos do restante da tabela de caso de atualização. Essas implementações só devem usar caracteres do intervalo de mapeamento obrigatório ao criar ou renomear arquivos (por meio da entrada do diretório Nome do Arquivo, consulte Seção 7.7). Ao criar maiúsculas e minúsculas de nomes de arquivo existentes, essas implementações não deverão configurar caracteres do intervalo de mapeamento não obrigatório, mas devem deixá-los intactos no nome de arquivo com maiúsculas e minúsculas resultante (isso é um up-casing parcial). Ao comparar nomes de arquivo, essas implementações devem tratar nomes de arquivo que diferem do nome em comparação apenas por caracteres Unicode do intervalo de mapeamento não obrigatório como equivalente. Embora esses nomes de arquivo sejam apenas potencialmente equivalentes, essas implementações não podem garantir que o nome de arquivo totalmente cased não colida com o nome em comparação.

Tabela 24 Entradas obrigatórias das primeiras 128 tabelas up-case

Índice de tabela + 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

(Observação: as entradas com mapeamentos de caso up-case que não são de identidade estão em negrito)

Ao formatar um volume, as implementações podem gerar uma tabela de maiúsculas e minúsculas em um formato compactado usando a compactação de mapeamento de identidade, pois uma grande parte do espaço de caracteres Unicode não tem nenhum conceito de maiúsculas e minúsculas (o que significa que os caracteres "minúsculas" e "maiúsculas" são equivalentes). As implementações compactam uma tabela de maiúsculas e minúsculas representando uma série de mapeamentos de identidade com o valor FFFFh seguido com o número de mapeamentos de identidade.

Por exemplo, uma implementação pode representar os primeiros mapeamentos de caracteres de 100 (64h) com as oito entradas a seguir de uma tabela de maiúsculas e minúsculas compactada:

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

As duas primeiras entradas indicam que os primeiros 97 (61h) caracteres (de 0000h a 0060h) têm mapeamentos de identidade. Os caracteres subsequentes, de 0061h a 0063h, mapeiam para caracteres 0041h a 0043h, respectivamente.

A capacidade de fornecer uma tabela de maiúsculas e minúsculas compactada após a formatação de um volume é opcional. No entanto, a capacidade de interpretar uma tabela descompactada e compactada é obrigatória. O valor do campo TableChecksum sempre está em conformidade com a forma como a tabela de maiúsculas e minúsculas existe no volume, que pode estar em formato compactado ou descompactado.

Ao formatar um volume, as implementações devem registrar a tabela up-case recomendada em formato compactado (consulte Tabela 25), para a qual o valor do campo TableChecksum é E619D30Dh.

Se uma implementação definir sua própria tabela de maiúsculas e minúsculas, compactada ou descompactada, essa tabela cobrirá o intervalo de caracteres Unicode completo (de códigos de caractere 0000h a FFFFh inclusive).