Compartilhar via

especificação do sistema de arquivos exFAT

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 central (veja a lista abaixo).

  1. Manter 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. Habilitar 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.

definição de termos da tabela 1 que têm um significado muito específico

de Termos de definição de
Dever Essa especificação usa o termo "deve" para descrever um comportamento que é obrigatório.
Se Essa especificação usa o termo "deve" para descrever um comportamento que ele recomenda fortemente, mas não torna obrigatório.
Maio 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 será modificada e interpretará o campo ou a estrutura conforme 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 de campo ou estrutura que implementa:

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

  2. Não deve interpretar, exceto quando as somas de verificação de computação

  3. Deve preservar todas as 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 Tabela 2).

tabela 2 texto completo de acrônimos comuns

acrônimo de Texto Completo
ASCII American Standard Code for Information Interchange
BIOS Sistema básico de saída de entrada
CPU Unidade de Processamento Central
exFAT Tabela de alocação de arquivo extensível
GORDURA 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 Seção 10.1)
INT Interromper
MBR Registro de inicialização mestre
texFAT ExFAT com segurança de transação
UTC Tempo Universal Coordenado

1.4 Qualificadores de estrutura e campo padrão

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

  1. Não estão assinados

  2. Use a notação decimal para descrever valores, onde não foi observado de outra forma; esta especificação usa a letra pós-correção "h" para indicar números hexadecimal 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

O TexFAT é uma extensão para exFAT que adiciona semântica operacional segura de transações sobre o sistema de arquivos base. O TexFAT é usado pelo 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 espaço de dados necessários 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

de deslocamento

(setor)

de tamanho de

(setores)

 comentários
região de inicialização principal
Setor de Inicialização Principal 0 1 Essa sub-região é obrigatória e seção 3.1 define seu conteúdo.
Principais setores de inicialização estendida 1 oito Essa sub-região é obrigatória e seção 3.2) define seu conteúdo.
Principais parâmetros OEM 9 1 Essa sub-região é obrigatória e 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 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 seção 3.1 define seu conteúdo.
Fazer backup de setores de inicialização estendida 13 oito Essa sub-região é obrigatória e seção 3.2 define seu conteúdo.
Parâmetros OEM de backup 21 1 Essa sub-região é obrigatória e 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 vinte e três 1 Essa sub-região é obrigatória e seção 3.4 define seu conteúdo.
de 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 Inicialização Principal e de Backup contêm o campo FatOffset.
Primeiro FAT FatOffset ComprimentoDeGordura

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

Observação: os setores Inicialização Principal e de Backup contêm os campos FatOffset e FatLength.
Segunda FAT DeslocamentoDeGordura + ComprimentoDeGordura ComprimentoGordura * (NúmeroDeGorduras - 1)

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

Observação: os setores Inicialização Principal e de Backup contêm os campos FatOffset, FatLength e NumberOfFats. O campo NumberOfFats pode conter apenas os valores 1 e 2.
de região de dados
Alinhamento do heap do 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 Inicialização Principal e 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 * 2SectorsPerClusterShift

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

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

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

Observação: os setores Inicialização Principal e 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 de inicialização necessárias, identificando informações e parâmetros do sistema de arquivos para habilitar uma implementação para executar o seguinte:

  1. Correia 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 de Inicialização de Backup é um backup da região de Inicialização Principal. Ele ajuda a 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 as 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 de Inicialização Principal ou 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 inicialize o conteúdo dos setores 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 a 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

de deslocamento

(byte)

de tamanho de

(bytes)

 comentários
