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 central (vea la lista siguiente).

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

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

  2. Habilitar archivos de gran tamaño y dispositivos de almacenamiento.

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

  3. Incorpore la extensibilidad para futuras innovaciones.

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

1,2 terminología específica

En el contexto de esta especificación, ciertos términos (vea la tabla 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 llevan un significado muy específico

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

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

  1. Se inicializará en cero y no debe usarse para ningún propósito

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

  3. Conservará las operaciones que modifican campos o estructuras circundantes.

1,3 texto completo de acrónimos comunes

Esta especificación usa acrónimos de uso común en el sector del equipo 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 de asignación de archivos extensible
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 de transacciones seguras
UTC Hora universal coordinada

1,4 calificadores de campo y estructura predeterminados

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

  1. Sin signo

  2. Usar notación decimal para describir valores, donde no se indica de otro modo; Esta especificación usa la letra "h" posterior a la corrección para denotar números hexadecimales y agrega GUID entre llaves

  3. Están en formato Little-endian

  4. No se 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 la semántica operativa con seguridad de las transacciones en la parte superior del sistema de archivos base. Windows CE usa TexFAT. TexFAT requiere el uso de las dos grasas y mapas de bits de asignación para su uso en transacciones. También define varias estructuras adicionales, entre las que se incluyen los descriptores de relleno y los 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 (vea la tabla 3).

Tabla 3 estructura de volumen

Nombre de la subregión

Offset

organismos

Tamaño

sector

Comentarios
Región de arranque principal
Sector de arranque principal 0 1 Esta subregión es obligatoria y la sección 3,1 define su contenido.
Sectores principales de arranque extendidos 1 8 Esta subregión es obligatoria y la sección 3,2) define su contenido.
Parámetros principales del OEM 9 1 Esta subregión es obligatoria y la sección 3,3 define su contenido.
Principal reservado 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 extendidos 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 backup boot 23 1 Esta subregión es obligatoria y la sección 3,4 define su contenido.
Región FAT
Alineación de 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.

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

Segunda 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 del clúster 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, * 2SectorsPerClusterShift

Esta subregión es obligatoria y la sección 5,1 define su contenido.

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

Exceso de espacio ClusterHeapOffset + Clustercount, * 2SectorsPerClusterShift VolumeLength – (ClusterHeapOffset + Clustercount, * 2SectorsPerClusterShift)

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 ClusterHeapOffset, Clustercount,, SectorsPerClusterShift y VolumeLength.

3 regiones de arranque principales y de copia de seguridad

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

  1. Arranque: Sujete un equipo desde un volumen exFAT.

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

  3. Detecta 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 recuperar el 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 para el arranque, las implementaciones no deben modificar el contenido de la región de arranque de copia de seguridad.

3,1 subregiones del sector de arranque principal y de copia de seguridad

El sector de arranque principal contiene código para el arranque desde un volumen de exFAT y parámetros básicos de exFAT que describen la estructura del volumen (vea la tabla 4). BIOS, MBR u otros agentes de programa previo de arranque pueden inspeccionar este sector y cargar y ejecutar las instrucciones de arranque que contiene.

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

Antes de usar el contenido del sector de arranque principal o de copia de seguridad, las implementaciones comprobarán su contenido mediante la validación de la suma de comprobación de arranque correspondiente y la garantía de que todos los campos estén dentro de su intervalo de valores válido.

Mientras que la operación de formato 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 correspondiente suma de comprobación de arranque) según sea necesario. Sin embargo, las implementaciones pueden actualizar los campos VolumeFlags o PercentInUse sin actualizar su correspondiente suma de comprobación de arranque (la suma de comprobación excluye específicamente estos dos campos).

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

Nombre del campo

Offset

bytes

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.
SectorsPerClusterShift 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.
Arranque 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á definido.

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

3.1.1 JumpBoot campo

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

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

3.1.2 campo FileSystemName

El campo FileSystemName debe contener el nombre del sistema de archivos del volumen.

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

3.1.3 campo MustBeZero

El campo MustBeZero se corresponderá directamente con el intervalo de bytes que consume el bloque de parámetros BIOS empaquetados en los volúmenes FAT12/16/32.

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

3.1.4 campo PartitionOffset

El campo PartitionOffset debe describir el desplazamiento del sector relativo al medio de la partición que hospeda el volumen exFAT determinado. Este campo ayuda con el arranque desde el volumen mediante el uso extendido de INT 13h en equipos personales.

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

3.1.5 VolumeLength

El campo VolumeLength debe describir el tamaño del volumen de exFAT determinado en sectores.

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

  • Al menos 220/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 sobrante es 0, el valor de este campo es ClusterHeapOffset + (232-11) * 2SectorsPerClusterShift.

