Especificación del sistema de archivos exFAT

1 Introducción

El sistema de archivos exFAT es el sucesor de FAT32 en la familia FAT de sistemas de archivos. Esta especificación describe el sistema de archivos exFAT y proporciona toda la información necesaria para implementar el sistema de archivos exFAT.

1.1 Objetivos de diseño

El sistema de archivos exFAT tiene tres objetivos de diseño centrales (consulte la lista siguiente).

  1. Conservar la simplicidad de los sistemas de archivos basados en FAT.

    Dos de los puntos fuertes de los sistemas de archivos basados en FAT son su relativa simplicidad y facilidad de implementación. En el espíritu de sus predecesores, los implementadores deben encontrar exFAT relativamente sencillo y fácil de implementar.

  2. Habilite archivos y dispositivos de almacenamiento muy grandes.

    El sistema de archivos exFAT usa 64 bits para describir el tamaño de archivo, lo que permite aplicaciones que dependen de archivos muy grandes. El sistema de archivos exFAT también permite clústeres de hasta 32 MB, lo que permite de forma eficaz dispositivos de almacenamiento muy grandes.

  3. Incorpore la extensibilidad para la innovación futura.

    El sistema de archivos exFAT incorpora extensibilidad en su diseño, lo que permite que el sistema de archivos siga el ritmo de las innovaciones en el almacenamiento y los cambios en el uso.

1.2 Terminología específica

En el contexto de esta especificación, ciertos términos (véase el cuadro 1) llevan un significado específico para el diseño y la implementación del sistema de archivos exFAT.

Tabla 1 Definición de términos que tienen un significado muy específico

Término Definición
Deberán Esta especificación utiliza el término "debe" para describir un comportamiento que es obligatorio.
Posible Esta especificación usa el término "should" para describir un comportamiento que recomienda encarecidamente, pero no hace obligatorio.
May Esta especificación usa el término "may" para describir un comportamiento que es opcional.
Mandatory Este término describe un campo o estructura que una implementación modificará y interpretará como se describe en esta especificación.
Opcionales Este término describe un campo o una estructura que una implementación puede admitir o no. Si una implementación admite un determinado campo o estructura opcional, modificará e interpretará el campo o la estructura como se describe en esta especificación.
No definido Este término describe el contenido de campo o estructura que una implementación puede modificar según sea necesario (es decir, claro a cero al establecer campos o estructuras circundantes) y no interpretará para contener ningún significado específico.
Reservado

Este término describe el contenido del campo o de la estructura que implementa:

  1. Se inicializará en cero y no debe usarse con ningún fin.

  2. No debe interpretar, excepto cuando se calculan sumas de comprobación.

  3. Se conservarán entre operaciones que modifiquen los campos o estructuras circundantes.

1.3 Texto completo de acrónimos comunes

Esta especificación usa acrónimos en uso común en el sector informático personal (consulte la tabla 2).

Tabla 2 Texto completo de acrónimos comunes

Acrónimo Texto completo
ASCII American Standard Code for Information Interchange
BIOS Sistema básico de salida de entrada
CPU Unidad de procesamiento central
exFAT Tabla extensible de asignación de archivos
FAT Tabla de asignación de archivos
FAT12 Tabla de asignación de archivos, índices de clúster de 12 bits
FAT16 Tabla de asignación de archivos, índices de clúster de 16 bits
FAT32 Tabla de asignación de archivos, índices de clúster de 32 bits
GPT tabla de particiones GUID
GUID Identificador único global (consulte la sección 10.1)
INT Interrupción
MBR registro de arranque maestro
texFAT ExFAT seguro para transacciones
UTC Hora universal coordinada

1.4 Calificadores de campo y estructura predeterminados

Los campos y las estructuras de esta especificación tienen los siguientes calificadores (consulte la lista siguiente), a menos que la especificación tenga en cuenta lo contrario.

  1. No están firmados

  2. Utilice la notación decimal para describir los valores, donde no se indique lo contrario; esta especificación usa la letra posterior a la corrección "h" para indicar números hexadecimales y incluir GUID en llaves

  3. Están en formato little-endian

  4. No requiere un carácter de terminación null para las cadenas

1.5 Windows CE y TexFAT

TexFAT es una extensión de exFAT que agrega semántica operativa segura para transacciones sobre el sistema de archivos base. TexFAT es utilizado por Windows CE. TexFAT requiere el uso de las dos FAT y mapas de bits de asignación para su uso en transacciones. También define varias estructuras adicionales, incluidos descriptores de relleno y descriptores de seguridad.

2 Estructura de volumen

Un volumen es el conjunto de todas las estructuras del sistema de archivos y el espacio de datos necesario para almacenar y recuperar datos de usuario. Todos los volúmenes exFAT contienen cuatro regiones (consulte la tabla 3).

Estructura de volumen de la tabla 3

Nombre de la subregión

Offset

(sector)

Tamaño

(sectores)

Comentarios
Región de arranque principal
Sector principal de arranque 0 1 Esta subregión es obligatoria y la sección 3.1 define su contenido.
Principales sectores de arranque extendido 1 8 Esta subregión es obligatoria y la sección 3.2) define su contenido.
Parámetros principales de OEM 9 1 Esta subregión es obligatoria y la sección 3.3 define su contenido.
Main Reserved 10 1 Esta subregión es obligatoria y su contenido está reservado.
Suma de comprobación de arranque principal 11 1 Esta subregión es obligatoria y la sección 3.4 define su contenido.
Región de arranque de copia de seguridad
Sector de arranque de copia de seguridad 12 1 Esta subregión es obligatoria y la sección 3.1 define su contenido.
Copia de seguridad de sectores de arranque extendido 13 8 Esta subregión es obligatoria y la sección 3.2 define su contenido.
Parámetros de OEM de copia de seguridad 21 1 Esta subregión es obligatoria y la sección 3.3 define su contenido.
Copia de seguridad reservada 22 1 Esta subregión es obligatoria y su contenido está reservado.
Suma de comprobación de arranque de copia de seguridad 23 1 Esta subregión es obligatoria y la sección 3.4 define su contenido.
Región FAT
Alineación FAT 24 FatOffset – 24

Esta subregión es obligatoria y su contenido, si existe, no está definido.

Nota: Los sectores principal y de arranque de copia de seguridad contienen el campo FatOffset.

Primer FAT FatOffset FatLength

Esta subregión es obligatoria y la sección 4.1 define su contenido.

Nota: Los sectores principal y de arranque de copia de seguridad contienen los campos FatOffset y FatLength.

Segundo FAT FatOffset + FatLength FatLength * (NumberOfFats – 1)

Esta subregión es obligatoria y la sección 4.1 define su contenido, si existe.

Nota: Los sectores principal y de arranque de copia de seguridad contienen los campos FatOffset, FatLength y NumberOfFats. El campo NumberOfFats solo puede contener los valores 1 y 2.

Región de datos
Alineación del montón de clústeres FatOffset + FatLength * NumberOfFats ClusterHeapOffset : (FatOffset + FatLength * NumberOfFats)

Esta subregión es obligatoria y su contenido, si existe, no está definido.

Nota: Los sectores principal y de arranque de copia de seguridad contienen los campos FatOffset, FatLength, NumberOfFats y ClusterHeapOffset. Los valores válidos del campo NumberOfFats son 1 y 2.

Montón de clústeres ClusterHeapOffset ClusterCount * 2SectoresPerClusterShift

Esta subregión es obligatoria y la sección 5.1 define su contenido.

Nota: Los sectores de arranque principal y de copia de seguridad contienen los campos ClusterHeapOffset, ClusterCount y SectorsPerClusterShift.

Exceso de espacio ClusterHeapOffset + ClusterCount * 2SectoresPerClusterShift VolumeLength: (ClusterHeapOffset + ClusterCount * 2SectoresPerClusterShift)

Esta subregión es obligatoria y su contenido, si existe, no está definido.

Nota: Los sectores de arranque principal y de copia de seguridad contienen los campos ClusterHeapOffset, ClusterCount, SectorsPerClusterShift y VolumeLength.

3 regiones principales y de arranque de copia de seguridad

La región de arranque principal proporciona todas las instrucciones necesarias para la división de arranque, la identificación de la información y los parámetros del sistema de archivos para permitir que una implementación realice lo siguiente:

  1. Correa de arranque de un sistema informático de un volumen exFAT.

  2. Identifique el sistema de archivos en el volumen como exFAT.

  3. Descubra la ubicación de las estructuras del sistema de archivos exFAT.

La región de arranque de copia de seguridad es una copia de seguridad de la región de arranque principal. Ayuda a la recuperación del volumen exFAT en caso de que la región de arranque principal esté en un estado incoherente. Excepto en circunstancias poco frecuentes, como la actualización de instrucciones de estrangulación de arranque, las implementaciones no deben modificar el contenido de la región de arranque de copia de seguridad.

3.1 Sub-regiones principales y del sector de arranque de copia de seguridad

El sector de arranque principal contiene código para la división de arranque de un volumen exFAT y parámetros exFAT fundamentales que describen la estructura del volumen (consulte la tabla 4). Bios, MBR u otros agentes de estrangulación de arranque pueden inspeccionar este sector y cargar y ejecutar las instrucciones de estrangulación de arranque contenidas en él.

El sector de arranque de copia de seguridad es una copia de seguridad del sector de arranque principal y tiene la misma estructura (consulte la tabla 4). El sector de arranque de copia de seguridad puede ayudar a las operaciones de recuperación; sin embargo, las implementaciones tratarán el contenido de los campos VolumeFlags y PercentInUse como obsoletos.

Antes de usar el contenido del sector principal o de arranque de copia de seguridad, las implementaciones comprobarán su contenido validando su suma de comprobación de arranque correspondiente y asegurándose de que todos sus campos están dentro de su intervalo de valores válido.