JumpBoot 0 3 Esse campo é obrigatório e seção 3.1.1 define seu conteúdo.
NomeDoSistemaDeArquivos 3 oito Esse campo é obrigatório e seção 3.1.2 define seu conteúdo.
MustBeZero 11 53 Esse campo é obrigatório e seção 3.1.3 define seu conteúdo.
Deslocamento de Partição 64 oito Esse campo é obrigatório e seção 3.1.4 define seu conteúdo.
ComprimentoVolume Setenta e dois oito Esse campo é obrigatório e seção 3.1.5 define seu conteúdo.
FatOffset 80 4 Esse campo é obrigatório e seção 3.1.6 define seu conteúdo.
FatLength 84 4 Esse campo é obrigatório e seção 3.1.7 define seu conteúdo.
ClusterHeapOffset 88 4 Esse campo é obrigatório e seção 3.1.8 define seu conteúdo.
Contagem de Clusters 92 4 Esse campo é obrigatório e seção 3.1.9 define seu conteúdo.
FirstClusterOfRootDirectory 96 4 Esse campo é obrigatório e seção 3.1.10 define seu conteúdo.
Número de Série do Volume 100 4 Esse campo é obrigatório e seção 3.1.11 define seu conteúdo.
RevisãoDoSistemaDeArquivos 104 2 Esse campo é obrigatório e seção 3.1.12 define seu conteúdo.
VolumeFlags 106 2 Esse campo é obrigatório e seção 3.1.13 define seu conteúdo.
BytesPerSectorShift 108 1 Esse campo é obrigatório e seção 3.1.14 define seu conteúdo.
SectorsPerClusterShift 109 1 Esse campo é obrigatório e seção 3.1.15 define seu conteúdo.
NumberOfFats 110 1 Esse campo é obrigatório e seção 3.1.16 define seu conteúdo.
DriveSelect 111 1 Esse campo é obrigatório e seção 3.1.17 define seu conteúdo.
PercentualEmUso 112 1 Esse campo é obrigatório e seção 3.1.18 define seu conteúdo.
Reservado 113 7 Esse campo é obrigatório e seu conteúdo é reservado.
Código de Inicialização 120 390 Esse campo é obrigatório e seção 3.1.19 define seu conteúdo.
BootSignature 510 2 Esse campo é obrigatório e seção 3.1.20 define seu conteúdo.
Excesso de Espaço 512 2BytesPerSectorShift – 512

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

Observação: os setores Inicialização Principal e 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 é (em 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âmetros BIOS embalado 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 220/2BytesPerSectorShift, 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 de Excesso de Espaço for 0, o maior valor desse campo será ClusterHeapOffset + (232-11) *2SectorsPerClusterShift.

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 Primeiro 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 contabiliza os 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) * 22/2BytesPerSectorShiftarredondado para 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 os FATs existam antes do Heap de Cluster

Esse campo pode conter um valor acima de seu limite inferior (conforme descrito acima) para permitir que o Segundo FAT, se presente, também seja alinhado às características da mídia de armazenamento subjacente. O conteúdo do espaço que excede o que o próprio FAT exige, 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 * 2SectorsPerClusterShift), 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 este campo deve ser o menor dos seguintes:

  • (VolumeLength – ClusterHeapOffset) / 2SectorsPerClusterShiftarredondado 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 um 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 no máximo 224- 2 clusters no Heap de Cluster. No entanto, as implementações devem ser capazes de lidar com volumes com até 232- 11 clusters no Heap de Cluster.

3.1.10 Campo FirstClusterOfRootDirectory

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 Maiúsculas e Minúsculas 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

3.1.11 Campo VolumeSerialNumber

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 menor. 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 ordem baixa e 1 para o byte de alta ordem
  • No máximo 99 para o byte de ordem baixa 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 menor.

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 Tabela 5 VolumeFlags

nome do campo

de deslocamento

(bit)

de tamanho de

(bits)

 comentários
ActiveFat 0 1 Esse campo é obrigatório e seção 3.1.13.1 define seu conteúdo.
VolumeDirty 1 1 Esse campo é obrigatório e seção 3.1.13.2 define seu conteúdo.
MediaFailure 2 1 Esse campo é obrigatório e seção 3.1.13.3 define seu conteúdo.
ClearToZero 3 1 Esse campo é obrigatório e 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 Segundo FAT e o Bitmap de 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 fat e de alocação ativos (consulte Seção 7.1).

