Las profundidades de la E/S de Windows (parte 5) — Estructura interna de NTFS: comprender el sistema de archivos a partir de la MFT

El Zone.Identifier invisible que se adjunta a un archivo descargado. Por qué copiar diez mil archivos pequeños es lento aunque el tamaño total sea el mismo. Hasta dónde llega realmente la explicación «NTFS usa journaling, así que está a salvo». Este artículo los organiza a partir de cómo se colocan los datos en el disco.

En el centro está la MFT (Master File Table, tabla maestra de archivos), el libro mayor que lleva la cuenta de cada archivo. Primero se toma el archivo como un conjunto de atributos y, a continuación, se recorren los datos, los nombres, los vínculos, los diarios y el espacio en disco, en ese orden.

Las partes 1 a 3 de la serie cubrieron el flujo de una solicitud de E/S, y la parte 4, el papel de la caché. Esta vez se toma NTFS, el representante por excelencia del sistema de archivos al que la solicitud llega al final. Es la entrega en la que el punto de vista pasa de la historia dinámica de «cómo fluye la solicitud» a la estructura estática de «cómo se colocan los datos».

Esta es la parte 5 de la serie «Las profundidades de la E/S de Windows».

Empiece por el problema que tiene

Si quiere aprender el mecanismo en orden, empiece por el capítulo 2; si está en medio de una investigación, use la guía siguiente. Los comandos de comprobación y cómo leer su salida están reunidos en el capítulo 8.

Términos previos que se usan en esta entrega

Requisito previo para esta entrega: resulta más fácil de leer si ya tiene los conceptos básicos de IRP y de la pila de dispositivos vistos en la parte 1. Aun así, para que pueda leerla de forma independiente sin problemas, a continuación se definen los términos de entregas anteriores que aparecen en el texto.

Tabla 1: Términos de entregas anteriores que se dan por conocidos en esta entrega

Además, las dos fases tratadas en la parte 1 —cleanup (cuando se cierra el último identificador) y close (cuando desaparecen todas las referencias internas del núcleo)— también se usan en la explicación de la eliminación de archivos del capítulo 4.

1. Primero, la conclusión

Qué es realmente un archivo y dónde se colocan los datos

• El centro de NTFS es la MFT (Master File Table, tabla maestra de archivos). Todos los archivos se gestionan como un libro mayor de registros dentro de la MFT, y toda la información relativa a un archivo está «dentro de la entrada de la MFT» o en «la zona fuera de la MFT a la que apunta la entrada» (capítulo 2).¹
• El contenido real de un archivo es un «conjunto de atributos». Los archivos pequeños caben, contenido incluido, dentro del registro de la MFT (residentes), mientras que los archivos grandes solo tienen una referencia a una secuencia de clústeres (no residentes). La lentitud del procesamiento masivo de archivos pequeños se explica a partir de aquí (capítulo 2).¹
• Un archivo puede tener varios flujos de datos (streams). El dato habitual es el «flujo sin nombre», y se pueden añadir flujos adicionales con la forma file.txt:nombre. Esta es la verdadera identidad de Zone.Identifier (Mark of the Web) (capítulo 3).²

Los nombres y el procesamiento al abrir

• El nombre también es un atributo. Un enlace físico (hard link) consiste en asignar varios nombres al mismo registro. El nombre corto 8.3 también convive como «otro nombre más» (capítulo 4).³⁴
• El punto de análisis (reparse point) es el mecanismo oficial de «al abrirlo, se va a otro sitio». Los enlaces simbólicos, las uniones (junctions) y los archivos a petición de OneDrive son todos aplicaciones de estos datos etiquetados (capítulo 5).⁵⁶

Recuperación ante fallos y asignación de espacio en disco