Aunque la operación de formato inicial inicial inicializará el contenido de los sectores principal y de arranque de copia de seguridad, las implementaciones pueden actualizar estos sectores (y también actualizarán su suma de comprobación de arranque correspondiente) según sea necesario. Sin embargo, las implementaciones pueden actualizar los campos VolumeFlags o PercentInUse sin actualizar su suma de comprobación de arranque respectiva (la suma de comprobación excluye específicamente estos dos campos).

Tabla 4 Estructura del sector principal y de arranque de copia de seguridad

Nombre del campo

Offset

(byte)

Tamaño

(bytes)

Comentarios
JumpBoot 0 3 Este campo es obligatorio y la sección 3.1.1 define su contenido.
FileSystemName 3 8 Este campo es obligatorio y la sección 3.1.2 define su contenido.
MustBeZero 11 53 Este campo es obligatorio y la sección 3.1.3 define su contenido.
PartitionOffset 64 8 Este campo es obligatorio y la sección 3.1.4 define su contenido.
VolumeLength 72 8 Este campo es obligatorio y la sección 3.1.5 define su contenido.
FatOffset 80 4 Este campo es obligatorio y la sección 3.1.6 define su contenido.
FatLength 84 4 Este campo es obligatorio y la sección 3.1.7 define su contenido.
ClusterHeapOffset 88 4 Este campo es obligatorio y la sección 3.1.8 define su contenido.
ClusterCount 92 4 Este campo es obligatorio y la sección 3.1.9 define su contenido.
FirstClusterOfRootDirectory 96 4 Este campo es obligatorio y la sección 3.1.10 define su contenido.
VolumeSerialNumber 100 4 Este campo es obligatorio y la sección 3.1.11 define su contenido.
FileSystemRevision 104 2 Este campo es obligatorio y la sección 3.1.12 define su contenido.
VolumeFlags 106 2 Este campo es obligatorio y la sección 3.1.13 define su contenido.
BytesPerSectorShift 108 1 Este campo es obligatorio y la sección 3.1.14 define su contenido.
SectoresPerClusterShift 109 1 Este campo es obligatorio y la sección 3.1.15 define su contenido.
NumberOfFats 110 1 Este campo es obligatorio y la sección 3.1.16 define su contenido.
DriveSelect 111 1 Este campo es obligatorio y la sección 3.1.17 define su contenido.
PercentInUse 112 1 Este campo es obligatorio y la sección 3.1.18 define su contenido.
Reservado 113 7 Este campo es obligatorio y su contenido está reservado.
BootCode 120 390 Este campo es obligatorio y la sección 3.1.19 define su contenido.
BootSignature 510 2 Este campo es obligatorio y la sección 3.1.20 define su contenido.
ExcessSpace 512 2BytesPerSectorShift : 512

Este campo es obligatorio y su contenido, si existe, no están definidos.

Nota: los sectores principal y de arranque de copia de seguridad contienen el campo BytesPerSectorShift.

Campo JumpBoot 3.1.1

El campo JumpBoot contendrá la instrucción de salto para las CPU comunes en equipos personales, que, cuando se ejecuta, "salta" la CPU para ejecutar las instrucciones de salto de arranque en el campo BootCode.

El valor válido para este campo es (en orden de byte bajo a byte de orden alto) EBh 76h 90h.

3.1.2 Campo FileSystemName

El campo FileSystemName contendrá el nombre del sistema de archivos en el volumen.

El valor válido para este campo es, en caracteres ASCII, "EXFAT", que incluye tres espacios en blanco finales.

3.1.3 Campo MustBeZero

El campo MustBeZero se corresponde directamente con el intervalo de bytes que consume el bloque de parámetros bios empaquetado en volúmenes FAT12/16/32.

El valor válido para este campo es 0, lo que ayuda a evitar que las implementaciones FAT12/16/32 monten erróneamente un volumen exFAT.

3.1.4 Campo PartitionOffset

El campo PartitionOffset describirá el desplazamiento del sector relativo a los medios de la partición que hospeda el volumen exFAT especificado. Este campo ayuda a la conexión de arranque desde el volumen usando INT extendido 13h en equipos personales.

Todos los valores posibles para este campo son válidos; sin embargo, el valor 0 indica que las implementaciones omitirán este campo.

3.1.5 VolumeLength Field

El campo VolumeLength describirá el tamaño del volumen exFAT especificado en sectores.

El intervalo válido de valores para este campo será:

  • Al menos2 2 20/ 2BytesPerSectorShift, lo que garantiza que el volumen más pequeño no sea inferior a 1 MB.

  • Como máximo 264- 1, el valor más grande que puede describir este campo.

    Sin embargo, si el tamaño de la subregión de espacio excesivo es 0, el valor más grande de este campo es ClusterHeapOffset + (232- 11) * 2SectoresPerClusterShift.

3.1.6 Campo FatOffset

El campo FatOffset describirá el desplazamiento del sector relativo al volumen del primer FAT. Este campo permite que las implementaciones alineen first FAT con las características del medio de almacenamiento subyacente.

El intervalo válido de valores para este campo será:

  • Al menos 24, que tiene en cuenta los sectores que consumen las regiones de arranque principal y arranque de copia de seguridad

  • A lo sumo ClusterHeapOffset: (FatLength * NumberOfFats), que tiene en cuenta los sectores que consume el montón de clústeres.

3.1.7 Campo FatLength

El campo FatLength describirá la longitud, en sectores, de cada tabla FAT (el volumen puede contener hasta dos FAT).

El intervalo válido de valores para este campo será:

  • Al menos (ClusterCount + 2) * 22 2BytesPerSectorShiftredondeado al entero más cercano, lo que garantiza que cada FAT tenga espacio suficiente para describir todos los clústeres del montón de clústeres.

  • Como máximo (ClusterHeapOffset - FatOffset) / NumberOfFats redondeado hacia abajo hasta el entero más cercano, lo que garantiza que las FAT existen antes del montón de clústeres.

Este campo puede contener un valor que supere su límite inferior (como se ha descrito anteriormente) para permitir que el Segundo FAT, si está presente, también se alinee con las características del medio de almacenamiento subyacente. El contenido del espacio que supera lo que requiere el propio FAT, si existe, no está definido.

3.1.8 Campo ClusterHeapOffset

El campo ClusterHeapOffset describirá el desplazamiento del sector relativo al volumen del montón del clúster. Este campo permite que las implementaciones alineen el montón de clústeres con las características del medio de almacenamiento subyacente.

El intervalo válido de valores para este campo será:

  • Al menos FatOffset + FatLength * NumberOfFats, para tener en cuenta los sectores que consumen todas las regiones anteriores

  • Como máximo 232- 1 o VolumeLength - (ClusterCount * 2SectoresPerClusterShift), el cálculo que sea menor

3.1.9 Campo ClusterCount

El campo ClusterCount describirá el número de clústeres que contiene el montón de clústeres.

El valor válido para este campo será el menor de lo siguiente:

  • (VolumeLength - ClusterHeapOffset) / 2SectoresPerClusterShiftredondeado hacia abajo hasta el entero más cercano, que es exactamente el número de clústeres que pueden caber entre el principio del montón de clústeres y el final del volumen.

  • 232- 11, que es el número máximo de clústeres que un FAT puede describir

El valor del campo ClusterCount determina el tamaño mínimo de un FAT. Para evitar fats extremadamente grandes, las implementaciones pueden controlar el número de clústeres del montón de clústeres aumentando el tamaño del clúster (a través del campo SectoresPerClusterShift). Esta especificación no recomienda más de 2 clústeres de24 a 2 en el montón de clústeres. Sin embargo, las implementaciones podrán controlar volúmenes con hasta 2 clústeres de32 a 11 en el montón de clústeres.

3.1.10 PrimerclusterOfRootCampoDirectory

El campo FirstClusterOfRootDirectory contendrá el índice de clúster del primer clúster del directorio raíz. Las implementaciones deben hacer todo lo posible por colocar el primer clúster del directorio raíz en el primer clúster no incorrecto después de los clústeres que consume el mapa de bits de asignación y la tabla de mayúsculas y minúsculas.

El intervalo válido de valores para este campo será:

  • Al menos 2, el índice del primer clúster del montón de clústeres

  • Como máximo ClusterCount + 1, el índice del último clúster del montón de clústeres

3.1.11 VolumeSerialNumber Field

El campo VolumeSerialNumber contendrá un número de serie único. Esto ayuda a las implementaciones a distinguir entre diferentes volúmenes exFAT. Las implementaciones deben generar el número de serie combinando la fecha y hora de dar formato al volumen exFAT. El mecanismo para combinar la fecha y la hora para formar un número de serie es específico de la implementación.

Todos los valores posibles para este campo son válidos.

3.1.12 Campo FileSystemRevision

El campo FileSystemRevision describirá los números de revisión principales y menores de las estructuras exFAT en el volumen especificado.

El byte de orden superior es el número de revisión principal y el byte de orden bajo es el número de revisión menor. Por ejemplo, si el byte de orden superior contiene el valor 01h y si el byte de orden bajo contiene el valor 05h, el campo FileSystemRevision describe el número de revisión 1.05. Del mismo modo, si el byte de orden superior contiene el valor 0Ah y si el byte de orden bajo contiene el valor 0Fh, el campo FileSystemRevision describe el número de revisión 10,15.

El intervalo válido de valores para este campo será:

  • Al menos 0 para el byte de orden bajo y 1 para el byte de orden superior

  • Como máximo 99 para el byte de orden bajo y 99 para el byte de orden superior

El número de revisión de exFAT que describe esta especificación es 1.00. Las implementaciones de esta especificación deben montar cualquier volumen exFAT con el número de revisión principal 1 y no montarán ningún volumen exFAT con ningún otro número de revisión importante. Las implementaciones respetarán el número de revisión menor y no realizarán operaciones ni crearán ninguna estructura del sistema de archivos que no se describa en la especificación correspondiente del número de revisión menor especificado.

3.1.13 Campo VolumeFlags

El campo VolumeFlags contendrá marcas que indican el estado de varias estructuras del sistema de archivos en el volumen exFAT (véase la tabla 5).