3.1.13.2 Campo VolumeDirty

O campo VolumeDirty deve descrever se o volume está 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 eles não resolvem. Se, ao montar um volume, o valor desse campo for 1, somente as implementações que resolvem inconsistências de metadados do sistema de arquivos poderão limpar o valor desse campo como 0. Essas implementações só limparão 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 no 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 ao acessar tentativas de 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 para falhas de mídia e registram todas as falhas como clusters "ruins" no FAT (ou resolvem 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 nesta 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 Campo BytesPerSectorShift

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 Campo SectorsPerClusterShift

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 FAT e o Primeiro Bitmap de Alocação
  • 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 Campo DriveSelect

O campo DriveSelect deve conter o número estendido da unidade INT 13h, que auxilia a inicialização desse volume usando INT 13h estendida 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 Campo PercentInUse

O campo PercentInUse deve descrever a porcentagem de clusters no Heap de Cluster que são alocados.

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 para 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 neste 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 Campo BootSignature

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 de inicialização distintas (consulte a Tabela 6). Agentes de inicialização, como as instruções de inicialização no Setor de Inicialização Principal, implementações alternativas do 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 de 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 inicialização estendida 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.

Estrutura do setor de inicialização estendida Tabela 6

nome do campo

de deslocamento

(byte)

de tamanho de

(bytes)

 comentários
ExtendedBootCode 0 2BytesPerSectorShift – 4

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

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

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

Observação: os setores Inicialização Principal e 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 neste 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 de 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 principais e de backup de parâmetros OEM

A sub-região de 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 Seção 3.3.2). Os fabricantes podem derivar suas próprias estruturas de parâmetros personalizados do modelo de 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 parâmetros OEM principais e têm a mesma estrutura (consulte Tabela 7).

Antes de usar o conteúdo dos Parâmetros OEM principal ou 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 OEM principal e de backup conforme necessário (e também atualizarão sua respectiva soma de verificação de inicialização).

Estrutura de parâmetros OEM da tabela 7

nome do campo

de deslocamento

(byte)

de tamanho de

(bytes)

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

.

.

.

.

.

.

.

.

.

.

.

.
Parâmetros[9] 432 48 Esse campo é obrigatório e 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 Inicialização Principal e 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 de Parâmetros Genéricos (consulte Seção 3.3.2). Qualquer campo Parâmetros não utilizados deve ser descrito como contendo uma estrutura de Parâmetros Nulos (consulte Seção 3.3.3).

Modelo de parâmetros genéricos 3.3.2

O modelo de 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

de deslocamento

(byte)

de tamanho de

(bytes)

 comentários
ParametersGUID 0 16 Esse campo é obrigatório e seção 3.3.2.1 define seu conteúdo.
Definido Personalizadamente 16 32 Esse campo é obrigatório e as estruturas derivadas desse modelo definem seu conteúdo.
Campo ParametersGuid 3.3.2.1

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 de Parâmetros Genéricos (consulte Seção 3.3.2) e deve descrever um campo Parâmetros não utilizados (consulte Tabela 9). Ao criar ou atualizar a estrutura de Parâmetros OEM, as implementações devem preencher campos parâmetros não utilizados com a estrutura Parâmetros Nulos. Além disso, ao criar ou atualizar a estrutura de 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 de Parâmetros OEM.

O suporte para a estrutura parâmetros nulos é obrigatório.

estrutura de parâmetros nulos tabela 9

nome do campo

de deslocamento

(byte)

de tamanho de

(bytes)

 comentários
ParametersGuid 0 16 Esse campo é obrigatório e seção 3.3.3.1 define seu conteúdo.
Reservado 16 32 Esse campo é obrigatório e seu conteúdo é reservado.
Campo ParametersGuid 3.3.3.1