3.1.6 FatOffset

El campo FatOffset debe describir el desplazamiento de sector relativo al volumen de la primera FAT. Este campo permite que las implementaciones alineen la primera FAT con las características de los medios de almacenamiento subyacentes.

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

  • Al menos 24, que tiene en cuenta los sectores que consumen las regiones de arranque principales y 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 FatLength

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

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

  • Al menos (Clustercount, + 2) * 22/2BytesPerSectorShiftredondeado al entero más próximo, lo que garantiza que cada FAT tenga espacio suficiente para describir todos los clústeres del montón del clúster

  • Como máximo (ClusterHeapOffset-FatOffset)/NumberOfFats redondeado al entero más próximo, lo que garantiza que las grasas existen antes que el montón del clúster.

Este campo puede contener un valor que supere el límite inferior (como se describió anteriormente) para permitir que la segunda FAT, si está presente, se alinee también con las características de los medios de almacenamiento subyacentes. El contenido del espacio que supera lo que el propio elemento FAT requiere, si existe, no está definido.

3.1.8 ClusterHeapOffset

El campo ClusterHeapOffset debe describir el desplazamiento de sector relativo al volumen del montón del clúster. Este campo permite que las implementaciones alineen el montón del clúster con las características de los medios de almacenamiento subyacentes.

El intervalo válido de valores para este campo debe 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, * 2SectorsPerClusterShift), lo que sea menor

3.1.9 Clustercount,

El campo Clustercount, debe describir el número de clústeres que contiene el montón de clústeres.

El valor válido para este campo debe ser el menor de los siguientes:

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

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

El valor del campo Clustercount, determina el tamaño mínimo de una FAT. Para evitar las grasas muy grandes, las implementaciones pueden controlar el número de clústeres en el montón del clúster aumentando el tamaño del clúster (a través del campo SectorsPerClusterShift). Esta especificación recomienda no tener más dedosclústeres en el montón de clústeres. Sin embargo, las implementaciones deben ser capaces de controlar volúmenes con hasta 2 clústeres32-11 en el montón del clúster.

3.1.10 FirstClusterOfRootDirectory

El campo FirstClusterOfRootDirectory debe contener el índice de clúster del primer clúster del directorio raíz. Las implementaciones deben hacer todo lo posible para colocar el primer clúster del directorio raíz en el primer clúster no incorrecto después de que los clústeres consuman el mapa de bits de asignación y la tabla de casos de uso.

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

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

  • Como máximo Clustercount, + 1, el índice del último clúster en el montón del clúster

3.1.11 VolumeSerialNumber

El campo VolumeSerialNumber debe contener un número de serie único. Esto ayuda a las implementaciones a distinguir entre distintos volúmenes de exFAT. Las implementaciones deben generar el número de serie combinando la fecha y hora de formato del volumen exFAT. El mecanismo de combinación de fecha y 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 FileSystemRevision

El campo FileSystemRevision debe describir los números de revisión principales y secundarios 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 inferior es el número de revisión secundaria. Por ejemplo, si el byte de orden superior contiene el valor 01h y si el byte de orden inferior 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 inferior 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 debe ser:

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

  • Como máximo 99 para el byte de orden inferior 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 de exFAT con la revisión principal número 1 y no debe montar ningún volumen exFAT con cualquier otro número de revisión principal. Las implementaciones respetarán el número de revisión menor y no realizarán operaciones ni creará ninguna estructura del sistema de archivos que no se haya descrito en la especificación correspondiente del número de revisión secundaria.

3.1.13 VolumeFlags

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

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

Tabla 5 VolumeFlags estructura de campo

Nombre del campo

Offset

poco

Tamaño

parada

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 ActiveFat

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

  • 0, que significa que el primer mapa de bits de la primera asignación y FAT están activos

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

Las implementaciones considerarán la FAT inactiva y el mapa de bits de asignación como obsoletos. Solo las implementaciones compatibles con TexFAT conmutarán los mapas de bits activos de FAT y de asignación (consulte la sección 7,1).

3.1.13.2 VolumeDirty

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

  • 0, 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 en los metadatos del sistema de archivos que no se resuelven. Si, al montar un volumen, el valor de este campo es 1, solo las implementaciones que resuelvan incoherencias en los metadatos del sistema de archivos pueden borrar el valor de este campo a 0. Estas implementaciones solo borrarán el valor de este campo a 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 a 0 después, de forma similar al orden de escritura recomendado descrito en la sección 8,1.