Las implementaciones no incluirán este campo al calcular la suma de comprobación correspondiente de la región de arranque principal o de arranque de copia de seguridad. Al hacer referencia al sector de arranque de copia de seguridad, las implementaciones tratarán este campo como obsoleto.

Estructura de campo VolumeFlags de la tabla 5

Nombre del campo

Offset

(bit)

Tamaño

(bits)

Comentarios
ActiveFat 0 1 Este campo es obligatorio y la sección 3.1.13.1 define su contenido.
VolumeDirty 1 1 Este campo es obligatorio y la sección 3.1.13.2 define su contenido.
MediaFailure 2 1 Este campo es obligatorio y la sección 3.1.13.3 define su contenido.
ClearToZero 3 1 Este campo es obligatorio y la sección 3.1.13.4 define su contenido.
Reservado 4 12 Este campo es obligatorio y su contenido está reservado.
3.1.13.1 Campo ActiveFat

El campo ActiveFat describirá qué mapa de bits fat y asignación están activos (y las implementaciones usarán), como se indica a continuación:

  • 0, lo que significa que el mapa de bits first FAT y first allocation están activos

  • 1, lo que significa que el mapa de bits de segunda asignación y FAT están activos y solo es posible cuando el campo NumberOfFats contiene el valor 2.

Las implementaciones tendrán en cuenta el mapa de bits fat y de asignación inactivos como obsoletos. Solo las implementaciones compatibles con TexFAT cambiarán los mapas de bits fat y de asignación activos (consulte la sección 7.1).

3.1.13.2 Campo VolumeDirty

El campo VolumeDirty describirá si el volumen está sucio o no, como se indica a continuación:

  • 0, lo que significa que el volumen probablemente está en un estado coherente

  • 1, lo que significa que el volumen probablemente está en un estado incoherente

Las implementaciones deben establecer el valor de este campo en 1 al encontrar incoherencias de metadatos del sistema de archivos que no resuelven. Si, al montar un volumen, el valor de este campo es 1, solo las implementaciones que resuelven incoherencias de metadatos del sistema de archivos pueden borrar el valor de este campo en 0. Estas implementaciones solo borrarán el valor de este campo en 0 después de asegurarse de que el sistema de archivos se encuentra en un estado coherente.

Si, al montar un volumen, el valor de este campo es 0, las implementaciones deben establecer este campo en 1 antes de actualizar los metadatos del sistema de archivos y borrar este campo en 0 posteriormente, de forma similar al orden de escritura recomendado descrito en la sección 8.1.

3.1.13.3 Campo MediaFailure

El campo MediaFailure describirá si una implementación ha detectado errores de medios o no, como se indica a continuación:

  • 0, lo que significa que el medio de hospedaje no ha notificado errores o que ya se han registrado errores conocidos en los clústeres fat como "incorrectos".

  • 1, lo que significa que el medio de hospedaje ha notificado errores (es decir, ha producido errores en las operaciones de lectura o escritura).

Una implementación debe establecer este campo en 1 cuando:

  1. El medio de hospedaje produce un error en los intentos de acceso a cualquier región del volumen.

  2. La implementación ha agotado los algoritmos de reintento de acceso, si los hay.

Si, al montar un volumen, el valor de este campo es 1, las implementaciones que examinan todo el volumen en busca de errores multimedia y registran todos los errores como clústeres "incorrectos" en FAT (o resolver errores multimedia) pueden borrar el valor de este campo en 0.

3.1.13.4 Campo ClearToZero

El campo ClearToZero no tiene un significado significativo en esta especificación.

Los valores válidos para este campo son:

  • 0, que no tiene ningún significado concreto

  • 1, lo que significa que las implementaciones borrarán este campo a 0 antes de modificar las estructuras, directorios o archivos del sistema de archivos.

Campo 3.1.14 BytesPerSectorShift

El campo BytesPerSectorShift describirá los bytes por sector expresados como registro2(N), donde N es el número de bytes por sector. Por ejemplo, para 512 bytes por sector, el valor de este campo es 9.

El intervalo válido de valores para este campo será:

  • Al menos 9 (tamaño del sector de 512 bytes), que es el sector más pequeño posible para un volumen exFAT

  • Como máximo 12 (tamaño de sector de 4096 bytes), que es el tamaño de página de memoria de las CPU comunes en los equipos personales

3.1.15 SectoresPerClusterShift

El campo SectoresPerClusterShift describirá los sectores por clúster expresados como registro2(N), donde N es el número de sectores por clúster. Por ejemplo, para 8 sectores por clúster, el valor de este campo es 3.

El intervalo válido de valores para este campo será:

  • Al menos 0 (1 sector por clúster), que es el clúster más pequeño posible

  • Como máximo 25: BytesPerSectorShift, que se evalúa como un tamaño de clúster de 32 MB

3.1.16 Campo NumberOfFats

El campo NumberOfFats describirá el número de FAT y mapas de bits de asignación que contiene el volumen.

El intervalo válido de valores para este campo será:

  • 1, que indica que el volumen solo contiene el mapa de bits first FAT y first allocation

  • 2, que indica que el volumen contiene el Primer FAT, Segundo FAT, Mapa de bits de primera asignación y Mapa de bits de segunda asignación; este valor solo es válido para volúmenes TexFAT.

3.1.17 UnidadSeleccionar campo

El campo DriveSelect contendrá el número de unidad INT 13h extendido, que ayuda al arranque de este volumen mediante int extendido 13h en equipos personales.

Todos los valores posibles para este campo son válidos. Los campos similares de los sistemas de archivos basados en FAT anteriores contenían con frecuencia el valor 80h.

3.1.18 Campo PercentInUse

El campo PercentInUse describirá el porcentaje de clústeres del montón de clústeres que se asignan.

El intervalo válido de valores para este campo será:

  • Entre 0 y 100 inclusive, que es el porcentaje de clústeres asignados en el montón del clúster, redondeado hacia abajo hasta el entero más cercano.

  • FFh exactamente, que indica que el porcentaje de clústeres asignados en el montón de clústeres no está disponible

Las implementaciones cambiarán el valor de este campo para reflejar los cambios en la asignación de clústeres en el montón de clústeres o lo cambiarán a FFh.

Las implementaciones no incluirán este campo al calcular la suma de comprobación correspondiente de la región de arranque principal o de arranque de copia de seguridad. Al hacer referencia al sector de arranque de copia de seguridad, las implementaciones tratarán este campo como obsoleto.

3.1.19 Campo BootCode

El campo BootCode contendrá instrucciones de estrangulación de arranque. Las implementaciones pueden rellenar este campo con las instrucciones de CPU necesarias para el arranque de un sistema informático. Las implementaciones que no proporcionan instrucciones de salto de arranque inicializarán cada byte de este campo a F4h (la instrucción de detención para las CPU comunes en equipos personales) como parte de su operación de formato.

3.1.20 Campo BootSignature

El campo BootSignature describirá si la intención de un sector determinado es que sea un sector de arranque o no.

El valor válido para este campo es AA55h. Cualquier otro valor de este campo invalida su respectivo sector de arranque. Las implementaciones deben comprobar el contenido de este campo antes de depender de cualquier otro campo en su respectivo sector de arranque.

3.2 Subárboles principales y de copia de seguridad de sectores de arranque extendido

Cada sector de los principales sectores de arranque extendido tiene la misma estructura; sin embargo, cada sector puede contener instrucciones distintas de estratos de arranque (consulte la tabla 6). Los agentes de estrabación de arranque, como las instrucciones de estrangulación de arranque en el sector de arranque principal, las implementaciones alternativas del BIOS o el firmware de un sistema incrustado, pueden cargar estos sectores y ejecutar las instrucciones que contienen.

Los sectores de arranque extendido de copia de seguridad son una copia de seguridad de los principales sectores de arranque extendido y tienen la misma estructura (consulte la tabla 6).

Antes de ejecutar las instrucciones de los sectores de arranque extendido principal o de copia de seguridad, las implementaciones deben comprobar su contenido asegurándose de que el campo ExtendedBootSignature de cada sector contenga su valor prescrito.

Aunque la operación de formato inicial inicial inicializará el contenido de los sectores principal y de arranque extendido de copia de seguridad, las implementaciones pueden actualizar estos sectores (y también actualizarán su suma de comprobación de arranque correspondiente) según sea necesario.

Tabla 6 Estructura del sector de arranque extendido

Nombre del campo

Offset

(byte)

Tamaño

(bytes)

Comentarios
ExtendedBootCode 0 2BytesPerSectorShift : 4

Este campo es obligatorio y la sección 3.2.1 define su contenido.

Nota: Los sectores principal y de arranque de copia de seguridad contienen el campo BytesPerSectorShift.

ExtendedBootSignature 2BytesPerSectorShift : 4 4

Este campo es obligatorio y la sección 3.2.2 define su contenido.

Nota: Los sectores principal y de arranque de copia de seguridad contienen el campo BytesPerSectorShift.

3.2.1 Campo ExtendedBootCode

El campo ExtendedBootCode contendrá instrucciones de estrangulación de arranque. Las implementaciones pueden rellenar este campo con las instrucciones de CPU necesarias para el arranque de un sistema informático. Las implementaciones que no proporcionan instrucciones de salto de arranque inicializarán cada byte de este campo a 00h como parte de su operación de formato.

3.2.2 Campo ExtendedBootSignature

El campo ExtendedBootSignature describirá si la intención del sector determinado es que sea un sector de arranque extendido o no.

El valor válido para este campo es AA550000h. Cualquier otro valor de este campo invalida su respectivo sector de arranque extendido principal o de copia de seguridad. Las implementaciones deben comprobar el contenido de este campo antes de depender de cualquier otro campo en su respectivo sector de arranque extendido.

3.3 Subárboles principales y de parámetros oem de copia de seguridad

La subregión Parámetros principales de OEM contiene diez estructuras de parámetros que pueden contener información específica del fabricante (consulte la tabla 7). Cada una de las diez estructuras de parámetros se deriva de la plantilla Parámetros genéricos (consulte la sección 3.3.2). Los fabricantes pueden derivar sus propias estructuras de parámetros personalizados de la plantilla Parámetros genéricos. Esta especificación define dos estructuras de parámetros: Parámetros NULL (consulte sección 3.3.3) y Parámetros flash (consulte la sección 3.3.4).