O campo ParametersGuid deve estar em conformidade com a definição fornecida pelo modelo de Parâmetros Genéricos (consulte 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 do Parâmetro Flash deriva do modelo de 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 de Parâmetros Flash para otimizar as operações de acesso durante leituras/gravações e para o alinhamento das estruturas do sistema de arquivos durante a formatação da mídia.

O suporte para a estrutura de Parâmetros Flash é opcional.

Estrutura de parâmetros flash tabela 10

nome do campo

de deslocamento

(byte)

de tamanho de

(bytes)

 comentários
ParametersGuid 0 16 Esse campo é obrigatório e seção 3.3.4.1 define seu conteúdo.
EraseBlockSize 16 4 Esse campo é obrigatório e seção 3.3.4.2 define seu conteúdo.
Pagesize 20 4 Esse campo é obrigatório e seção 3.3.4.3 define seu conteúdo.
SpareSectors 24 4 Esse campo é obrigatório e seção 3.3.4.4 define seu conteúdo.
TempoDeAcessoAleatório 28 4 Esse campo é obrigatório e seção 3.3.4.5 define seu conteúdo.
Tempo de Programação 32 4 Esse campo é obrigatório e seção 3.3.4.6 define seu conteúdo.
ReadCycle 36 4 Esse campo é obrigatório e seção 3.3.4.7 define seu conteúdo.
WriteCycle 40 4 Esse campo é obrigatório e 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 de 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).

Campo ParametersGuid 3.3.4.1

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

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

Campo EraseBlockSize 3.3.4.2

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

3.3.4.3 Campo Tamanho de Página

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ível para suas operações internas de moderação.

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.

3.3.4.6 Campo ProgrammingTime

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 de soma de verificação não deve incluir os campos VolumeFlags e PercentInUse em seu respectivo Setor de Inicialização (consulte 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 principal e de inicialização 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 for alterado.

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

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 Arquivos) 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 a FAT que não está ativa como obsoleta. O uso do FAT inativo e a alternância entre FATs é específico para a implementação.

4.1 Primeira e Segunda Sub-regiões FAT

Um FAT deve descrever cadeias de cluster no Heap de Cluster (consulte Tabela 11). Uma cadeia de clusters é uma série de clusters que fornece espaço para gravar 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 arquivos Tabela 11

nome do campo

de deslocamento

(byte)

de tamanho de

(bytes)

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

.

.

.

.

.

.

.

.

.

.

.

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

Esse campo é obrigatório e 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.
Excesso de Espaço (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] só existe 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 para 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 nesta 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; a FatEntry fornecida não deve apontar para qualquer FatEntry que a 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 cluster; este é o único valor válido para a última FatEntry de qualquer cadeia de cluster determinada

5 Região de Dados

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

Sub-região do Heap de Cluster 5.1

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

de deslocamento

(setor)

de tamanho de

(setores)

 comentários
Cluster[2] ClusterHeapOffset 2SetoresPorClusterShift

Esse campo é obrigatório e 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) * 2SectorsPerClusterShift 2SectorsPerClusterShift

Esse campo é obrigatório e 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] ... Campos cluster[ClusterCount+1]

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

Cada diretório consiste em uma série de entradas de diretório (consulte 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 Tabela 13

nome do campo

de deslocamento

(byte)

de tamanho de

(byte)

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

.

.

.

.

.

.

.

.

.

.

.

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

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

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

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

Cada campo DirectoryEntry nesta matriz deriva do modelo Generic DirectoryEntry (consulte 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 Tabela 14). Todas as estruturas de entrada de diretório derivam desse modelo e somente 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 em seção 7.8 e Seção 7.9). A capacidade de interpretar o modelo Generic DirectoryEntry é obrigatória.

Modelo de DirectoryEntry Genérico da Tabela 14

nome do campo

de deslocamento

(byte)

de tamanho de

(byte)

 comentários
Tipo de entrada 0 1 Esse campo é obrigatório e seção 6.2.1 define seu conteúdo.
Definido Personalizadamente 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 seção 6.2.2 define seu conteúdo.
DataLength 24 oito Esse campo é obrigatório e seção 6.2.3 define seu conteúdo.

Campo EntryType 6.2.1