• Hay dos diarios (journals). $LogFile sirve para recuperar la coherencia de los metadatos (un registro de anticipación para no corromperse), y el diario USN sirve para registrar el historial de cambios (un libro mayor de qué ha cambiado). Sus funciones son completamente distintas (capítulo 6).⁷⁸
• El «tamaño» y el «tamaño en disco» son cosas distintas. Los archivos dispersos (sparse) y la compresión generan esta divergencia. Aquí también está el trasfondo de aquello que vimos en la parte 2: «los archivos comprimidos no se vuelven asíncronos» (capítulo 7).⁹¹⁰

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (35 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

2. Todo es, en el fondo, un registro de la MFT

2.1. El libro mayor del volumen

Al formatear un volumen NTFS se crean la MFT (master file table) y una serie de archivos de metadatos que comienzan por $. La MFT contiene al menos una entrada por cada archivo del volumen, y eso incluye una entrada para la propia MFT.¹

flowchart TB
    subgraph VOL["Volumen NTFS"]
        MFT["$MFT — tabla maestra de archivos<br/>Libro mayor de los registros de todos los archivos (también el suyo)"]
        LOG["$LogFile — registro de transacciones de<br/>operaciones de metadatos (capítulo 6)"]
        BITMAP["$Bitmap — uso de los clústeres"]
        OTH["$Boot / $Secure / $UpCase y<br/>otros archivos de metadatos"]
        DATA["Área de datos de usuario<br/>(dónde viven los datos no residentes)"]
    end
    MFT -->|"el registro indica la posición"| DATA

Figura 1: Estructura de un volumen NTFS. Que la propia información de gestión del sistema de archivos también se guarde como archivos forma parte del diseño de NTFS

La información está dentro del registro o en la zona externa a la que el registro apunta

El tamaño, las marcas de tiempo, los permisos de acceso e incluso el contenido de los datos: toda la información de un archivo se almacena dentro de la entrada de la MFT o en una zona fuera de la MFT cuya posición describe la entrada.¹

El registro que queda libre al eliminar se reutiliza, pero la MFT misma no se reduce

Al eliminar un archivo, la entrada se marca como «libre» y se reutiliza. Sin embargo, el tamaño de la propia MFT no se reduce.

Para que, al crecer, la MFT pueda usar una zona lo más continua posible, se reserva una zona de la MFT. La documentación oficial también describe cómo cambia esto en operación: a medida que el volumen se llena, empieza la fragmentación de la MFT.¹

2.2. Un archivo es un conjunto de atributos: residente y no residente

El contenido de un registro de archivo es una lista de atributos. La información estándar (marcas de tiempo, etc.), el nombre de archivo, la seguridad y los datos se gestionan juntos en este conjunto.

El lugar donde se colocan los datos se divide en estos dos casos.

La figura 2 muestra la bifurcación y la figura 3, la diferencia en el contenido del registro.

flowchart TB
    subgraph REC["Registro de archivo MFT (el libro mayor de un archivo)"]
        STD["Atributo de información estándar<br/>marcas de tiempo e indicadores de atributo"]
        FN["Atributo de nombre de archivo<br/>(puede haber varios — capítulo 4)"]
        DATA["Atributo de datos"]
    end
    Q{"¿Los datos son pequeños?"}
    RES["Residente (resident)<br/>el contenido cabe dentro del registro<br/>una lectura se completa solo con acceder a la MFT"]
    NONRES["No residente (non-resident)<br/>el registro solo tiene una referencia a la secuencia de clústeres<br/>los datos reales están en el área de datos de usuario"]
    DATA --> Q
    Q -->|"hasta unos cientos de bytes"| RES
    Q -->|"más que eso"| NONRES

Figura 2: El registro de archivo es un conjunto de atributos. Si los datos son pequeños, quedan «residentes» dentro del registro

Resulta más claro ver, uno junto al otro, cómo cambia el contenido del mismo registro entre el caso residente y el no residente.

flowchart LR
    subgraph RES2["Residente (resident) — un archivo pequeño"]
        RA["Registro de archivo MFT (longitud fija)<br/>información estándar / nombre de archivo / seguridad<br/>─────────────<br/>atributo de datos = el contenido mismo<br/>«valor=1» entra aquí directamente"]
        RB["No hay otro lugar de almacenamiento en el disco<br/>una lectura se completa solo con acceder a la MFT"]
        RA --> RB
    end
    subgraph NON2["No residente (non-resident) — un archivo grande"]
        NA["Registro de archivo MFT (longitud fija)<br/>información estándar / nombre de archivo / seguridad<br/>─────────────<br/>atributo de datos = tabla de data runs<br/>la lista de «desde dónde, cuántos clústeres»"]
        NB["Área de datos de usuario<br/>run 1: clústeres contiguos"]
        NC["Área de datos de usuario<br/>run 2: clústeres contiguos en otro lugar"]
        NA -->|"indica la posición"| NB
        NA -->|"indica la posición"| NC
    end

Figura 3: Contraste entre residente y no residente. En el caso no residente, lo único que tiene el registro es la tabla de «dónde está el dato real y cuánto hay» (los data runs)

Cuantos más data runs hay, más zonas dispersas hay que recorrer para leer un solo archivo. Esa es exactamente la verdadera identidad de la fragmentación que se describe a continuación.

A partir de esta estructura se explican varios fenómenos que se encuentran en el terreno.

En la copia de archivos pequeños se acumula el trabajo de libro mayor por archivo

Por cada archivo se producen operaciones de metadatos: crear el registro MFT, registrar el nombre y configurar la seguridad. El trabajo de libro mayor acaba dominando sobre la transferencia de datos en sí (y cada una de esas operaciones también será objeto de inspección por los filtros que se verán en la parte 6).

La fragmentación es que los data runs se repartan en varias zonas

Los datos no residentes se registran como «una secuencia de intervalos contiguos de clústeres (runs)». Si no se consigue una zona continua, aumenta el número de runs y aumentan las búsquedas (seeks) necesarias para leer: eso es la fragmentación. La disposición real de los runs se puede inspeccionar con fsutil file layout.

Un directorio también es un archivo que tiene un índice para resolver nombres

Un directorio es «un archivo que tiene un índice que va del nombre de archivo al número de registro MFT». En el libro mayor, todo descansa sobre el mismo mecanismo.

3. Los datos no son más que uno de los «flujos»

3.1. Un archivo, varias secuencias de bytes

En NTFS, un mismo archivo puede tener varios flujos de datos. Lo que normalmente se lee y se escribe con ReadFile/WriteFile es el flujo predeterminado sin nombre, y con la sintaxis nombre-de-archivo:nombre-de-flujo se puede crear un flujo de datos alternativo (ADS).²

flowchart LR
    subgraph F["El archivo report.docx (un solo registro MFT)"]
        D0["Flujo predeterminado (sin nombre)<br/>= el contenido que se ve a diario"]
        D1[":Zone.Identifier<br/>información de origen (Mark of the Web)"]
        D2[":un nombre cualquiera<br/>información adicional propia de la aplicación"]
    end

Figura 4: Flujos de datos múltiples. En el tamaño que muestra el Explorador solo aparece el flujo predeterminado

Zone.Identifier es un flujo que guarda la información de origen

El ejemplo más cercano es Zone.Identifier. En un archivo descargado con el explorador se registra su origen (que procede de internet, por ejemplo) y sirve como criterio para el aviso «Windows protegió el equipo» de SmartScreen y para la vista protegida de Office.

El mecanismo del aviso se trató en «Por qué Windows muestra «Windows protegió el equipo»». El mecanismo del otro lado, el que guarda esa información de origen, es el flujo adicional de NTFS.

3.2. Las trampas que pisa el desarrollador

No se ve solo con un listado habitual ni con la visualización del tamaño

No aparece ni en el tamaño del Explorador ni en el listado de dir. Se puede comprobar con dir /r o con streams de Sysinternals.¹¹

Según el destino o la ruta de la copia, se pierde

El ADS es una función de NTFS, así que suele perderse al copiar a una memoria USB con FAT o a través de almacenamiento en la nube. «El aviso de descarga desapareció al copiar» es esto.

Aunque la aplicación pueda usarlo, no lo convierta en el almacén del dato de negocio propiamente dicho

Se puede leer y escribir con solo incluir dos puntos en la ruta, como en CreateFile("data.txt:meta", ...) .² Es cómodo, pero se asume también la propiedad del apartado anterior —«no se puede transportar»—, así que no es el lugar donde guardar el contenido de los datos de negocio.

4. El nombre también es un atributo — enlaces físicos y nombres 8.3

4.1. Enlace físico — varios nombres hacia el mismo registro

En la figura 2 se escribió que «el atributo de nombre de archivo puede haber varios». Varias rutas, dentro del mismo volumen, referencian un único archivo: eso es un enlace físico (CreateHardLink / mklink /H).³

flowchart TB
    subgraph DIR1["Índice de C:\app\"]
        E1["config.json → registro #1234"]
    end
    subgraph DIR2["Índice de C:\backup\"]
        E2["config-link.json → registro #1234"]
    end
    REC["Registro MFT #1234<br/>contenido de los datos (o referencia a los runs)<br/>número de vínculos: 2"]
    E1 --> REC
    E2 --> REC

Figura 5: Enlace físico. El índice del directorio apunta al mismo registro MFT; ambos son «el auténtico»

Cualquier nombre apunta al mismo archivo

Cambiar desde cualquier nombre es el mismo archivo, así que el contenido coincide de inmediato.³ No se trata de considerar uno auténtico y el otro una copia, sino de que al mismo contenido real se le han puesto nombres de igual rango.

Separar quitar un nombre de que desaparezca la entidad

Cuando hay un enlace físico, DeleteFile significa «quitar un nombre». La entidad desaparece cuando se quita el último nombre, se cierran los identificadores abiertos y desaparecen también todas las referencias internas del núcleo, como una sección de asignación en memoria.

Las dos fases de la parte 1, cleanup (cuando se cierra el último identificador) y close (cuando desaparece la última referencia), también intervienen en esta vida de la eliminación.

Compartir el contenido y actualizar la visualización de atributos no son lo mismo

Aunque se cambien los atributos desde un vínculo, la visualización aparente de atributos de otro vínculo puede quedarse desactualizada. Es una peculiaridad de visualización que también anota la documentación oficial.³

4.2. El nombre 8.3 — otro nombre oculto

El nombre corto es un alias de compatibilidad

Por compatibilidad histórica, NTFS puede generar automáticamente un nombre corto en formato 8.3, como REPORT~1.DOC, para un nombre de archivo largo. También este es «otro nombre más» que convive en el mismo registro.

En una carpeta con muchos archivos, generar el nombre corto y evitar colisiones también tiene un coste. Con fsutil 8dot3name se puede desactivar la generación o quitar los nombres cortos existentes.⁴

Sin embargo, si hay una aplicación antigua que registra el nombre corto en una ruta del Registro, quitarlo la rompe. Que exista una función para inspeccionar el impacto antes del strip es por eso.⁴

Compruebe la configuración de generación antes de depender del nombre corto

Que exista o no un nombre corto depende del entorno. El valor del Registro que decide el comportamiento predeterminado, NtfsDisable8dot3NameCreation, admite estas cuatro opciones.⁴

Con 2 se puede conmutar por volumen. No es cierto que «en Windows siempre existe un nombre corto como PROGRA~1».

Antes de escribir código o un procedimiento que dependa del nombre corto, compruebe el estado con fsutil 8dot3name query C:. Si omite el volumen, puede comprobar la configuración predeterminada común a todos los volúmenes.

Las trampas en torno a las rutas y los nombres (MAX_PATH, nombres reservados, punto final) se tratan con detalle en «MAX_PATH y las trampas de las rutas y los nombres de archivo en Windows». Juntando la resolución de nombres de la parte 1 (el administrador de objetos) con este capítulo (los nombres dentro del sistema de archivos) se obtiene el panorama completo de los «nombres» en Windows.

5. Puntos de análisis — el mecanismo de «al abrirlo, se va a otro sitio»

Se mira la etiqueta y se cambia el procesamiento al abrir

A un archivo o a un directorio se le puede poner un punto de análisis (reparse point). En la práctica es un atributo que tiene una etiqueta y datos definidos por el usuario.

Al abrir un archivo con punto de análisis, el procesamiento cambia según la etiqueta. Hay casos en que un controlador de filtro que entiende la etiqueta se hace cargo, y casos en que, por una etiqueta de cambio de nombre, se vuelve a resolver con la ruta de destino.⁵

sequenceDiagram
    participant App as Aplicación
    participant IOM as Administrador de E/S
    participant FS as NTFS

    App->>IOM: CreateFile("C:\\data\\link.txt")
    IOM->>FS: IRP_MJ_CREATE (el mundo de la parte 1)
    Note over FS: Se descubre un punto de análisis en el destino<br/>se devuelven la etiqueta y los datos
    alt Enlace simbólico / unión (cambio de nombre)
        FS-->>IOM: «El lugar real es este»
        IOM->>FS: Se vuelve a resolver con la ruta de destino
    else Etiqueta gestionada por un filtro (archivo en la nube, etc.)
        Note over FS: El filtro que entiende la etiqueta<br/>se hace cargo del procesamiento (parte 6)
    end

Figura 6: Resolución de un punto de análisis. Se ha convertido en el gancho oficial que se interpone en la operación de «abrir»

Enlaces simbólicos, uniones y archivos a petición

Sobre este único mecanismo se alinean funciones que ya resultan familiares.

• Enlace simbólico (mklink) — un indicador que conserva la ruta de destino. También puede apuntar a otro volumen o a una ruta UNC.⁶
• Unión / punto de montaje — el mecanismo veterano que conecta un directorio con una ubicación de otro volumen local.³
• Archivos a petición de OneDrive — un archivo cuyo contenido real no está a mano se representa con un punto de análisis y, en el instante de abrirlo, el filtro lo descarga y entrega el contenido. Esa es la verdadera identidad de «se ve en el Explorador, pero al abrirlo se dispara comunicación» (el mecanismo del filtro en sí se verá en la parte 6).

El código que recorre un árbol comprueba los puntos de análisis

En la práctica, lo importante es que el destino de una ruta no tiene por qué ser realmente ese lugar local. Un código que no tiene en cuenta su existencia pisa problemas como los siguientes.

• El recorrido recursivo entra en bucle por una unión.
• El recuento de tamaños se duplica.
• Una copia de seguridad provoca la materialización masiva de archivos en la nube.

El punto de entrada de la medida es comprobar FILE_ATTRIBUTE_REPARSE_POINT con las API de la familia FindFirstFile.⁵

6. Los dos diarios — $LogFile y USN

Se dice a menudo que «NTFS es un sistema de archivos con journaling», pero NTFS tiene dos diarios con funciones distintas. Si se confunden, se malinterpreta la garantía.

flowchart TB
    subgraph J1["$LogFile — registro de anticipación (para no romperse)"]
        A1["Las operaciones de metadatos (actualizar un registro, cambiar un nombre, etc.)<br/>se registran en el diario antes de ejecutarlas"]
        A2["Tras un fallo del sistema, en el siguiente arranque<br/>se reproduce el diario y se recupera la coherencia de la estructura"]
        A1 --> A2
    end
    subgraph J2["Diario USN — historial de cambios (para saber qué cambió)"]
        B1["Cada vez que cambia un archivo o un directorio<br/>se registran el contenido del cambio y el nombre"]
        B2["Las copias de seguridad, los índices de búsqueda y las herramientas de sincronización<br/>conocen «qué cambió desde la última vez» sin un recorrido completo"]
        B1 --> B2
    end

Figura 7: Los dos diarios. $LogFile es para «no romperse»; el USN, para «saber qué cambió»

Puesto en una tabla, la diferencia queda así.

Tabla 2: Contraste entre los dos diarios

$LogFile recupera la coherencia de la estructura

$LogFile es el registro de anticipación de las operaciones de metadatos. Tras un fallo del sistema, NTFS recupera automáticamente la coherencia del sistema de archivos a partir del diario y de la información de punto de control en el siguiente arranque.⁷

Lo que aquí se protege es la coherencia de la estructura, no el contenido de los datos escritos en el archivo. Como se vio en la parte 4, los datos sucios que están en la caché pueden perderse con un corte de energía. Separe poder recuperar la estructura de que quede el contenido de la última escritura.

El USN es el libro mayor para investigar qué cambió desde la última vez

El diario USN registra, cada vez que cambia un archivo o un directorio del volumen, el contenido del cambio y el nombre del destino.⁸

Es el mecanismo con el que las copias de seguridad y los indizadores recogen «solo lo que cambió desde la última vez» sin un recorrido completo, y también se usa para evitar reconstruir el índice tras un fallo.⁸

En una investigación, fsutil usn readjournal puede servir como libro mayor de cotejo que compensa lo que se le escapa a FileSystemWatcher. Sobre las pérdidas de la supervisión en sí, consulte «Guía práctica de FileSystemWatcher».

7. Archivos dispersos y compresión — la historia de que hay dos «tamaños»

En NTFS, la longitud lógica de un archivo y el espacio realmente asignado se gestionan por separado. Son el «tamaño» y el «tamaño en el disco» de la pantalla de propiedades. Hay dos representantes que generan la divergencia.

Un archivo disperso tiene los rangos de ceros como «huecos»

Un archivo disperso (sparse file) no asigna espacio real a los rangos de ceros seguidos y los gestiona como «huecos».⁹ Que un archivo de disco virtual de 42 GB de tamaño lógico use solo 500 MB en el disco es algo que ocurre con normalidad. Si se lee un hueco, se devuelven ceros; si se escribe, se asigna solo esa parte.

flowchart LR
    subgraph L["Archivo lógico (tamaño: 1 GB)"]
        R1["Datos 10 MB"]
        H1["Hueco (ceros) 500 MB"]
        R2["Datos 5 MB"]
        H2["Hueco (ceros) el resto"]
    end
    subgraph P["Asignación en disco (15 MB + información de gestión)"]
        A1["Run: el contenido real de R1"]
        A2["Run: el contenido real de R2"]
    end
    R1 --> A1
    R2 --> A2

Figura 8: Archivo disperso. Los «huecos» no tienen asignación, y el tamaño lógico y el tamaño en el disco divergen

La compresión no solo afecta al uso: también al comportamiento de la E/S

La compresión NTFS comprime y almacena los datos por unidad de compresión.¹⁰ Es transparente y cómoda, pero el coste no es transparente: en cada lectura y escritura se ejecuta una expansión y una recompresión, y la fragmentación también avanza con más facilidad. Y, como se vio en el capítulo 5 de la parte 2, el acceso a un archivo comprimido no se vuelve asíncrono (el sistema de archivos lo convierte en síncrono). Es uno de los sitios que hay que sospechar cuando «hay archivos que no se aceleran aunque se haya pasado a E/S asíncrona».

Cuatro factores que mirar cuando los tamaños no coinciden

El tamaño real basado en la asignación se puede obtener con GetCompressedFileSize. Cuando el «total de tamaños de archivo» y el «uso de disco» no coinciden, se comprueban estos cuatro, en este orden.

Separar la longitud lógica del espacio asignado hace más fácil seguir las diferencias de visualización.

8. Compruébelo con sus propios ojos

Esta vez también se puede observar todo en el Windows que tiene a mano (parte de ello requiere privilegios de administrador). Para que pueda juzgar por sí mismo si el resultado es correcto, cada comando lleva una nota de dónde mirar y qué se averigua.

8.1. Ver si hay un ADS por la línea que lleva el nombre del flujo

:: Ver los flujos de datos alternativos
dir /r C:\Users\%USERNAME%\Downloads

Dónde mirar: debajo de las líneas normales de archivo aparecen, con sangría y con su longitud, líneas de la forma nombre-de-archivo:Zone.Identifier:$DATA. Si está esa línea, el archivo lleva el Mark of the Web (capítulo 3). Los archivos descargados con el explorador lo tienen; los que uno mismo crea, no. Ejecutarlo en ambos sitios y comparar deja claro si hay ADS o no.

8.2. Ver lo residente y lo no residente, y la disposición de los datos

:: Ver la disposición (runs) y los atributos de un archivo en la MFT
fsutil file layout C:\path\to\file.dat

:: Ver solo las extensiones (un subcomando descrito en la documentación oficial)
fsutil file queryextents C:\path\to\file.dat

Dónde mirar: layout enumera, por flujo, el tamaño y el tamaño asignado y, si es no residente, la lista de extensiones (triples de VCN, LCN y número de clústeres). Un archivo muy pequeño en el que no aparece ninguna línea de extensión es residente (apartado 2.2); si se reparte en varias líneas, está fragmentado. Ejecutarlo contra un archivo de texto de unos bytes y contra un archivo de cientos de MB y compararlos es la forma más corta de palpar lo residente y lo no residente.

8.3. Comparar la configuración de generación de nombres cortos con los nombres reales

:: Configuración de generación de nombres cortos 8.3, y nombres cortos existentes
fsutil 8dot3name query C:
dir /x

Dónde mirar: query indica si la generación de nombres cortos está habilitada o deshabilitada en ese volumen (si se omite el volumen, se obtiene la configuración predeterminada común a todos los volúmenes).⁴ dir /x muestra una columna de nombres cortos junto al nombre largo, así que si la columna está vacía, no se ha creado un nombre corto. Permite confirmar en el propio entorno aquello del apartado 4.2: «no tiene por qué haber un nombre corto».

8.4. Ver el estado del diario USN y cómo avanza el registro

:: Estado del diario USN
fsutil usn queryjournal C:

Dónde mirar: se muestran el identificador del diario, el rango de USN válidos (First USN / Next USN), el tamaño máximo objetivo (MaximumSize) y la unidad de asignación (AllocationDelta).¹² Si se crea un archivo y se vuelve a ejecutar, Next USN debería haber avanzado, y eso confirma que «el cambio se está registrando». MaximumSize es la referencia de «hasta dónde se puede retroceder» que se tocó en el capítulo 6. En un volumen donde el diario está deshabilitado, el comando da error.

8.5. Ver el atributo y la etiqueta de un punto de análisis

:: Comprobar puntos de análisis (destino y etiqueta)
dir /aL C:\Users\%USERNAME%
fsutil reparsepoint query "C:\Users\%USERNAME%\OneDrive"

Dónde mirar: lo que aparece en dir /aL es un punto de análisis (algo con FILE_ATTRIBUTE_REPARSE_POINT activado). Los enlaces simbólicos y las uniones se muestran con un tipo como <SYMLINKD> o <JUNCTION>. fsutil reparsepoint query muestra el valor de la etiqueta de análisis y, si es de cambio de nombre, la ruta de destino. Si se apunta a algo que no es un punto de análisis, da error, así que el propio error es la confirmación de que «esto es una carpeta normal».

8.6. Seguir las operaciones reales de archivo con Procmon

Si se siguen las operaciones de archivo con Procmon, los personajes de esta entrega desfilan con su nombre real (escrituras en $LogFile, rutas con nombre de flujo, procesamiento de análisis). Sobre cómo usarlo, consulte «Guía práctica de Process Monitor (ProcMon)».

9. Resumen

• El centro de NTFS es la MFT. Todos los archivos son un registro del libro mayor, y la información está «dentro del registro» o «en la zona externa a la que el registro apunta». Los datos pequeños son residentes y los grandes son una referencia a runs; la lentitud del procesamiento masivo de archivos pequeños y la fragmentación son consecuencias de esta estructura.¹
• Un archivo puede tener varios flujos de datos. Zone.Identifier (Mark of the Web) no es más que un ADS: se ve con dir /r y no se transporta fuera de NTFS.²¹¹
• El nombre es un atributo, y puede haber varios. Un enlace físico es un nombre de igual rango hacia el mismo registro; el nombre 8.3 es otro nombre de compatibilidad. «Eliminar = quitar un nombre», y la entidad desaparece cuando desaparecen el último nombre, el último identificador y todas las referencias internas del núcleo (una sección asignada, etc.).³⁴
• El punto de análisis es el gancho oficial sobre «abrir», y tanto el enlace simbólico como la unión y los archivos a petición son aplicaciones de esto. El código que recorre un árbol necesita tener en cuenta FILE_ATTRIBUTE_REPARSE_POINT.⁵⁶
• Hay dos diarios. $LogFile recupera la coherencia de la estructura (para no romperse); el USN es el historial de cambios (qué cambió). «Usa journaling, así que los datos también están a salvo» no se sostiene: la durabilidad de los datos se construye con las herramientas de la parte 4.⁷⁸
• El tamaño lógico y la asignación son cosas distintas. Archivos dispersos, compresión, ADS y redondeo por clúster son los cuatro grandes factores de «los tamaños no coinciden». Incluido el hecho de que un archivo comprimido no se vuelve E/S asíncrona, es un cajón útil en las investigaciones de rendimiento.⁹¹⁰

La serie concluye en la parte 6, «Controladores de filtro y minifiltros — por qué Procmon y el análisis antivirus pueden interponerse en la E/S». Cómo se interponen realmente en la E/S esos «que se colocan en medio» que han aparecido de tanto en tanto desde la parte 1 —el antivirus, Procmon, OneDrive, el cifrado—. Como cierre de la serie, se revela la verdadera identidad de los residentes que se sitúan en los huecos de la pila de dispositivos.

Artículos relacionados

• Las profundidades de la E/S de Windows (parte 1) — toda lectura y escritura se convierte en un IRP: el panorama del sistema de E/S
• Las profundidades de la E/S de Windows (parte 2) — E/S síncrona y E/S asíncrona: el verdadero significado de OVERLAPPED
• Las profundidades de la E/S de Windows (parte 4) — el administrador de caché: ¿cuándo llega su WriteFile al disco?
• Por qué Windows muestra «Windows protegió el equipo»
• MAX_PATH y las trampas de las rutas y los nombres de archivo en Windows — el límite de 260 caracteres, los nombres reservados, el punto final y mayúsculas y minúsculas
• Guía práctica de FileSystemWatcher - contramedidas para pérdidas y duplicados
• Trampas de las unidades de red y las rutas UNC — la práctica de tratar un servidor de archivos (carpeta compartida) desde una aplicación de negocio
• Guía práctica de Process Monitor (ProcMon) — identificar en 10 minutos «no se lee la configuración» y «ACCESS DENIED»

Ámbitos de consulta relacionados

En KomuraSoft LLC nos ocupamos del diseño y la investigación de aplicaciones de negocio para Windows arraigadas en el funcionamiento de NTFS, incluidos los comportamientos inexplicables de tamaño de archivo y de rendimiento de copia, y los fallos relacionados con vínculos y flujos.

• Desarrollo de aplicaciones para Windows
• Investigación de errores y análisis de causa raíz
• Aprovechamiento de activos existentes y apoyo a la migración
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Qué es la MFT (Master File Table, tabla maestra de archivos)?

Es la estructura de datos que constituye el corazón de un volumen NTFS: un libro mayor que contiene al menos una entrada (registro de archivo) para cada archivo del volumen, incluida una entrada para la propia MFT. Toda la información relativa a un archivo —su tamaño, las marcas de tiempo, los permisos de acceso e incluso el contenido de los datos— se almacena dentro de la entrada de la MFT o en una zona fuera de la MFT a la que la entrada apunta. Si el archivo es pequeño, todo el contenido cabe dentro de la propia entrada de la MFT (residente); si es grande, la entrada solo registra una referencia al lugar donde están los datos (la secuencia de clústeres), es decir, es no residente. Al eliminar un archivo, la entrada se marca como libre y se reutiliza, pero el tamaño de la propia MFT no se reduce.

¿Qué es ese dato invisible llamado «Zone.Identifier» que aparece adjunto a los archivos?

Es uno de los flujos de datos múltiples de NTFS (un flujo de datos alternativo). En NTFS, un mismo archivo puede tener varias secuencias de bytes (flujos), y lo que normalmente se lee y se escribe es el flujo predeterminado sin nombre. En un flujo adicional que se especifica con dos puntos, como en «file.txt:Zone.Identifier», Windows registra el origen del archivo (por ejemplo, que se descargó de internet). Esto es el llamado «Mark of the Web», y sirve como criterio para el aviso de SmartScreen o la vista protegida de Office. El flujo alternativo no aparece en el tamaño que muestra el Explorador, pero se puede comprobar con el comando dir /r o con la herramienta streams de Sysinternals. También conviene tener en cuenta que no se conserva al copiar a un sistema de archivos distinto de NTFS, como FAT.

¿En qué se diferencian un enlace físico y un enlace simbólico?

Un enlace físico (hard link) consiste en «añadir un nombre más, en pie de igualdad, que apunta al mismo contenido real del archivo (el mismo registro MFT)». Solo se puede crear dentro del mismo volumen, se accede al mismo archivo sin importar desde qué nombre, y si se elimina uno de los nombres, el archivo no desaparece mientras queden otros nombres. El enlace simbólico es «un indicador que dirige hacia otra ruta», y se implementa como un punto de análisis. Como solo conserva la cadena de la ruta de destino, puede apuntar a otro volumen o a un recurso remoto, pero si el destino desaparece, el enlace queda en un callejón sin salida. En la práctica, la distinción básica es: el enlace físico para compartir el contenido real (lo que cambia el significado de «eliminar»), y el enlace simbólico para redirigir rutas (traslados o redirecciones).

Como NTFS es un sistema de archivos con journaling, ¿los datos no se pierden ni siquiera con un corte de energía?

Hay que entender con precisión hasta dónde llega la protección. Lo que protege el registro de transacciones de NTFS ($LogFile) es la coherencia de la estructura (los metadatos) del sistema de archivos. Aunque se produzca un fallo del sistema, en el siguiente arranque se usa el registro para recuperar automáticamente la coherencia y evitar que «el volumen quede corrupto e ilegible». Sin embargo, esto no significa que se restaure el propio contenido de los datos de un archivo que se estaba escribiendo. Como vimos en la parte 4 de la serie, los datos sucios que están en la caché se pierden con un corte de energía. Es decir, la comprensión correcta es que «el volumen no se corrompe, pero el contenido de la última escritura puede perderse»; si se necesita durabilidad para los propios datos, hay que construirla con FlushFileBuffers, WRITE_THROUGH, o con un diseño de escritura en la propia aplicación (archivo temporal + renombrado, etc.).

¿Por qué el «Tamaño» de un archivo y su «Tamaño en el disco» son diferentes?

Porque en NTFS la longitud lógica de un archivo y el espacio de disco realmente asignado se gestionan por separado. Incluso en un archivo normal aparece una diferencia porque la asignación se redondea por unidad de clúster (4 KB de forma predeterminada), pero la divergencia se vuelve grande en los archivos dispersos y en los archivos comprimidos. En un archivo disperso, no se asigna espacio real a los tramos que son ceros seguidos, sino que se gestionan como «huecos», por lo que puede ocurrir que un tamaño lógico de varios GB ocupe solo unos pocos MB en el disco. En un archivo comprimido, solo se asigna el tamaño tras la compresión. A la inversa, cuando el «Tamaño en el disco» parece mayor, la causa puede ser el redondeo por clúster o los flujos de datos alternativos.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.