Los parámetros de OEM de copia de seguridad son una copia de seguridad de los parámetros principales de OEM y tienen la misma estructura (consulte la tabla 7).

Antes de usar el contenido de los parámetros de OEM principal o de copia de seguridad, las implementaciones comprobarán su contenido validando la suma de comprobación de arranque correspondiente.

Los fabricantes deben rellenar los parámetros oem principal y de copia de seguridad con sus propias estructuras de parámetros personalizados, si las hay, y cualquier otra estructura de parámetros. Las operaciones de formato posteriores conservarán el contenido de los parámetros del OEM principal y de copia de seguridad.

Las implementaciones pueden actualizar los parámetros del OEM principal y de copia de seguridad según sea necesario (y también actualizarán su suma de comprobación de arranque correspondiente).

Estructura de parámetros de OEM de la tabla 7

Nombre del campo

Offset

(byte)

Tamaño

(bytes)

Comentarios
Parámetros[0] 0 48 Este campo es obligatorio y la sección 3.3.1 define su contenido.

.

.

.

.

.

.

.

.

.

.

.

.

Parámetros[9] 432 48 Este campo es obligatorio y la sección 3.3.1 define su contenido.
Reservado 480 2BytesPerSectorShift : 480

Este campo es obligatorio y su contenido está reservado.

Nota: los sectores principal y de arranque de copia de seguridad contienen el campo BytesPerSectorShift.

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

Cada campo Parámetros de esta matriz contiene una estructura de parámetros, que se deriva de la plantilla Parámetros genéricos (consulte la sección 3.3.2). Cualquier campo Parámetros sin usar se describirá como que contiene una estructura de parámetros NULL (consulte la sección 3.3.3).

Plantilla de parámetros genéricos 3.3.2

La plantilla Parámetros genéricos proporciona la definición base de una estructura de parámetros (consulte la tabla 8). Todas las estructuras de parámetros derivan de esta plantilla. La compatibilidad con esta plantilla de parámetros genéricos es obligatoria.

Plantilla de parámetros genéricos de la tabla 8

Nombre del campo

Offset

(byte)

Tamaño

(bytes)

Comentarios
ParametersGuid 0 16 Este campo es obligatorio y la sección 3.3.2.1 define su contenido.
CustomDefined 16 32 Este campo es obligatorio y las estructuras que derivan de esta plantilla definen su contenido.
3.3.2.1 ParámetrosCampoGuid

El campo ParametersGuid describirá un GUID, que determina el diseño del resto de la estructura de parámetros especificada.

Todos los valores posibles para este campo son válidos; Sin embargo, los fabricantes deben usar una herramienta de generación de GUID, como GuidGen.exe, para seleccionar un GUID al derivar estructuras de parámetros personalizados de esta plantilla.

3.3.3 Parámetros NULL

La estructura Parámetros NULL se deriva de la plantilla Parámetros genéricos (consulte la sección 3.3.2) y describirá un campo Parámetros sin usar (consulte la tabla 9). Al crear o actualizar la estructura Parámetros de OEM, las implementaciones rellenarán los campos Parámetros sin usar con la estructura Parámetros NULL. Además, al crear o actualizar la estructura de parámetros oem, las implementaciones deben consolidar las estructuras de parámetros NULL al final de la matriz, dejando así todas las demás estructuras parameters al principio de la estructura de parámetros de OEM.

La compatibilidad con la estructura De parámetros NULL es obligatoria.

Tabla 9 Estructura de parámetros NULL

Nombre del campo

Offset

(byte)

Tamaño

(bytes)

Comentarios
ParametersGuid 0 16 Este campo es obligatorio y la sección 3.3.3.1 define su contenido.
Reservado 16 32 Este campo es obligatorio y su contenido está reservado.
3.3.3.1 ParámetrosCampoGuid

El campo ParametersGuid se ajustará a la definición proporcionada por la plantilla Parámetros genéricos (consulte la sección 3.3.2.1).

El valor válido para este campo, en notación GUID, es {00000000-0000-0000-0000-000000000000}.

3.3.4 Parámetros flash

La estructura de parámetros flash se deriva de la plantilla Parámetros genéricos (consulte la sección 3.3.2) y contiene parámetros para medios flash (consulte la tabla 10). Los fabricantes de dispositivos de almacenamiento basados en flash pueden rellenar un campo Parámetros (preferiblemente el campo Parámetros[0] ) con esta estructura de parámetros. Las implementaciones pueden usar la información de la estructura De parámetros flash para optimizar las operaciones de acceso durante las lecturas y escrituras y para la alineación de las estructuras del sistema de archivos que duren el formato del medio.

La compatibilidad con la estructura de parámetros flash es opcional.

Tabla 10 Estructura de parámetros flash

Nombre del campo

Offset

(byte)

Tamaño

(bytes)

Comentarios
ParametersGuid 0 16 Este campo es obligatorio y la sección 3.3.4.1 define su contenido.
EraseBlockSize 16 4 Este campo es obligatorio y la sección 3.3.4.2 define su contenido.
PageSize 20 4 Este campo es obligatorio y la sección 3.3.4.3 define su contenido.
SpareSectors 24 4 Este campo es obligatorio y la sección 3.3.4.4 define su contenido.
RandomAccessTime 28 4 Este campo es obligatorio y la sección 3.3.4.5 define su contenido.
ProgrammingTime 32 4 Este campo es obligatorio y la sección 3.3.4.6 define su contenido.
ReadCycle 36 4 Este campo es obligatorio y la sección 3.3.4.7 define su contenido.
WriteCycle 40 4 Este campo es obligatorio y la sección 3.3.4.8 define su contenido.
Reservado 44 4 Este campo es obligatorio y su contenido está reservado.

Todos los valores posibles para todos los campos Parámetros de Flash, excepto para el campo ParametersGuid, son válidos. Sin embargo, el valor 0 indica que el campo no tiene sentido (las implementaciones omitirán el campo especificado).

3.3.4.1 Campo ParametersGuid

El campo ParametersGuid se ajustará a la definición proporcionada en la plantilla Parámetros genéricos (vea la sección 3.3.2.1).

El valor válido para este campo, en notación GUID, es {0A0C7E46-3399-4021-90C8-FA6D389C4BA2}.

3.3.4.2 Campo EraseBlockSize

El campo EraseBlockSize describirá el tamaño, en bytes, del bloque de borrado del medio flash.

3.3.4.3 Campo PageSize

El campo PageSize describirá el tamaño, en bytes de la página del medio flash.

3.3.4.4 Campo SpareSectors

El campo SpareSectors describirá el número de sectores que el medio flash tiene disponible para sus operaciones de moderación internas.

3.3.4.5 Campo RandomAccessTime

El campo RandomAccessTime describirá el tiempo medio de acceso aleatorio del medio flash, en nanosegundos.

3.3.4.6 Campo ProgrammingTime

El campo ProgrammingTime describirá el tiempo medio de programación del medio flash, en nanosegundos.

3.3.4.7 Campo ReadCycle

El campo ReadCycle describirá el tiempo medio del ciclo de lectura del medio flash, en nanosegundos.

3.3.4.8 Campo WriteCycle

El campo WriteCycle describirá el tiempo medio del ciclo de escritura, en nanosegundos.

3.4 Subárboles principales y de suma de comprobación de arranque de copia de seguridad

Las sumas de comprobación de arranque principal y de copia de seguridad contienen cada uno un patrón de repetición de la suma de comprobación de cuatro bytes del contenido de todas las demás subárboles de sus respectivas regiones de arranque. El cálculo de la suma de comprobación no incluirá los campos VolumeFlags y PercentInUse en su respectivo sector de arranque (consulte la figura 1). El patrón de repetición de la suma de comprobación de cuatro bytes rellena su subregión de suma de comprobación de arranque correspondiente desde el principio hasta el final de la subregión.

Antes de usar el contenido de cualquiera de las demás subárboles de las regiones principal o de arranque de copia de seguridad, las implementaciones comprobarán su contenido validando su suma de comprobación de arranque correspondiente.

Aunque la operación de formato inicial rellenará las sumas de comprobación principal y de arranque de copia de seguridad con el patrón de suma de comprobación repetida, las implementaciones actualizarán estos sectores a medida que cambie el contenido de los demás sectores en sus respectivas regiones de arranque.

Figura 1 Cálculo de suma de comprobación de arranque

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ón de tabla de asignación de archivos

La región tabla de asignación de archivos (FAT) puede contener hasta dos FAT, una en la subregión First FAT y otra en la segunda subregión FAT. El campo NumberOfFats describe cuántas FAT contiene esta región. Los valores válidos para el campo NumberOfFats son 1 y 2. Por lo tanto, la subregión First FAT siempre contiene un FAT. Si el campo NumberOfFats es dos, la subregión Second FAT también contiene un FAT.

El campo ActiveFat del campo VolumeFlags describe qué FAT está activo. Solo el campo VolumeFlags del sector de arranque principal es actual. Las implementaciones tratarán la FAT que no está activa como obsoleta. El uso de FAT inactivo y el cambio entre fats es específico de la implementación.

4.1 Primera y segunda subárbol FAT

Un FAT describirá las cadenas de clúster en el montón de clústeres (consulte la tabla 11). Una cadena de clústeres es una serie de clústeres que proporciona espacio para registrar el contenido de archivos, directorios y otras estructuras del sistema de archivos. Un FAT representa una cadena de clústeres como una lista vinculada de forma singly de índices de clúster. Con la excepción de las dos primeras entradas, cada entrada de un FAT representa exactamente un clúster.

Tabla 11 Estructura de tabla de asignación de archivos

Nombre del campo

Offset

(byte)

Tamaño

(bytes)