O campo EntryType tem três modos de uso que o valor do campo define (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, na verdade, reservados
    • Todas as entradas de diretório subsequentes no diretório especificado também são marcadores de fim de diretório
    • Marcadores de fim de diretório só são válidos fora dos conjuntos de entrada de diretório
    • As implementações podem substituir marcadores de fim de diretório conforme necessário
  • Entre 01h e 7Fh incluídos, que servem como um marcador de entrada de diretório não utilizado, aplicam-se as seguintes condições:
    • Todos os outros campos no DirectoryEntry especificado são, na verdade, indefinidos
    • Entradas de diretório não utilizados só são válidas fora dos conjuntos de entrada 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, aplicam-se as seguintes condições:
    • 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 Seção 6.2.1.4) que contém o valor 1

Para evitar modificações no campo InUse (consulte Seção 6.2.1.4) resultando erroneamente 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

de deslocamento

(bit)

de tamanho de

(bits)

 comentários
TypeCode 0 5 Esse campo é obrigatório e seção 6.2.1.1 define seu conteúdo.
TipoImportância 5 1 Esse campo é obrigatório e a Seção Seção 6.2.1.2 define seu conteúdo.
CategoriaTipo 6 1 Esse campo é obrigatório e seção 6.2.1.3 define seu conteúdo.
InUse 7 1 Esse campo é obrigatório e 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. Este campo, além dos campos TypeImportance e TypeCategory (consulte Seção 6.2.1.2 e Seção 6.2.1.3, respectivamente) identifica 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.

Campo TypeImportance 6.2.1.2

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 primário e crítico secundário, 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 primário e benigno, respectivamente)
Campo TypeCategory 6.2.1.3

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 Seção 6.3)
  • 1, o que significa que a entrada de diretório fornecida é secundária (consulte Seção 6.4)
Campo InUse 6.2.1.4

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 não existe nenhuma alocação de cluster
  • Entre 2 e ClusterCount + 1, que é o intervalo de índices de cluster válidos

As estruturas derivadas desse modelo poderão 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 * 2SectorsPerClusterShift* 2BytesPerSectorShift

Estruturas que derivam 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 DirectoryEntry 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 do diretório deverão ser entradas de diretório secundário (consulte Seção 6.4).

A capacidade de interpretar o modelo de DirectoryEntry Primário Genérico é 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 DirectoryEntry Primário Genérico Tabela 16

nome do campo

de deslocamento

(byte)

de tamanho de

(byte)

 comentários
Tipo de entrada 0 1 Esse campo é obrigatório e seção 6.3.1 define seu conteúdo.
SecondaryCount 1 1 Esse campo é obrigatório e seção 6.3.2 define seu conteúdo.
SetChecksum 2 2 Esse campo é obrigatório e seção 6.3.3 define seu conteúdo.
GeneralPrimaryFlags 4 2 Esse campo é obrigatório e seção 6.3.4 define seu conteúdo.
Definido Personalizadamente 6 14 Esse campo é obrigatório e as estruturas derivadas desse modelo definem seu conteúdo.
FirstCluster 20 4 Esse campo é obrigatório e seção 6.3.5 define seu conteúdo.
DataLength 24 oito Esse campo é obrigatório e 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).

Campo TypeImportance 6.3.1.2

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 do 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 correlaciona-se 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 de entrada de diretório primário críticas que essa especificação define.

6.3.1.2.2 Entradas benignas do diretório primário

As entradas benignas do diretório primário 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 correlaciona-se ao número de revisão do exFAT secundário. O suporte para qualquer entrada benigna do diretório primário que essa especificação, ou qualquer especificação subsequente, define é opcional. Uma entrada de diretório primário benigna não reconhecida renderiza toda a entrada de diretório definida como não reconhecida (além da definição dos modelos de entrada de diretório aplicáveis).

Campo TypeCategory 6.3.1.3

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.

Campo InUse 6.3.1.4

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 imediatamente seguem 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 do 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 que derivam 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 que derivam desse modelo podem redefinir os campos SecondaryCount e SetChecksum.