3.1.13.3 MediaFailure

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

  • 0, que significa que el medio de hospedaje no ha comunicado errores o que los errores conocidos ya se han registrado en la FAT como clústeres "incorrectos"

  • 1, lo que significa que el medio de hospedaje ha detectado errores (es decir, que se ha producido un error 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 de medios y registran todos los errores como clústeres "incorrectos" en la FAT (o que resuelven los errores de los medios) pueden borrar el valor de este campo a 0.

3.1.13.4 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 determinado

  • 1, lo que significa que las implementaciones deben desactivar este campo en 0 antes de modificar cualquier estructura, directorio o archivo del sistema de archivos

3.1.14 BytesPerSectorShift

El campo BytesPerSectorShift debe describir los bytes por sector expresado 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 debe ser:

  • Al menos 9 (tamaño de sector de 512 bytes), que es el sector más pequeño posible para un volumen de 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 SectorsPerClusterShift

El campo SectorsPerClusterShift debe 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 debe 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 NumberOfFats

El campo NumberOfFats debe describir el número de grasas y los mapas de bits de asignación que contiene el volumen.

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

  • 1, que indica que el volumen solo contiene el primer mapa de bits de la primera distribución y FAT

  • 2, que indica que el volumen contiene el primer mapa de bits FAT, segunda FAT, primera asignación y segundo mapa de bits de asignación; Este valor solo es válido para los volúmenes TexFAT

3.1.17 DriveSelect

El campo DriveSelect debe contener el número de unidad INT 13h extendido, que ayuda a partir de este volumen mediante el uso del INT.

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

3.1.18 PercentInUse

El campo PercentInUse debe describir el porcentaje de clústeres en el montón de clúster que se asignan.

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

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

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

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

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

3.1.19 campo de arranque

El campo de arranque debe contener instrucciones 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 para el arranque inicializarán cada byte de este campo en F4h (la instrucción Halt para las CPU comunes en los equipos personales) como parte de la operación de formato.

3.1.20 BootSignature

El campo BootSignature debe describir si el propósito 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 sector de arranque respectivo. Las implementaciones deben comprobar el contenido de este campo antes de depender de cualquier otro campo en el sector de arranque respectivo.

3,2 subregiones de sectores de arranque principales y de copia de seguridad

Cada sector de los sectores de arranque extendidos principales tiene la misma estructura. sin embargo, cada sector puede contener instrucciones diferentes para el arranque (vea la tabla 6). Los agentes de arranque previo, como las instrucciones para el arranque en el sector de arranque principal, las implementaciones de BIOS alternativas 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 sectores de arranque extendidos principales y tienen la misma estructura (vea la tabla 6).

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

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

Tabla 6 estructura del sector de arranque extendido

Nombre del campo

Offset

bytes

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 para el 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 para el arranque inicializarán cada byte de este campo a 00H como parte de la operación de formato.

3.2.2 campo ExtendedBootSignature

El campo ExtendedBootSignature debe describir si el objetivo 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 sus respectivos sectores de arranque principal o de copia de seguridad extendidos. Las implementaciones deben comprobar el contenido de este campo antes de depender de cualquier otro campo en el sector de arranque extendido correspondiente.

subregiones 3,3 principales y de copia de seguridad de parámetros OEM

La subregión principal de parámetros de OEM contiene diez estructuras de parámetros que pueden contener información específica del fabricante (vea la Tabla 7). Cada una de las diez estructuras de parámetros deriva de la plantilla de 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 de parámetros genéricos. Esta especificación define dos estructuras de parámetros: parámetros null (vea la sección 3.3.3) y parámetros de 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 del OEM y tienen la misma estructura (vea la Tabla 7).

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

Los fabricantes deben rellenar los parámetros principales y de copia de seguridad de OEM 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 principales y de copia de seguridad de OEM.

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

Tabla 7 estructura de parámetros OEM

Nombre del campo

Offset

bytes

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 de parámetros de esta matriz contiene una estructura de parámetros, que se deriva de la plantilla de parámetros genéricos (consulte la sección 3.3.2). Cualquier campo de parámetros no usados se describe como si contiene una estructura de parámetros null (vea la sección 3.3.3).

3.3.2 plantilla de parámetros genéricos

La plantilla de parámetros genéricos proporciona la definición base de una estructura de parámetros (vea 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 tabla 8

Nombre del campo

Offset

bytes

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 ParametersGuid

El campo ParametersGuid debe 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 a partir de esta plantilla.

3.3.3 parámetros null

La estructura de parámetros NULL se deriva de la plantilla de parámetros genéricos (consulte la sección 3.3.2) y describe un campo de parámetros no usados (vea la Tabla 9). Al crear o actualizar la estructura de parámetros OEM, las implementaciones deben rellenar los campos de parámetros no usados con la estructura de 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, con lo que se dejan todas las demás estructuras de parámetros al principio de la estructura de parámetros OEM.

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

Tabla 9 parámetros null (estructura)

Nombre del campo

Offset

bytes

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 ParametersGuid

El campo ParametersGuid debe ajustarse a la definición proporcionada por la plantilla de 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 de Flash

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

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

Tabla 10 parámetros de Flash (estructura)

Nombre del campo

Offset

bytes

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 de 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 ParametersGuid

El campo ParametersGuid debe ajustarse a la definición proporcionada en la plantilla de parámetros genéricos (consulte la sección 3.3.2.1).

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

3.3.4.2 EraseBlockSize

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

3.3.4.3 campo de paginación

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

3.3.4.4 SpareSectors

El campo SpareSectors debe describir el número de sectores que el medio Flash tiene disponible para las operaciones de reserva internas.

3.3.4.5 RandomAccessTime

El campo RandomAccessTime debe describir el tiempo promedio de acceso aleatorio del medio Flash, en nanosegundos.

3.3.4.6 ProgrammingTime

En el campo ProgrammingTime se describe el tiempo medio de programación del medio Flash, en nanosegundos.

3.3.4.7 ReadCycle

El campo ReadCycle debe describir el tiempo promedio de ciclo de lectura del medio Flash, en nanosegundos.

3.3.4.8 WriteCycle

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

3,4 subregiones de suma de comprobación de arranque principal y de copia de seguridad

Las sumas de comprobación principal y de arranque de copia de seguridad contienen un patrón de repetición de la suma de comprobación de cuatro bytes del contenido de todas las demás subregiones en sus regiones de arranque respectivas. El cálculo de la suma de comprobación no incluirá los campos VolumeFlags y PercentInUse en el sector de arranque correspondiente (vea la figura 1). El patrón de repetición de la suma de comprobación de cuatro bytes rellena la subregión de la 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 subregiones en las regiones de arranque principal o de copia de seguridad, las implementaciones comprobarán su contenido mediante la validación de la suma de comprobación de arranque correspondiente.

Mientras que la operación de formato inicial rellenará las sumas de comprobación principal y de copia de seguridad con el patrón de suma de comprobación repetido, 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 la 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 de tabla de asignación de archivos (FAT) puede contener hasta dos grasas, una en la primera subregión de FAT y otra en la subregión de FAT. El campo NumberOfFats describe cuántas grasas contiene esta región. Los valores válidos para el campo NumberOfFats son 1 y 2. Por lo tanto, la primera subregión de FAT siempre contiene una FAT. Si el campo NumberOfFats es dos, la segunda subregión FAT también contiene una FAT.

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

subregiones 4,1 primera y segunda FAT

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

Tabla 11 estructura de la tabla de asignación de archivos

Nombre del campo

Offset

bytes

Tamaño

bytes

Comentarios
FatEntry [0] 0 4 Este campo es obligatorio y la sección 4.1.2 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 [ campo FatEntry 0 ]

El [ campo FatEntry 0 ] debe describir el tipo de medio en el primer byte (byte de orden más bajo) y debe contener FFH en los tres bytes restantes.

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

campo 4.1.2 FatEntry [ 1 ]

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 usar este campo para ningún propósito. Las implementaciones no deben interpretar este campo y conservarán su contenido entre las operaciones que modifican los campos circundantes.

4.1.3 FatEntry [ 2 ] ... FatEntry [ clustercount, + 1 ]

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

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

  • Entre 2 y Clustercount, + 1, ambos incluidos, que señala a la siguiente FatEntry de la cadena de clúster especificada; el FatEntry determinado no debe apuntar a ningún FatEntry que lo preceda en la cadena de clúster especificada.

  • Exactamente FFFFFFF7h, que marca el clúster correspondiente del FatEntry determinado como "malo"

  • Exactamente FFFFFFFFh, que marca el clúster correspondiente del FatEntry determinado 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úster determinada.

5 regiones de datos

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

5,1 subregión del montón del clúster

La estructura del montón del clúster es muy simple (vea la tabla 12); cada serie consecutiva de sectores describe un clúster, tal y como se define en el campo SectorsPerClusterShift. Lo importante es que el primer clúster del montón del clúster tiene el índice dos, que se corresponde directamente con el índice de FatEntry [ 2 ] .

En un volumen de 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. Esta es una diferencia significativa de las predecesoras de exFAT (FAT12, FAT16 y FAT32), en las que una FAT mantiene 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 del clúster

Nombre del campo

Offset

organismos

Tamaño

sector

Comentarios
Clúster [2] ClusterHeapOffset 2SectorsPerClusterShift

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.

.

.

.

.

.

.

.

.

.

.

.

.

Clúster [Clustercount, + 1] ClusterHeapOffset + (Clustercount,-1) * 2SectorsPerClusterShift 2SectorsPerClusterShift

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 Clustercount,, ClusterHeapOffset y SectorsPerClusterShift.

5.1.1 Cluster [ 2 ] ... Campos de clustercount, de clúster [ + 1 ]

Cada campo de clúster 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 utiliza un enfoque de árbol de directorios para administrar las estructuras y los archivos del sistema de archivos que existen en el montón del clúster. Los directorios tienen una relación de uno a varios entre el elemento primario y el secundario 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 en un modo vinculado individualmente.

Cada directorio consta de una serie de entradas de directorio (vea 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

bytes

Tamaño

bytes

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úster que contiene el directorio dado, dividido por el tamaño de un campo DirectoryEntry, 32 bytes.

6,1 DirectoryEntry [ 0 ] ... DirectoryEntry [ N--1]

Cada campo DirectoryEntry de esta matriz se deriva de la plantilla DirectoryEntry genérica (consulte la sección 6,2).

6,2 plantilla DirectoryEntry genérica

La plantilla DirectoryEntry genérico proporciona la definición base para las entradas de directorio (vea la Tabla 14). Todas las estructuras de entradas de directorio se derivan de esta plantilla y solo son válidas las estructuras de entradas de directorio definidas por Microsoft (exFAT no tiene disposiciones para las estructuras de entradas de directorio definidas por el fabricante excepto según se define en la sección 7,8 y en la sección 7,9). La capacidad de interpretar la plantilla DirectoryEntry genérica es obligatoria.

Tabla 14 plantilla DirectoryEntry genérica

Nombre del campo

Offset

bytes

Tamaño

bytes

Comentarios
EntryType tal y 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 el campo de 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 siguientes condiciones:

    • El resto de campos del DirectoryEntry dado están realmente reservados

    • Todas las entradas de directorio subsiguientes en el 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 no utilizado y se aplican las condiciones siguientes:

    • El resto de campos del DirectoryEntry dado están realmente sin definir.

    • Las entradas de directorio no utilizadas solo son válidas fuera de los conjuntos de entradas de directorio

    • Las implementaciones pueden sobrescribir las entradas de directorio no utilizadas 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 normal 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 se corresponde directamente con el campo InUse (vea la sección 6.2.1.4) que contiene el valor 1.

Para evitar modificaciones en el campo InUse (consulte la sección 6.2.1.4) de forma errónea, lo que da como resultado un marcador de fin de directorio, el valor 80h no es válido.

Tabla 15 estructura de campo EntryType genérica

Nombre del campo

Offset

poco

Tamaño

parada

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

El campo TypeCode describe parcialmente el tipo específico de la entrada de directorio especificada. Este campo, más los campos TypeImportance y TypeCategory (vea la sección 6.2.1.2 y 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 TypeImportance

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

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

  • 0, lo que significa que la entrada de directorio dada es crítica (consulte la sección 6.3.1.2.1 y la sección 6.4.1.2.1 para ver las entradas críticas principales y críticas del directorio secundario, respectivamente)

  • 1, lo que significa que la entrada de directorio dada es benigna (consulte la sección 6.3.1.2.2 y la sección 6.4.1.2.2 para entradas de directorio secundario benignas y benignas, respectivamente)

6.2.1.3 TypeCategory

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

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

  • 0, 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 dada es secundaria (consulte la sección 6,4).

6.2.1.4 campo InUse

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

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

  • 0, que significa que la entrada de directorio especificada no está en uso. Esto significa que la estructura especificada realmente es una entrada de directorio no usada

  • 1, lo que significa que la entrada de directorio especificada está en uso. Esto significa que la estructura especificada es una entrada de directorio normal.

6.2.2 campo FirstCluster

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

El intervalo válido de valores para este campo debe 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 volver a definir los campos FirstCluster y DATALENGTH, si una asignación de clúster no es compatible con la estructura derivada.

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

  • A lo sumo Clustercount, * 2SectorsPerClusterShift * 2BytesPerSectorShift

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

6,3 plantilla DirectoryEntry principal genérica

La primera entrada de directorio en un conjunto de entradas de directorio debe ser una entrada de directorio principal. Todas las entradas de directorio subsiguientes, si las hay, en el conjunto de entradas de directorio serán entradas de directorio secundario (consulte la sección 6,4).

La capacidad de interpretar la plantilla DirectoryEntry principal genérica es obligatoria.

Todas las estructuras de entradas de directorio principales derivan de la plantilla DirectoryEntry principal genérica (vea la tabla 16), que deriva de la plantilla DirectoryEntry genérica (consulte la sección 6,2).

Tabla 16 plantilla DirectoryEntry principal genérica

Nombre del campo

Offset

bytes

Tamaño

bytes

Comentarios
EntryType tal y 0 1 Este campo es obligatorio y en la sección 6.3.1 se 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.

6.3.1 campo de EntryType

El campo EntryType debe ajustarse a la definición proporcionada en la plantilla DirectoryEntry genérico (consulte la sección 6.2.1).

6.3.1.1 campo TypeCode

El campo TypeCode debe ajustarse a la definición proporcionada en la plantilla DirectoryEntry genérico (consulte la sección 6.2.1.1).

6.3.1.2 TypeImportance

El campo TypeImportance debe ajustarse 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 de directorio principales críticas (las entradas del directorio de archivos son una excepción, consulte la sección 7,4).

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

6.3.1.2.2 entradas de directorio principal benignas

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

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

6.3.1.3 TypeCategory

El campo TypeCategory debe ajustarse 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 debe ser 0.

6.3.1.4 campo InUse

El campo InUse debe ajustarse 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 debe 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, constituyen el conjunto de entradas de directorio.

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

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

  • A lo sumo 255, lo que significa que las siguientes entradas de directorio 255 y esta entrada de directorio principal constituyen el conjunto de entradas de directorio

Las estructuras de entradas de directorio principales críticas que se derivan de esta plantilla pueden volver a definir los campos SecondaryCount y Setchecksum (.

6.3.3 Setchecksum (

El campo Setchecksum (contendrá la suma de comprobación de todas las entradas de directorio en el 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 de entradas de directorio principales críticas que se derivan de esta plantilla pueden volver a definir 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 GeneralPrimaryFlags

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

Las estructuras de entradas de directorio principales críticas que se derivan de esta plantilla pueden volver a definir este campo.

Tabla 17 estructura de campos de GeneralPrimaryFlags genéricos

Nombre del campo

Offset

poco

Tamaño

parada

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 AllocationPossible

El campo AllocationPossible debe describir si es posible una asignación en el montón del clúster para la entrada de directorio especificada.

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

  • 0, que significa que no es posible una asignación asociada de clústeres y que los campos FirstCluster y DATALENGTH no estén definidos realmente (las estructuras que se derivan de esta plantilla pueden volver a definir esos campos)

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

6.3.4.2 NoFatChain

El campo NoFatChain debe indicar si la FAT activa describe o no la cadena de clúster de la asignación determinada.

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

  • 0, que significa que las entradas FAT correspondientes para la cadena de clúster 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, 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 interpretan. las implementaciones pueden usar la siguiente ecuación para calcular el tamaño de la asignación asociada: DATALENGTH/(2SectorsPerClusterShift * 2BytesPerSectorShift) redondeada al entero más próximo.

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úster de asignación asociada son válidas.

6.3.5 FirstCluster

El campo FirstCluster debe ajustarse 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 de entradas de directorio principales críticas que se derivan de esta plantilla pueden volver a definir los campos FirstCluster y DATALENGTH. Otras estructuras que derivan de esta plantilla pueden volver a definir los campos FirstCluster y DATALENGTH solo si el campo AllocationPossible contiene el valor 0.

Campo 6.3.6 DATALENGTH

El campo DATALENGTH debe ajustarse 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 de entradas de directorio principales críticas que se derivan de esta plantilla pueden volver a definir los campos FirstCluster y DATALENGTH. Otras estructuras que derivan de esta plantilla pueden volver a definir los campos FirstCluster y DATALENGTH solo si el campo AllocationPossible contiene el valor 0.

6,4 plantilla DirectoryEntry secundaria genérica

El propósito central de las entradas del directorio secundario es proporcionar información adicional sobre un conjunto de entradas de directorio. La capacidad de interpretar la plantilla DirectoryEntry secundaria genérica es obligatoria.

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

Todas las estructuras de entradas de directorio secundarias se derivan de la plantilla DirectoryEntry secundaria genérica (vea la Tabla 18), que deriva de la plantilla DirectoryEntry genérica (consulte la sección 6,2).

Tabla 18 plantilla DirectoryEntry secundaria genérica

Nombre del campo

Offset

bytes

Tamaño

bytes

Comentarios
EntryType tal y 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 de EntryType

El campo EntryType debe ajustarse a la definición proporcionada en la plantilla DirectoryEntry genérico (consulte la sección 6.2.1)

6.4.1.1 campo TypeCode

El campo TypeCode debe ajustarse a la definición proporcionada en la plantilla DirectoryEntry genérico (consulte la sección 6.2.1.1).

6.4.1.2 TypeImportance

El campo TypeImportance debe ajustarse 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 de directorio secundario críticas

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 una entrada de directorio secundario crítica específica es opcional, una entrada de directorio crítica no reconocida representa el conjunto completo 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 secundario crítica que no reconoce una implementación, la implementación tendrá, como máximo, las plantillas de las entradas de directorio en el conjunto de entradas de directorio, y no los datos de ninguna asignación asociada a ninguna entrada de directorio del conjunto de entradas de directorio (las entradas de directorio de archivos son una excepción; vea la 7,4 sección

6.4.1.2.2 entradas de directorio secundario benignas

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

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

6.4.1.3 TypeCategory

El campo TypeCategory debe ajustarse 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 es 1.

6.4.1.4 campo InUse

El campo InUse debe ajustarse 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 estructura de campos GeneralSecondaryFlags genéricos

Nombre del campo

Offset

poco

Tamaño

parada

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 AllocationPossible

El campo AllocationPossible debe tener la misma definición que el campo con el mismo nombre en la plantilla DirectoryEntry principal genérica (consulte la sección 6.3.4.1).

6.4.2.2 NoFatChain

El campo NoFatChain debe tener la misma definición que el campo con el mismo nombre en la plantilla DirectoryEntry principal genérica (consulte la sección 6.3.4.2).

6.4.3 campo FirstCluster

El campo FirstCluster debe ajustarse 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.

Campo 6.4.4 DATALENGTH

El campo DATALENGTH debe ajustarse 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 entradas 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, una FAT no describe el estado de asignación de los clústeres; en su lugar, se realiza un mapa de bits de asignación. Los mapas de bits de asignación existen en el montón del clúster (consulte la sección 7.1.5) y tienen las entradas de directorio principal críticas correspondientes en el directorio raíz (vea la Tabla 20).

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

Tabla 20 mapa de bits de asignación DirectoryEntry (estructura)

Nombre del campo

Offset

bytes

Tamaño

bytes

Comentarios
EntryType tal y 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 de EntryType

El campo EntryType debe ajustarse a la definición proporcionada en la plantilla DirectoryEntry principal genérica (consulte la sección 6.3.1).

7.1.1.1 campo TypeCode

El campo TypeCode debe ajustarse a la definición proporcionada en la plantilla DirectoryEntry principal genérica (consulte la sección 6.3.1.1).

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

Campo 7.1.1.2 TypeImportance

El campo TypeImportance debe ajustarse a la definición proporcionada en la plantilla DirectoryEntry principal genérica (consulte la sección 6.3.1.2).

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

7.1.1.3 TypeCategory

El campo TypeCategory debe ajustarse a la definición proporcionada en la plantilla DirectoryEntry principal genérica (consulte la sección 6.3.1.3).

7.1.1.4 campo InUse

El campo InUse debe ajustarse a la definición proporcionada en la plantilla DirectoryEntry principal genérica (consulte la sección 6.3.1.4).

7.1.2 campo BitmapFlags

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

Tabla 21 BitmapFlags estructura de campo

Nombre del campo

Offset

poco

Tamaño

parada

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 BitmapIdentifier

El campo BitmapIdentifier indicará el mapa de bits de asignación que se describe en la entrada de directorio especificada. Las implementaciones utilizarán el primer mapa de bits de asignación junto con la primera FAT y usarán el segundo mapa de bits de 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, que significa que la entrada de directorio dada describe el primer mapa de bits de asignación

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

7.1.3 campo FirstCluster

El campo FirstCluster debe ajustarse a la definición proporcionada en la plantilla DirectoryEntry principal genérica (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 la FAT, que hospeda el mapa de bits de asignación.

Campo 7.1.4 DATALENGTH

El campo de clúster de meta6.3.6 debe ajustarse a la definición proporcionada en la plantilla DirectoryEntry principal genérica (consulte la sección).

Mapa de bits de asignación de 7.1.5

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

Un mapa de bits de asignación representa los clústeres del índice más bajo al más alto (vea 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 inferior del primer byte.

Tabla 22 estructura de mapa de bits de asignación

Nombre del campo

Offset

poco

Tamaño

parada

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

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

7.1.5.1 BitmapEntry [ 2 ] ... BitmapEntry [ clustercount, + 1 ]

Cada campo BitmapEntry de esta matriz representa un clúster en el montón del clúster. BitmapEntry [ 2 ] representa el primer clúster del montón del clúster 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 (una asignación de clúster ya puede consumir el clúster correspondiente o la FAT activa puede describir el clúster correspondiente como incorrecto)

7,2 entrada de directorio de tabla de casos de uso

La tabla de mayúsculas y minúsculas define la conversión de minúsculas a caracteres en mayúsculas. Esto es importante debido a la entrada del directorio de nombres de archivo (consulte la sección 7,7) uso de caracteres Unicode y el sistema de archivos exFAT no distingue mayúsculas de minúsculas y se conservan las mayúsculas y minúsculas. La tabla de casos de arriba existe en el montón del clúster (vea la sección 7.2.5) y tiene una entrada de directorio principal crítica correspondiente en el directorio raíz (vea la tabla 23). El número válido de entradas de directorio de tabla de casos de uso es 1.

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

Tabla 23: estructura DirectoryEntry de la tabla de casos

Nombre del campo

Offset

bytes

Tamaño

bytes

Comentarios
EntryType tal y 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.

7.2.1 (campo de EntryType)

El campo EntryType debe ajustarse a la definición proporcionada en la plantilla DirectoryEntry principal genérica (consulte la sección 6.3.1).

Campo TypeCode de 7.2.1.1

El campo TypeCode debe ajustarse a la definición proporcionada en la plantilla DirectoryEntry principal genérica (consulte la sección 6.3.1.1).

Para la entrada de directorio de la tabla de casos de uso, el valor válido para este campo es 2.

7.2.1.2 TypeImportance campo

El campo TypeImportance debe ajustarse a la definición proporcionada en la plantilla DirectoryEntry principal genérica (consulte la sección 6.3.1.2).

Para la entrada de directorio de la tabla de casos de uso, el valor válido para este campo es 0.

7.2.1.3 TypeCategory

El campo TypeCategory debe ajustarse a la definición proporcionada en la plantilla DirectoryEntry principal genérica (consulte la sección 6.3.1.3).

7.2.1.4 campo InUse

El campo InUse debe ajustarse a la definición proporcionada en la plantilla DirectoryEntry principal genérica (consulte la sección 6.3.1.4).

7.2.2 TableChecksum

El campo TableChecksum contiene la suma de comprobación de la tabla de casos de uso (que describen los campos FirstCluster y DATALENGTH). Las implementaciones deben comprobar que el contenido de este campo es válido antes de usar la tabla de casos de uso.

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 debe ajustarse a la definición proporcionada en la plantilla DirectoryEntry principal genérica (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 la FAT, que hospeda la tabla de casos de uso.

Campo de longitud de DATALENGTH 7.2.4

El campo de clúster de meta6.3.6 debe ajustarse a la definición proporcionada en la plantilla DirectoryEntry principal genérica (consulte la sección).

7.2.5: tabla de casos

Una tabla con 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 casos de uso de mayúsculas que representa el carácter Unicode que se va a convertir en mayúsculas y el campo de 2 bytes que representa el carácter Unicode con 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 casos de uso. Estas implementaciones solo usarán caracteres del intervalo de asignación obligatorio al crear o cambiar el nombre de archivos (a través de la entrada del directorio de nombres de archivo, consulte la sección 7,7). Cuando se usan mayúsculas y minúsculas en los nombres de archivo existentes, tales implementaciones no deben poner en mayúsculas los caracteres del intervalo de asignación no obligatorio, pero deben dejarlos intactos en el nombre de archivo con mayúsculas y minúsculas resultante (se trata de un carácter de mayúsculas y minúsculas parcial). Al comparar los nombres de archivo, estas implementaciones tratarán los nombres de archivo que se diferencian del nombre en comparación únicamente por los caracteres Unicode del intervalo de asignación no obligatorio como equivalentes. Aunque estos nombres de archivo solo son potencialmente equivalentes, estas implementaciones no pueden garantizar que el nombre de archivo con mayúsculas y minúsculas no entre en conflicto con el nombre en comparación.

Tabla 24: primeras 128 entradas de la tabla de casos arriba

Índice de tabla Entradas 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 casos de uso 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 mayúsculas de minúsculas (lo que significa que los caracteres "en minúscula" y "en mayúscula" son equivalentes). Las implementaciones comprimen una tabla de mayúsculas y minúsculas representando 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 100 (64h) con las siguientes ocho entradas de una tabla de casos de uso comprimido:

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

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

La capacidad de proporcionar una tabla de casos de uso comprimido al formatear un volumen es opcional. Sin embargo, la capacidad de interpretar una tabla sin comprimir y una tabla de casos de uso comprimido es obligatoria. El valor del campo TableChecksum siempre se ajusta al modo en que existe la tabla de casos en el volumen, que puede tener un formato comprimido o sin comprimir.

Al dar formato a un volumen, las implementaciones de deben registrar la tabla de casos que se recomienda en el formato comprimido (vea la tabla 25), para la que el valor del campo TableChecksum es E619D30Dh.

Si una implementación define su propia tabla de casos, comprimidos o sin comprimir, esa tabla cubrirá el intervalo de caracteres Unicode completo (de los códigos de carácter 0000h a FFFFh inclusive).