Comentarios
FatEntry[0] 0 4 Este campo es obligatorio y la sección 4.1.1 define su contenido.
FatEntry[1] 4 4 Este campo es obligatorio y la sección 4.1.2 define su contenido.
FatEntry[2] 8 4 Este campo es obligatorio y la sección 4.1.3 define su contenido.

.

.

.

.

.

.

.

.

.

.

.

.

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

Este campo es obligatorio y la sección 4.1.3 define su contenido.

ClusterCount + 1 nunca puede superar FFFFFFF6h.

Nota: Los sectores principal y de arranque de copia de seguridad contienen el campo ClusterCount.

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

Este campo es obligatorio y su contenido, si existe, no está definido.

Nota: Los sectores principal y de arranque de copia de seguridad contienen los campos ClusterCount, FatLength y BytesPerSectorShift.

4.1.1 FatEntry[0] Campo

El campo FatEntry[0] describirá el tipo de medio en el primer byte (el byte de orden inferior) y contendrá FFh en los tres bytes restantes.

El tipo de medio (el primer byte) debe ser F8h.

4.1.2 FatEntry[1] Campo

El campo FatEntry[1] solo existe debido a la prioridad histórica y no describe nada de interés.

El valor válido para este campo es FFFFFFFFh. Las implementaciones inicializarán este campo en su valor prescrito y no deben utilizar este campo para ningún propósito. Las implementaciones no deben interpretar este campo y conservarán su contenido en las operaciones que modifican los campos circundantes.

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

Cada campo FatEntry de esta matriz representará un clúster en el montón de clústeres. FatEntry[2] representa el primer clúster del montón de clústeres y FatEntry[ClusterCount+1] representa el último clúster del montón de clústeres.

El intervalo válido de valores para estos campos será:

  • Entre 2 y ClusterCount + 1, ambos inclusive, que apunta a la siguiente FatEntry en la cadena de clústeres especificada; el objeto FatEntry dado no señalará a fatEntry que lo preceda en la cadena de clústeres especificada.

  • Exactamente FFFFFFF7h, que marca el clúster correspondiente de FatEntry dado como "malo"

  • Exactamente FFFFFFFFh, que marca el clúster correspondiente de FatEntry dado como el último clúster de una cadena de clústeres; este es el único valor válido para el último FatEntry de cualquier cadena de clústeres determinada.

5 Región de datos

La región De datos contiene el montón de clústeres, que proporciona espacio administrado para estructuras, directorios y archivos del sistema de archivos.

5.1 Subregión del montón de clústeres

La estructura del montón de clústeres es muy sencilla (consulte la tabla 12); cada serie consecutiva de sectores describe un clúster, como define el campo SectoresPerClusterShift. Lo importante es que el primer clúster del montón de clústeres tiene el índice dos, que corresponde directamente al índice de FatEntry[2].

En un volumen exFAT, un mapa de bits de asignación (consulte la sección 7.1.5) mantiene el registro del estado de asignación de todos los clústeres. Se trata de una diferencia significativa de las predecesoras de exFAT (FAT12, FAT16 y FAT32), en las que un FAT mantuvo un registro del estado de asignación de todos los clústeres en el montón del clúster.

Tabla 12 Estructura del montón de clústeres

Nombre del campo

Offset

(sector)

Tamaño

(sectores)

Comentarios
Clúster[2] ClusterHeapOffset 2SectoresPerClusterShift

Este campo es obligatorio y la sección 5.1.1 define su contenido.

Nota: Los sectores principal y de arranque de copia de seguridad contienen los campos ClusterHeapOffset y SectorsPerClusterShift.

.

.

.

.

.

.

.

.

.

.

.

.

Cluster[ClusterCount+1] ClusterHeapOffset + (ClusterCount – 1) * 2SectoresPerClusterShift 2SectoresPerClusterShift

Este campo es obligatorio y la sección 5.1.1 define su contenido.

Nota: Los sectores de arranque principal y de copia de seguridad contienen los campos ClusterCount, ClusterHeapOffset y SectorsPerClusterShift.

5.1.1 Clúster[2] ... Cluster[ClusterCount+1] Fields

Cada campo Cluster de esta matriz es una serie de sectores contiguos, cuyo tamaño está definido por el campo SectorsPerClusterShift.

6 Estructura de directorios

El sistema de archivos exFAT usa un enfoque de árbol de directorios para administrar las estructuras y archivos del sistema de archivos que existen en el montón de clústeres. Los directorios tienen una relación uno a varios entre los elementos primarios y secundarios en el árbol de directorios.

El directorio al que hace referencia el campo FirstClusterOfRootDirectory es la raíz del árbol de directorios. Todos los demás directorios descienden del directorio raíz de una manera vinculada singly.

Cada directorio consta de una serie de entradas de directorio (consulte la tabla 13).

Una o varias entradas de directorio se combinan en un conjunto de entradas de directorio que describe algo de interés, como una estructura del sistema de archivos, un subdirectorio o un archivo.

Tabla 13 Estructura de directorios

Nombre del campo

Offset

(byte)

Tamaño

(byte)

Comentarios
DirectoryEntry[0] 0 32 Este campo es obligatorio y la sección 6.1 define su contenido.

.

.

.

.

.

.

.

.

.

.

.

.

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

Este campo es obligatorio y la sección 6.1 define su contenido.

N, el número de campos DirectoryEntry es el tamaño, en bytes, de la cadena de clústeres que contiene el directorio especificado, dividido por el tamaño de un campo DirectoryEntry, 32 bytes.

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

Cada campo DirectoryEntry de esta matriz deriva de la plantilla DirectoryEntry genérico (consulte la sección 6.2).

6.2 Plantilla de DirectoryEntry genérica

La plantilla Generic DirectoryEntry proporciona la definición base para las entradas de directorio (vea la tabla 14). Todas las estructuras de entrada de directorio derivan de esta plantilla y solo las estructuras de entrada de directorio definidas por Microsoft son válidas (exFAT no tiene disposiciones para las estructuras de entrada de directorio definidas por el fabricante, excepto según se define en la sección 7.8 y la sección 7.9). La capacidad de interpretar la plantilla Generic DirectoryEntry es obligatoria.

Tabla 14 Generic DirectoryEntry Template

Nombre del campo

Offset

(byte)

Tamaño

(byte)

Comentarios
EntryType 0 1 Este campo es obligatorio y la sección 6.2.1 define su contenido.
CustomDefined 1 19 Este campo es obligatorio y las estructuras que derivan de esta plantilla pueden definir su contenido.
FirstCluster 20 4 Este campo es obligatorio y la sección 6.2.2 define su contenido.
DataLength 24 8 Este campo es obligatorio y la sección 6.2.3 define su contenido.

6.2.1 Campo EntryType

El campo EntryType tiene tres modos de uso que define el valor del campo (vea la lista siguiente).

  • 00h, que es un marcador de fin de directorio y se aplican las condiciones siguientes:

    • Todos los demás campos de DirectoryEntry especificados están realmente reservados.

    • Todas las entradas de directorio posteriores del directorio especificado también son marcadores de fin de directorio

    • Los marcadores de fin de directorio solo son válidos fuera de los conjuntos de entradas de directorio

    • Las implementaciones pueden sobrescribir los marcadores de fin de directorio según sea necesario.

  • Entre 01h y 7Fh, que es un marcador de entrada de directorio sin usar y se aplican las condiciones siguientes:

    • Todos los demás campos del objeto DirectoryEntry especificados no están definidos

    • Las entradas de directorio sin usar solo son válidas fuera de los conjuntos de entradas de directorio

    • Las implementaciones pueden sobrescribir entradas de directorio sin usar según sea necesario.

    • Este intervalo de valores corresponde al campo InUse (vea la sección 6.2.1.4) que contiene el valor 0.

  • Entre 81h y FFh, que es una entrada de directorio regular y se aplican las condiciones siguientes:

    • El contenido del campo EntryType (vea la tabla 15) determina el diseño del resto de la estructura DirectoryEntry.

    • Este intervalo de valores, y solo este intervalo de valores, son válidos dentro de un conjunto de entradas de directorio.

    • Este intervalo de valores corresponde directamente al campo InUse (vea la sección 6.2.1.4) que contiene el valor 1.

Para evitar modificaciones en el campo InUse (vea sección 6.2.1.4) da lugar erróneamente a un marcador de fin de directorio, el valor 80h no es válido.

Tabla 15 Estructura de campo EntryType genérico

Nombre del campo

Offset

(bit)

Tamaño

(bits)

Comentarios
TypeCode 0 5 Este campo es obligatorio y la sección 6.2.1.1 define su contenido.
TypeImportance 5 1 Este campo es obligatorio y la sección 6.2.1.2 define su contenido.
TypeCategory 6 1 Este campo es obligatorio y la sección 6.2.1.3 define su contenido.
InUse 7 1 Este campo es obligatorio y la sección 6.2.1.4 define su contenido.
Campo TypeCode 6.2.1.1

El campo TypeCode describe parcialmente el tipo específico de la entrada de directorio especificada. Este campo, además de los campos TypeImportance y TypeCategory (vea sección 6.2.1.2 y sección 6.2.1.3, respectivamente) identifican de forma única el tipo de la entrada de directorio especificada.

Todos los valores posibles de este campo son válidos, a menos que los campos TypeImportance y TypeCategory contengan el valor 0; en ese caso, el valor 0 no es válido para este campo.

6.2.1.2 Campo TypeImportance

El campo TypeImportance describirá la importancia de la entrada de directorio especificada.

Los valores válidos para este campo serán:

6.2.1.3 Campo TypeCategory

El campo TypeCategory describirá la categoría de la entrada de directorio especificada.

Los valores válidos para este campo serán:

  • 0, lo que significa que la entrada de directorio especificada es principal (consulte la sección 6.3)

  • 1, lo que significa que la entrada de directorio especificada es secundaria (consulte la sección 6.4)

6.2.1.4 Campo inUse

El campo InUse describirá si la entrada de directorio especificada en uso o no.

Los valores válidos para este campo serán:

  • 0, lo que significa que la entrada de directorio especificada no está en uso; esto significa que la estructura especificada es realmente una entrada de directorio sin usar.

  • 1, lo que significa que la entrada de directorio especificada está en uso; esto significa que la estructura especificada es una entrada de directorio regular.