Figura 2 de Computação 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

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

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

estrutura de campo GeneralPrimaryFlags da tabela 17

nome do campo

de deslocamento

(bit)

de tamanho de

(bits)

 comentários
AlocaçãoPossível 0 1 Esse campo é obrigatório e seção 6.3.4.1 define seu conteúdo.
NoFatChain 1 1 Esse campo é obrigatório e seção 6.3.4.2 define seu conteúdo.
Definido Personalizadamente 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 que derivam 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 estã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 determinada.

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/(2SectorsPerClusterShift* 2BytesPerSectorShift) arredondado para o inteiro mais próximo

Se as estruturas de entrada de diretório primário crítico que derivam desse modelo redefinir 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 que derivam desse modelo podem redefinir os campos FirstCluster e DataLength. Outras estruturas derivadas desse modelo poderão 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 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 que derivam desse modelo podem redefinir os campos FirstCluster e DataLength. Outras estruturas derivadas desse modelo poderão redefinir os campos FirstCluster e DataLength somente se o campo AllocationPossible contiver o valor 0.

6.4 Modelo de DirectoryEntry Secundário Genérico

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 de DirectoryEntry Secundário Genérico é 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ítico ou benigno 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).

Modelo de Diretório Secundário Genérico Tabela 18

nome do campo

de deslocamento

(byte)

de tamanho de

(byte)

 comentários
Tipo de entrada 0 1 Esse campo é obrigatório e a Seção Seção 6.4.1 define seu conteúdo.
SinalizadoresSecundáriosGerais 1 1 Esse campo é obrigatório e seção 6.4.2 define seu conteúdo.
Definido Personalizadamente 2 18 Esse campo é obrigatório e as estruturas derivadas desse modelo definem seu conteúdo.
FirstCluster 20 4 Esse campo é obrigatório e seção 6.4.3 define seu conteúdo.
DataLength 24 oito Esse campo é obrigatório e 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).

Campo TypeImportance 6.4.1.2

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 do diretório secundário

Entradas de diretório secundário críticas contêm informações que são essenciais para o gerenciamento adequado do 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 toda a entrada de diretório definida como não reconhecida (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 do 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 Seção 7.4).

6.4.1.2.2 Entradas benignas de diretório secundário

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

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

Campo TypeCategory 6.4.1.3

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

Campo InUse 6.4.1.4

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

6.4.2 Campo GeneralSecondaryFlags

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

estrutura de campo GeneralSecondaryFlags da Tabela 19 Genérico

nome do campo

de deslocamento

(bit)

de tamanho de

(bits)

 comentários
AllocationPossible 0 1 Esse campo é obrigatório e seção 6.4.2.1 define seu conteúdo.
NoFatChain 1 1 Esse campo é obrigatório e seção 6.4.2.2 define seu conteúdo.
Definido Personalizadamente 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 mesmo campo nomeado no modelo Generic Primary DirectoryEntry (consulte Seção 6.3.4.1).

6.4.2.2 Campo NoFatChain

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

6.4.3 Campo FirstCluster

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.

6.4.4 Campo DataLength