6.2.2 Campo FirstCluster

El campo FirstCluster contendrá el índice del primer clúster de una asignación en el montón de clúster asociado a la entrada de directorio especificada.

El intervalo válido de valores para este campo será:

  • Exactamente 0, lo que significa que no existe ninguna asignación de clúster

  • Entre 2 y ClusterCount + 1, que es el intervalo de índices de clúster válidos

Las estructuras que derivan de esta plantilla pueden redefinir los campos FirstCluster y DataLength, si una asignación de clúster no es compatible con la estructura derivada.

6.2.3 Campo DataLength

El campo DataLength describe el tamaño, en bytes, de los datos que contiene la asignación de clúster asociada.

El intervalo válido de valor para este campo es:

  • Al menos 0; si el campo FirstCluster contiene el valor 0, el único valor válido de este campo es 0.

  • Como máximo ClusterCount * 2SectoresPerClusterShift* 2BytesPerSectorShift

Las estructuras que derivan de esta plantilla pueden redefinir los campos FirstCluster y DataLength, si una asignación de clúster no es posible para la estructura derivada.

6.3 Plantilla de directorio principal genéricoEntry

La primera entrada de directorio en un conjunto de entradas de directorio será una entrada de directorio principal. Todas las entradas de directorio posteriores, si las hay, en el conjunto de entradas de directorio serán entradas de directorio secundarias (consulte la sección 6.4).

La capacidad de interpretar la plantilla Generic Primary DirectoryEntry es obligatoria.

Todas las estructuras de entrada de directorio principal derivan de la plantilla Directorio principal genéricoEntry (consulte la tabla 16), que se deriva de la plantilla DirectoryEntry genérica (consulte la sección 6.2).

Tabla 16 Plantilla de directorio principal genéricoEntry

Nombre del campo

Offset

(byte)

Tamaño

(byte)

Comentarios
EntryType 0 1 Este campo es obligatorio y la sección 6.3.1 define su contenido.
SecondaryCount 1 1 Este campo es obligatorio y la sección 6.3.2 define su contenido.
SetChecksum 2 2 Este campo es obligatorio y la sección 6.3.3 define su contenido.
GeneralPrimaryFlags 4 2 Este campo es obligatorio y la sección 6.3.4 define su contenido.
CustomDefined 6 14 Este campo es obligatorio y las estructuras que derivan de esta plantilla definen su contenido.
FirstCluster 20 4 Este campo es obligatorio y la sección 6.3.5 define su contenido.
DataLength 24 8 Este campo es obligatorio y la sección 6.3.6 define su contenido.

Campo EntryType 6.3.1

El campo EntryType se ajustará a la definición proporcionada en la plantilla DirectoryEntry genérica (consulte la sección 6.2.1).

Campo TypeCode 6.3.1.1

El campo TypeCode se ajustará a la definición proporcionada en la plantilla DirectoryEntry genérica (consulte la sección 6.2.1.1).

6.3.1.2 Campo TypeImportance

El campo TypeImportance se ajustará a la definición proporcionada en la plantilla DirectoryEntry genérica (consulte la sección 6.2.1.2).

6.3.1.2.1 Entradas críticas del directorio principal

Las entradas críticas del directorio principal contienen información que es fundamental para la administración adecuada de un volumen exFAT. Solo el directorio raíz contiene entradas críticas del directorio principal (las entradas del directorio de archivos son una excepción, vea sección 7.4).

La definición de entradas críticas del directorio principal se correlaciona con el número de revisión de exFAT principal. Las implementaciones admitirán todas las entradas críticas del directorio principal y solo registrarán las estructuras críticas de entrada de directorio principal que defina esta especificación.

6.3.1.2.2 Entradas de directorio primario benigno

Las entradas de directorio principal benignas contienen información adicional que puede ser útil para administrar un volumen exFAT. Cualquier directorio puede contener entradas de directorio principal benignas.

La definición de entradas de directorio principal benignas se correlaciona con el número de revisión exFAT secundario. La compatibilidad con cualquier entrada de directorio principal benigna de esta especificación, o cualquier especificación posterior, define es opcional. Una entrada de directorio principal benigna no reconocida representa toda la entrada de directorio establecida como no reconocida (más allá de la definición de las plantillas de entrada de directorio aplicables).

6.3.1.3 Campo TypeCategory

El campo TypeCategory se ajustará a la definición proporcionada en la plantilla DirectoryEntry genérica (consulte la sección 6.2.1.3).

Para esta plantilla, el valor válido para este campo será 0.

6.3.1.4 InUse field

El campo InUse se ajustará a la definición proporcionada en la plantilla DirectoryEntry genérica (consulte la sección 6.2.1.4).

6.3.2 Campo SecondaryCount

El campo SecondaryCount describirá el número de entradas del directorio secundario que siguen inmediatamente a la entrada de directorio principal especificada. Estas entradas de directorio secundario, junto con la entrada de directorio principal especificada, componen el conjunto de entradas de directorio.

El intervalo válido de valores para este campo será:

  • Al menos 0, lo que significa que esta entrada de directorio principal es la única entrada del conjunto de entradas de directorio.

  • Como máximo 255, lo que significa que las siguientes 255 entradas de directorio y esta entrada de directorio principal componen el conjunto de entradas de directorio.

Las estructuras críticas de entrada de directorio principal que derivan de esta plantilla pueden redefinir los campos SecondaryCount y SetChecksum.

6.3.3 Campo SetChecksum

El campo SetChecksum contendrá la suma de comprobación de todas las entradas de directorio del conjunto de entradas de directorio especificado. Sin embargo, la suma de comprobación excluye este campo (vea la figura 2). Las implementaciones comprobarán que el contenido de este campo es válido antes de usar cualquier otra entrada de directorio en el conjunto de entradas de directorio especificado.

Las estructuras críticas de entrada de directorio principal que derivan de esta plantilla pueden redefinir los campos SecondaryCount y SetChecksum.

Figura 2 Cálculo de 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

El campo GeneralPrimaryFlags contiene marcas (vea la tabla 17).

Las estructuras críticas de entrada de directorio principal que derivan de esta plantilla pueden redefinir este campo.

Tabla 17 Estructura de campo GeneralPrimaryFlags genérica

Nombre del campo

Offset

(bit)

Tamaño

(bits)

Comentarios
AllocationPossible 0 1 Este campo es obligatorio y la sección 6.3.4.1 define su contenido.
NoFatChain 1 1 Este campo es obligatorio y la sección 6.3.4.2 define su contenido.
CustomDefined 2 14 Este campo es obligatorio y las estructuras que derivan de esta plantilla pueden definir este campo.
6.3.4.1 Campo AllocationPossible

El campo AllocationPossible describirá si es posible o no una asignación en el montón de clústeres para la entrada de directorio especificada.

Los valores válidos para este campo serán:

  • 0, lo que significa que una asignación asociada de clústeres no es posible y los campos FirstCluster y DataLength son realmente indefinidos (las estructuras que derivan de esta plantilla pueden redefinir esos campos).

  • 1, lo que significa que es posible una asignación asociada de clústeres y los campos FirstCluster y DataLength son los definidos

6.3.4.2 Campo NoFatChain

El campo NoFatChain indicará si el FAT activo describe o no la cadena de clústeres de la asignación especificada.

Los valores válidos para este campo serán:

  • 0, lo que significa que las entradas FAT correspondientes para la cadena de clústeres de la asignación son válidas y las implementaciones las interpretarán; si el campo AllocationPossible contiene el valor 0, o si el campo AllocationPossible contiene el valor 1 y el campo FirstCluster contiene el valor 0, el único valor válido de este campo es 0.

  • 1, lo que significa que la asignación asociada es una serie contigua de clústeres; las entradas FAT correspondientes para los clústeres no son válidas y las implementaciones no las interpretarán; las implementaciones pueden usar la siguiente ecuación para calcular el tamaño de la asignación asociada: DataLength / (2SectoresPerClusterShift* 2BytesPerSectorShift) redondeado al entero más cercano

Si las estructuras de entrada de directorio principal críticas que derivan de esta plantilla vuelven a definir el campo GeneralPrimaryFlags, las entradas FAT correspondientes para cualquier cadena de clústeres de asignación asociada son válidas.

6.3.5 FirstCluster Field

El campo FirstCluster se ajustará a la definición proporcionada en la plantilla DirectoryEntry genérica (consulte la sección 6.2.2).

Si el bit NoFatChain es 1, FirstCluster debe apuntar a un clúster válido en el montón del clúster.

Las estructuras críticas de entrada de directorio principal que derivan de esta plantilla pueden redefinir los campos FirstCluster y DataLength. Otras estructuras que derivan de esta plantilla pueden redefinir los campos FirstCluster y DataLength solo si el campo AllocationPossible contiene el valor 0.

6.3.6 Campo DataLength

El campo DataLength se ajustará a la definición proporcionada en la plantilla DirectoryEntry genérica (consulte la sección 6.2.3).

Si el bit NoFatChain es 1, DataLength no debe ser cero. Si el campo FirstCluster es cero, DataLength también debe ser cero.

Las estructuras críticas de entrada de directorio principal que derivan de esta plantilla pueden redefinir los campos FirstCluster y DataLength. Otras estructuras que derivan de esta plantilla pueden redefinir los campos FirstCluster y DataLength solo si el campo AllocationPossible contiene el valor 0.

6.4 Plantilla de directorio secundario genéricoEntry

El propósito central de las entradas de directorio secundario es proporcionar información adicional sobre un conjunto de entradas de directorio. La capacidad de interpretar la plantilla Generic Secondary DirectoryEntry es obligatoria.

La definición de entradas de directorio secundaria críticas e benignas se correlaciona con el número de revisión exFAT secundario. La compatibilidad con cualquier entrada crítica o benigna de directorio secundario esta especificación, o especificaciones posteriores, define es opcional.

Todas las estructuras de entrada de directorio secundario derivan de la plantilla Generic Secondary DirectoryEntry (consulte la tabla 18), que se deriva de la plantilla Generic DirectoryEntry (consulte la sección 6.2).

Tabla 18 Directorio secundario genérico Template

Nombre del campo

Offset

(byte)

Tamaño

(byte)

Comentarios
EntryType 0 1 Este campo es obligatorio y la sección 6.4.1 define su contenido.
GeneralSecondaryFlags 1 1 Este campo es obligatorio y la sección 6.4.2 define su contenido.
CustomDefined 2 18 Este campo es obligatorio y las estructuras que derivan de esta plantilla definen su contenido.
FirstCluster 20 4 Este campo es obligatorio y la sección 6.4.3 define su contenido.
DataLength 24 8 Este campo es obligatorio y la sección 6.4.4 define su contenido.

6.4.1 Campo EntryType

El campo EntryType se ajustará a la definición proporcionada en la plantilla DirectoryEntry genérica (consulte la sección 6.2.1).

Campo TypeCode 6.4.1.1

El campo TypeCode se ajustará a la definición proporcionada en la plantilla DirectoryEntry genérica (consulte la sección 6.2.1.1).

6.4.1.2 TypeImportance Field

El campo TypeImportance se ajustará a la definición proporcionada en la plantilla DirectoryEntry genérica (consulte la sección 6.2.1.2).

6.4.1.2.1 Entradas críticas del directorio secundario

Las entradas críticas del directorio secundario contienen información que es fundamental para la administración adecuada de su conjunto de entradas de directorio contenedor. Aunque la compatibilidad con cualquier entrada de directorio secundaria crítica específica es opcional, una entrada de directorio crítica no reconocida representa todo el conjunto de entradas de directorio como no reconocido (más allá de la definición de las plantillas de entrada de directorio aplicables).

Sin embargo, si un conjunto de entradas de directorio contiene al menos una entrada de directorio secundaria crítica que no reconoce una implementación, la implementación interpretará como máximo las plantillas de las entradas de directorio del conjunto de entradas de directorio y no los datos asociados a ninguna entrada de directorio del conjunto de entradas de directorio contienen (las entradas de directorio de archivos son una excepción, consulte la sección 7.4).

6.4.1.2.2 Entradas benignas del directorio secundario

Las entradas benignas del directorio secundario contienen información adicional que puede resultar útil para administrar su conjunto de entradas de directorio contenedor. La compatibilidad con cualquier entrada de directorio secundaria benigna específica es opcional. Las entradas de directorio secundario benignas no reconocidas no representan todo el conjunto de entradas de directorio como no reconocidas.

Las implementaciones pueden omitir cualquier entrada secundaria benigna que no reconozca.

6.4.1.3 Campo TypeCategory

El campo TypeCategory se ajustará a la definición proporcionada en la plantilla DirectoryEntry genérico (consulte la sección 6.2.1.3).

Para esta plantilla, el valor válido para este campo es 1.

6.4.1.4 InUse field

El campo InUse se ajustará a la definición proporcionada en la plantilla DirectoryEntry genérica (consulte la sección 6.2.1.4).

6.4.2 Campo GeneralSecondaryFlags

El campo GeneralSecondaryFlags contiene marcas (vea la tabla 19).

Tabla 19 General GenéricoSecondaryFlags (estructura de campo)

Nombre del campo

Offset

(bit)

Tamaño

(bits)

Comentarios
AllocationPossible 0 1 Este campo es obligatorio y la sección 6.4.2.1 define su contenido.
NoFatChain 1 1 Este campo es obligatorio y la sección 6.4.2.2 define su contenido.
CustomDefined 2 6 Este campo es obligatorio y las estructuras que derivan de esta plantilla pueden definir este campo.
6.4.2.1 Campo AllocationPossible

El campo AllocationPossible tendrá la misma definición que el mismo campo con nombre en la plantilla Directorio principal genéricoEntry (vea la sección 6.3.4.1).

6.4.2.2 Campo NoFatChain

El campo NoFatChain tendrá la misma definición que el mismo campo con nombre en la plantilla Directorio principal genéricoEntry (consulte la sección 6.3.4.2).

6.4.3 FirstCluster Field

El campo FirstCluster se ajustará a la definición proporcionada en la plantilla DirectoryEntry genérica (consulte la sección 6.2.2).

Si el bit NoFatChain es 1, FirstCluster debe apuntar a un clúster válido en el montón del clúster.

6.4.4 Campo DataLength

El campo DataLength se ajustará a la definición proporcionada en la plantilla DirectoryEntry genérica (consulte la sección 6.2.3).

Si el bit NoFatChain es 1, DataLength no debe ser cero. Si el campo FirstCluster es cero, DataLength también debe ser cero.

7 Definiciones de entrada de directorio

La revisión 1.00 del sistema de archivos exFAT define las siguientes entradas de directorio:

7.1 Entrada de directorio de mapa de bits de asignación

En el sistema de archivos exFAT, un FAT no describe el estado de asignación de clústeres; en su lugar, lo hace un mapa de bits de asignación. Los mapas de bits de asignación existen en el montón de clústeres (consulte la sección 7.1.5) y tienen entradas de directorio principal críticas correspondientes en el directorio raíz (consulte la tabla 20).

El campo NumberOfFats determina el número de entradas de directorio de mapa de bits de asignación válidas en el directorio raíz. Si el campo NumberOfFats contiene el valor 1, el único número válido de entradas del directorio mapa de bits de asignación es 1. Además, la entrada del directorio Mapa de bits de asignación solo es válida si describe el mapa de bits de primera asignación (vea la sección 7.1.2.1). Si el campo NumberOfFats contiene el valor 2, el único número válido de entradas del directorio mapa de bits de asignación es 2. Además, las dos entradas del directorio mapa de bits de asignación solo son válidas si se describe el mapa de bits de primera asignación y el otro se describe el mapa de bits de asignación segundo.

Tabla 20 Estructura DirectoryEntry de mapa de bits de asignación

Nombre del campo

Offset

(byte)

Tamaño

(byte)

Comentarios
EntryType 0 1 Este campo es obligatorio y la sección 7.1.1 define su contenido.
BitmapFlags 1 1 Este campo es obligatorio y la sección 7.1.2 define su contenido.
Reservado 2 18 Este campo es obligatorio y su contenido está reservado.
FirstCluster 20 4 Este campo es obligatorio y la sección 7.1.3 define su contenido.
DataLength 24 8 Este campo es obligatorio y la sección 7.1.4 define su contenido.

7.1.1 Campo EntryType

El campo EntryType se ajustará a la definición proporcionada en la plantilla Directorio principal genéricoEntry (consulte la sección 6.3.1).

Campo TypeCode 7.1.1.1

El campo TypeCode se ajustará a la definición proporcionada en la plantilla Directorio principal genéricoEntry (consulte la sección 6.3.1.1).

Para una entrada de directorio mapa de bits de asignación, el valor válido para este campo es 1.

7.1.1.2 Campo TypeImportance

El campo TypeImportance se ajustará a la definición proporcionada en la plantilla Directorio principal genéricoEntry (consulte la sección 6.3.1.2).

Para una entrada de directorio mapa de bits de asignación, el valor válido para este campo es 0.

7.1.1.3 Campo TypeCategory

El campo TypeCategory se ajustará a la definición proporcionada en la plantilla Directorio principal genéricoEntry (consulte la sección 6.3.1.3).

7.1.1.4 Campo InUse

El campo InUse se ajustará a la definición proporcionada en la plantilla Directorio principal genéricoEntry (consulte la sección 6.3.1.4).

Campo BitmapFlags 7.1.2

El campo BitmapFlags contiene marcas (vea la tabla 21).

Tabla 21 Estructura de campo BitmapFlags

Nombre del campo

Offset

(bit)

Tamaño

(bits)

Comentarios
BitmapIdentifier 0 1 Este campo es obligatorio y la sección 7.1.2.1 define su contenido.
Reservado 1 7 Este campo es obligatorio y su contenido está reservado.
7.1.2.1 Campo BitmapIdentifier

El campo BitmapIdentifier indicará qué mapa de bits de asignación describe la entrada de directorio especificada. Las implementaciones usarán el mapa de bits de primera asignación junto con la Primera FAT y utilizarán el mapa de bits de segunda asignación junto con la Segunda FAT. El campo ActiveFat describe qué mapa de bits de asignación y FAT están activos.

Los valores válidos para este campo serán:

  • 0, lo que significa que la entrada de directorio especificada describe el mapa de bits de primera asignación

  • 1, lo que significa que la entrada de directorio especificada describe el mapa de bits de segunda asignación y solo es posible cuando NumberOfFats contiene el valor 2.

7.1.3 Campo FirstCluster

El campo FirstCluster se ajustará a la definición proporcionada en la plantilla Directorio principal genéricoEntry (consulte la sección 6.3.5).

Este campo contiene el índice del primer clúster de la cadena de clústeres, como se describe en FAT, que hospeda el mapa de bits de asignación.

7.1.4 Campo DataLength

El campo DataCluster se ajustará a la definición proporcionada en la plantilla Directorio principal genéricoEntry (consulte la sección 6.3.6).

Mapa de bits de asignación 7.1.5

Un mapa de bits de asignación registra el estado de asignación de los clústeres en el montón de clústeres. Cada bit de un mapa de bits de asignación indica si su clúster correspondiente está disponible para la asignación o no.

Un mapa de bits de asignación representa clústeres del índice más bajo al más alto (consulte la tabla 22). Por motivos históricos, el primer clúster tiene el índice 2. Nota: el primer bit del mapa de bits es el bit de orden más bajo del primer byte.

Tabla 22 Estructura de mapa de bits de asignación

Nombre del campo

Offset

(bit)

Tamaño

(bits)

Comentarios
BitmapEntry[2] 0 1 Este campo es obligatorio y la sección 7.1.5.1 define su contenido.

.

.

.

.

.

.

.

.

.

.

.

.

BitmapEntry[ClusterCount+1] ClusterCount: 1 1