O campo DataLength deve estar em conformidade com a definição fornecida no modelo Generic DirectoryEntry (consulte 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 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 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 única entrada de diretório bitmap de alocação só será válida se descrever o Primeiro Bitmap de Alocação (consulte 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 Bitmap de Primeira Alocação e a outra descrever o Bitmap de Segunda Alocação.

Estrutura de Diretório do Bitmap de Alocação da Tabela Tabela 20

nome do campo

de deslocamento

(byte)

de tamanho de

(byte)

 comentários
Tipo de entrada 0 1 Esse campo é obrigatório e seção 7.1.1 define seu conteúdo.
BitmapFlags 1 1 Esse campo é obrigatório e 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 seção 7.1.3 define seu conteúdo.
DataLength 24 oito Esse campo é obrigatório e 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 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 Seção 6.3.1.1).

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

Campo TypeImportance 7.1.1.2

O campo TypeImportance deve estar em conformidade com a definição fornecida no modelo de DirectoryEntry Primário Genérico (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.

Campo TypeCategory 7.1.1.3

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

Campo InUse 7.1.1.4

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.1.2 Campo BitmapFlags

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

Estrutura de campo Tabela 21 BitmapFlags

nome do campo

de deslocamento

(bit)

de tamanho de

(bits)

 comentários
BitmapIdentifier 0 1 Esse campo é obrigatório e 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 fornecida 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 só é possível quando NumberOfFats contém o valor 2

7.1.3 Campo FirstCluster

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 índice 2.

Observação

O primeiro bit no bitmap é o bit de ordem mais baixa do primeiro byte.

estrutura bitmap de alocação da tabela 22

nome do campo

de deslocamento

(bit)

de tamanho de

(bits)

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

.

.

.

.

.

.

.

.

.

.

.

.
BitmapEntry[ClusterCount+1] ClusterCount – 1 1

Esse campo é obrigatório e 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 Contagem de Clusters (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] ... Campos BitmapEntry[ClusterCount+1]

Cada campo BitmapEntry nessa 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 maiúsculas e minúsculas

A Tabela de Maiúsculas e Minúsculas define a conversão de maiúsculas e minúsculas para caracteres maiúsculas de minúsculas. Isso é importante devido à entrada do diretório Nome do Arquivo (consulte a Seção 7.7) usando caracteres Unicode e o sistema de arquivos exFAT não diferenciando maiúsculas de minúsculas e a preservação de maiúsculas e minúsculas. A tabela de maiúsculas e minúsculas existe no Heap de Cluster (consulte Seção 7.2.5) e tem uma entrada de diretório primário crítico correspondente no diretório raiz (consulte Tabela 23). O número válido de entradas de diretório de 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 caso acima, exceto como resultado de operações de formato.

Estrutura do Table DirectoryEntry da Tabela 23 de

nome do campo

de deslocamento

(byte)

de tamanho de

(byte)

 comentários
Tipo de entrada 0 1 Esse campo é obrigatório e seção 7.2.1 define seu conteúdo.
Reservado1 1 3 Esse campo é obrigatório e seu conteúdo é reservado.
TableChecksum 4 4 Esse campo é obrigatório e seção 7.2.2 define seu conteúdo.
Reservado2 oito 12 Esse campo é obrigatório e seu conteúdo é reservado.
FirstCluster 20 4 Esse campo é obrigatório e seção 7.2.3 define seu conteúdo.
DataLength 24 oito Esse campo é obrigatório e 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.

Campo TypeImportance 7.2.1.2

O campo TypeImportance deve estar em conformidade com a definição fornecida no modelo de DirectoryEntry Primário Genérico (consulte Seção 6.3.1.2).

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

Campo TypeCategory 7.2.1.3

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

Campo InUse 7.2.1.4

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

de Computação tableChecksum da Figura 3 do

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

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 caractere consiste em um campo de 2 bytes, com o índice do campo na tabela de maiúsculas e minúsculas que representa o caractere Unicode a ser colocado em maiúsculas e minúsculas, 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 maiúsculas e minúsculas. 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 nomes de arquivo existentes, essas implementações não devem criar caracteres de maiúsculas e minúsculas do intervalo de mapeamento não obrigatório, mas devem deixá-los intactos no nome de arquivo com maiúsculas e minúsculas resultante (este é 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 do arquivo totalmente atualizado não colida com o nome em comparação.

Tabela 24 Entradas obrigatórias da tabela de primeiras 128 maiúsculas de minúsculas

Í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 não de identidade em maiúsculas e minúsculas 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 compactação de mapeamento de identidade, já que uma grande parte do espaço de caractere Unicode não tem nenhum conceito de caso (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, são mapeados para caracteres de 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 deverá abranger o intervalo de caracteres Unicode completo (de códigos de caractere 0000h a FFFFh inclusive).