Este campo es obligatorio y la sección 7.1.5.1 define su contenido.

Nota: los sectores principal y de arranque de copia de seguridad contienen el campo ClusterCount.

Reservado ClusterCount (DataLength * 8): ClusterCount

Este campo es obligatorio y su contenido, si existe, están reservados.

Nota: los sectores principal y de arranque de copia de seguridad contienen el campo ClusterCount.

7.1.5.1 BitmapEntry[2] ... BitmapEntry[ClusterCount+1] Campos

Cada campo BitmapEntry de esta matriz representa un clúster en el montón de clústeres. BitmapEntry[2] representa el primer clúster del montón de clústeres y BitmapEntry[ClusterCount+1] representa el último clúster del montón del clúster.

Los valores válidos para estos campos serán:

  • 0, que describe el clúster correspondiente como disponible para la asignación

  • 1, que describe el clúster correspondiente como no disponible para la asignación (es posible que una asignación de clúster ya consuma el clúster correspondiente o el FAT activo pueda describir el clúster correspondiente como incorrecto)

7.2 Entrada de directorio de tabla de mayúsculas y minúsculas

La tabla de mayúsculas y minúsculas define la conversión de minúsculas a caracteres mayúsculas. Esto es importante debido a que la entrada del directorio Nombre de archivo (consulte la sección 7.7) con caracteres Unicode y el sistema de archivos exFAT no distingue mayúsculas de minúsculas y conserva mayúsculas de minúsculas. La tabla de mayúsculas y minúsculas existe en el montón de clústeres (consulte la sección 7.2.5) y tiene una entrada de directorio principal crítica correspondiente en el directorio raíz (consulte la tabla 23). El número válido de entradas del directorio Tabla mayúsculas y minúsculas es 1.

Debido a la relación entre los nombres de archivo y tabla de mayúsculas y minúsculas, las implementaciones no deben modificar la tabla de mayúsculas y minúsculas, excepto como resultado de las operaciones de formato.

Tabla 23 Estructura de directorio de tabla de mayúsculas y minúsculas

Nombre del campo

Offset

(byte)

Tamaño

(byte)

Comentarios
EntryType 0 1 Este campo es obligatorio y la sección 7.2.1 define su contenido.
Reserved1 1 3 Este campo es obligatorio y su contenido está reservado.
TableChecksum 4 4 Este campo es obligatorio y la sección 7.2.2 define su contenido.
Reserved2 8 12 Este campo es obligatorio y su contenido está reservado.
FirstCluster 20 4 Este campo es obligatorio y la sección 7.2.3 define su contenido.
DataLength 24 8 Este campo es obligatorio y la sección 7.2.4 define su contenido.

Campo EntryType 7.2.1

El campo EntryType se ajustará a la definición proporcionada en la plantilla Directorio principal genéricoEntry (consulte la sección 6.3.1).

Campo TypeCode 7.2.1.1

El campo TypeCode se ajustará a la definición proporcionada en la plantilla Directorio principal genéricoEntry (consulte la sección 6.3.1.1).

Para la entrada del directorio Tabla mayúsculas y minúsculas, el valor válido para este campo es 2.

7.2.1.2 Campo TypeImportance

El campo TypeImportance se ajustará a la definición proporcionada en la plantilla Directorio principal genéricoEntry (consulte la sección 6.3.1.2).

Para la entrada del directorio Tabla mayúsculas y minúsculas, el valor válido para este campo es 0.

7.2.1.3 Campo TypeCategory

El campo TypeCategory se ajustará a la definición proporcionada en la plantilla Directorio principal genéricoEntry (consulte la sección 6.3.1.3).

7.2.1.4 Campo InUse

El campo InUse se ajustará a la definición proporcionada en la plantilla Directorio principal genéricoEntry (consulte la sección 6.3.1.4).

7.2.2 Campo TableChecksum

El campo TableChecksum contiene la suma de comprobación de la tabla de mayúsculas y minúsculas (que describen los campos FirstCluster y DataLength). Las implementaciones comprobarán que el contenido de este campo es válido antes de usar la tabla de mayúsculas y minúsculas.

Figura 3 Cálculo de tableChecksum

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

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

    return Checksum;
}

7.2.3 Campo FirstCluster

El campo FirstCluster se ajustará a la definición proporcionada en la plantilla Directorio principal genéricoEntry (consulte la sección 6.3.5).

Este campo contiene el índice del primer clúster de la cadena de clústeres, como se describe en FAT, que hospeda la tabla de mayúsculas y minúsculas.

7.2.4 Campo DataLength

El campo DataCluster se ajustará a la definición proporcionada en la plantilla Directorio principal genéricoEntry (consulte la sección 6.3.6).

7.2.5 Tabla de mayúsculas y minúsculas

Una tabla de mayúsculas y minúsculas es una serie de asignaciones de caracteres Unicode. Una asignación de caracteres consta de un campo de 2 bytes, con el índice del campo en la tabla de mayúsculas y minúsculas que representa el carácter Unicode que se va a agregar y el campo de 2 bytes que representa el carácter Unicode en mayúsculas y minúsculas.

Los primeros 128 caracteres Unicode tienen asignaciones obligatorias (consulte la tabla 24). Una tabla de mayúsculas y minúsculas que tiene cualquier otra asignación de caracteres para cualquiera de los primeros 128 caracteres Unicode no es válida.

Las implementaciones que solo admiten caracteres del intervalo de asignación obligatorio pueden omitir las asignaciones del resto de la tabla de mayúsculas y minúsculas. Dichas implementaciones solo usarán caracteres del intervalo de asignación obligatorio al crear o cambiar el nombre de los archivos (a través de la entrada del directorio Nombre de archivo, consulte la sección 7.7). Cuando se apliquen mayúsculas y minúsculas a los nombres de archivo existentes, estas implementaciones no incluirán caracteres en mayúsculas y minúsculas del intervalo de asignación no obligatorio, pero los dejará intactos en el nombre de archivo en mayúsculas y minúsculas resultante (esto es una mayúscula y minúscula parcial). Al comparar nombres de archivo, estas implementaciones tratarán los nombres de archivo que difieren del nombre en comparación solo por caracteres Unicode del intervalo de asignación no obligatorio como equivalente. Aunque estos nombres de archivo solo son potencialmente equivalentes, estas implementaciones no pueden garantizar que el nombre de archivo totalmente en mayúsculas y minúsculas no entre en conflicto con el nombre en comparación.

Tabla 24 Entradas obligatorias de la tabla 128 mayúsculas y minúsculas

Índice de tabla + 0 + 1 + 2 + 3 + 4 + 5 + 6 + 7
0000h 0000h 0001h 0002h 0003h 0004h 0005h 0006h 0007h
0008h 0008h 0009h 000Ah 000Bh 000Ch 000Dh 000Eh 000Fh
0010h 0010h 0011h 0012h 0013h 0014h 0015h 0016h 0017h
0018h 0018h 0019h 001Ah 001Bh 001Ch 001Dh 001Eh 001Fh
0020h 0020h 0021h 0022h 0023h 0024h 0025h 0026h 0027h
0028h 0028h 0029h 002Ah 002Bh 002Ch 002Dh 002Eh 002Fh
0030h 0030h 0031h 0032h 0033h 0034h 0035h 0036h 0037h
0038h 0038h 0039h 003Ah 003Bh 003Ch 003Dh 003Eh 003Fh
0040h 0040h 0041h 0042h 0043h 0044h 0045h 0046h 0047h
0048h 0048h 0049h 004Ah 004Bh 004Ch 004Dh 004Eh 004Fh
0050h 0050h 0051h 0052h 0053h 0054h 0055h 0056h 0057h
0058h 0058h 0059h 005Ah 005Bh 005Ch 005Dh 005Eh 005Fh
0060h 0060h 0041h 0042h 0043h 0044h 0045h 0046h 0047h
0068h 0048h 0049h 004Ah 004Bh 004Ch 004Dh 004Eh 004Fh
0070h 0050h 0051h 0052h 0053h 0054h 0055h 0056h 0057h
0078h 0058h 0059h 005Ah 007Bh 007Ch 007Dh 007Eh 007Fh

(Nota: las entradas con asignaciones de mayúsculas y minúsculas que no son de identidad están en negrita)

Al dar formato a un volumen, las implementaciones pueden generar una tabla de mayúsculas y minúsculas en un formato comprimido mediante la compresión de asignación de identidades, ya que una gran parte del espacio de caracteres Unicode no tiene ningún concepto de caso (lo que significa que los caracteres "minúsculas" y "mayúsculas" son equivalentes). Las implementaciones comprimen una tabla de mayúsculas y minúsculas mediante la representación de una serie de asignaciones de identidad con el valor FFFFh seguido del número de asignaciones de identidad.

Por ejemplo, una implementación puede representar las primeras asignaciones de caracteres de 100 (64h) con las ocho entradas siguientes de una tabla de mayúsculas y minúsculas comprimidas:

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

Las dos primeras entradas indican que los primeros 97 (61h) caracteres (de 0000h a 0060h) tienen asignaciones de identidad. Los caracteres siguientes, de 0061h a 0063h, se asignan a los caracteres 0041h a 0043h, respectivamente.

La capacidad de proporcionar una tabla de mayúsculas y minúsculas comprimida al dar formato a un volumen es opcional. Sin embargo, la capacidad de interpretar una tabla de mayúsculas y minúsculas sin comprimir es obligatoria. El valor del campo TableChecksum siempre se ajusta a cómo existe la tabla de mayúsculas y minúsculas en el volumen, que puede estar en formato comprimido o sin comprimir.

Al dar formato a un volumen, las implementaciones deben registrar la tabla de mayúsculas y minúsculas recomendada en formato comprimido (consulte la tabla 25), para la que el valor del campo TableChecksum es E619D30Dh.

Si una implementación define su propia tabla de mayúsculas y minúsculas, ya sea comprimida o sin comprimir, esa tabla abarcará el intervalo de caracteres Unicode completo (de códigos de caracteres de 0000h a FFFFh inclusivo).