Les profondeurs de l'E/S Windows (partie 5) — Structure interne de NTFS : comprendre le système de fichiers à travers la MFT

Le Zone.Identifier invisible attaché à un fichier téléchargé. La raison pour laquelle copier dix mille petits fichiers est lent, même à taille totale égale. Jusqu’où « NTFS est journalisé, donc c’est sûr » est réellement vrai. Cet article les reprend tous à partir de la façon dont les données sont disposées sur le disque.

Au centre se trouve la MFT (Master File Table), le registre qui tient le compte de chaque fichier. On commence par voir un fichier comme un ensemble d’attributs, puis on enchaîne données, noms, liens, journaux et espace disque, dans cet ordre.

Les parties 1 à 3 de la série ont suivi le flux d’une requête d’E/S, et la partie 4 le rôle du cache. Cette fois, c’est le tour de NTFS, le représentant le plus connu du système de fichiers où la requête arrive enfin. C’est la partie où le point de vue passe de l’histoire dynamique — comment une requête circule — à la structure statique — comment les données sont posées.

Ceci est la partie 5 de la série « Les profondeurs de l’E/S Windows ».

Lire à partir du problème rencontré

Si vous voulez apprendre le mécanisme dans l’ordre, commencez au chapitre 2 ; si vous êtes en pleine investigation, servez-vous du guide ci-dessous. Les commandes de vérification et la façon de lire leur sortie sont rassemblées au chapitre 8.

Termes préalables utilisés dans cette partie

Préalable pour cette partie : il est plus facile de suivre si vous avez déjà les bases des IRP et de la pile de périphériques vues dans la partie 1. Cela dit, pour que cet article puisse aussi se lire seul, voici d’abord les définitions des termes des parties précédentes qui apparaissent dans le corps du texte.

Tableau 1 : Les termes des parties précédentes supposés acquis dans cette partie

Autre point : les deux étapes vues dans la partie 1, cleanup (quand le dernier handle se ferme) et close (quand toutes les références internes au noyau ont disparu), seront aussi utilisées dans l’explication de la suppression de fichiers au chapitre 4.

1. D’abord la conclusion

Ce qu’est vraiment un fichier, et où vivent ses données

• Le cœur de NTFS, c’est la MFT (Master File Table). Tous les fichiers sont gérés comme des enregistrements du registre à l’intérieur de la MFT, et toute information sur un fichier se trouve soit « à l’intérieur de l’entrée de la MFT », soit « dans la zone hors MFT que désigne l’entrée » (chapitre 2).¹
• La substance d’un fichier est un ensemble d’attributs. Un petit fichier tient entièrement, données comprises, dans son enregistrement MFT (il est résident) ; un gros fichier ne conserve qu’une référence à une suite de clusters (il est non résident). C’est ce qui explique la lenteur du traitement d’un grand nombre de petits fichiers (chapitre 2).¹
• Un fichier peut avoir plusieurs lots de données (flux de données multiples). Les données du quotidien constituent le « flux sans nom » ; file.txt:nom permet d’ajouter des flux supplémentaires. C’est l’identité de Zone.Identifier (Mark of the Web) (chapitre 3).²

Les noms, et ce qui se passe à l’ouverture

• Le nom aussi est un attribut. Attacher plusieurs noms à un même enregistrement, c’est un lien physique. Le nom court 8.3 cohabite lui aussi, comme « un nom de plus » (chapitre 4).³⁴
• Le point d’analyse est le mécanisme officiel du « on ouvre, on se retrouve ailleurs ». Les liens symboliques, les jonctions et les fichiers à la demande de OneDrive sont tous des applications de cette même donnée étiquetée (chapitre 5).⁵⁶

Reprise après incident et allocation de l’espace disque

• Il existe deux journaux. $LogFile sert à la restauration de la cohérence des métadonnées (un journal préalable pour ne pas se corrompre), tandis que le journal USN sert à l’enregistrement de l’historique des changements (un registre de ce qui a changé). Leurs rôles sont entièrement différents (chapitre 6).⁷⁸
• « Taille » et « taille sur le disque » sont deux choses différentes. Les fichiers clairsemés et la compression créent cet écart. C’est aussi ici que se trouve le fond de « un fichier compressé ne devient jamais asynchrone », vu dans la partie 2 (chapitre 7).⁹¹⁰

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (35 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. Tout est un enregistrement de la MFT

2.1. Le registre du volume

Formater un volume NTFS crée la MFT (Master File Table), ainsi qu’une série de fichiers de métadonnées dont le nom commence par $. La MFT contient au moins une entrée pour chaque fichier du volume, et cela inclut une entrée pour la MFT elle-même.¹

flowchart TB
    subgraph VOL["Volume NTFS"]
        MFT["$MFT — Master File Table<br/>Registre des enregistrements de tous les fichiers (y compris lui-même)"]
        LOG["$LogFile — journal de transactions des<br/>opérations de métadonnées (chapitre 6)"]
        BITMAP["$Bitmap — état d'occupation des clusters"]
        OTH["$Boot / $Secure / $UpCase et<br/>autres fichiers de métadonnées"]
        DATA["Zone de données utilisateur<br/>(emplacement des données non résidentes)"]
    end
    MFT -->|"les enregistrements désignent l'emplacement"| DATA

Figure 1 : Structure d’un volume NTFS. Conserver aussi les informations de gestion du système de fichiers sous forme de fichiers fait partie de la conception de NTFS.

L’information est dans l’enregistrement, ou dans la zone externe qu’il désigne

Taille, horodatages, autorisations d’accès, et jusqu’au contenu des données : toute information sur un fichier est stockée soit à l’intérieur de l’entrée de la MFT, soit dans une zone hors MFT dont l’entrée décrit l’emplacement.¹

Un enregistrement libéré par une suppression est réutilisé, mais la MFT elle-même ne rétrécit pas

Quand vous supprimez un fichier, son entrée est marquée comme libre et sera réutilisée. En revanche, la taille de la MFT elle-même ne diminue pas.

Pour que la MFT puisse, en grandissant, utiliser autant d’espace contigu que possible, une zone MFT est réservée. La documentation officielle décrit aussi l’évolution en cours d’exploitation : à mesure que le volume se remplit, la MFT commence à se fragmenter.¹

2.2. Un fichier est un ensemble d’attributs, résidents et non résidents

Le contenu d’un enregistrement de fichier est une liste d’attributs. Les informations standard (horodatages, etc.), le nom de fichier, la sécurité et les données sont gérés ensemble dans ce paquet.

L’emplacement des données se sépare en deux cas.

La figure 2 montre la ramification, la figure 3 la différence de contenu de l’enregistrement.

flowchart TB
    subgraph REC["Enregistrement de fichier MFT (registre d'un fichier)"]
        STD["Attribut d'informations standard<br/>horodatages et indicateurs d'attributs"]
        FN["Attribut de nom de fichier<br/>(on peut en avoir plusieurs — chapitre 4)"]
        DATA["Attribut de données"]
    end
    Q{"Les données sont-elles petites"}
    RES["Résident (resident)<br/>le corps des données tient dans l'enregistrement<br/>une lecture se termine par le seul accès à la MFT"]
    NONRES["Non résident (non-resident)<br/>l'enregistrement ne tient qu'une référence à une suite de clusters<br/>les données réelles sont dans la zone utilisateur"]
    DATA --> Q
    Q -->|"jusqu'à quelques centaines d'octets"| RES
    Q -->|"au-delà"| NONRES

Figure 2 : Un enregistrement de fichier est un ensemble d’attributs. Si les données sont petites, elles restent « résidentes » dans l’enregistrement.

Mettre côte à côte le contenu du même enregistrement, en forme résidente et non résidente, rend la différence plus lisible.

flowchart LR
    subgraph RES2["Résident (resident) — petit fichier"]
        RA["Enregistrement de fichier MFT (longueur fixe)<br/>informations standard / nom de fichier / sécurité<br/>─────────────<br/>attribut de données = le contenu lui-même<br/>« réglage=1 » entre ici directement"]
        RB["Il n'y a pas d'autre emplacement sur le disque<br/>une lecture se termine par le seul accès à la MFT"]
        RA --> RB
    end
    subgraph NON2["Non résident (non-resident) — gros fichier"]
        NA["Enregistrement de fichier MFT (longueur fixe)<br/>informations standard / nom de fichier / sécurité<br/>─────────────<br/>attribut de données = table des data runs<br/>suite de « à partir d'où, combien de clusters »"]
        NB["Zone de données utilisateur<br/>run 1 : clusters contigus"]
        NC["Zone de données utilisateur<br/>run 2 : clusters contigus ailleurs"]
        NA -->|"désigne l'emplacement"| NB
        NA -->|"désigne l'emplacement"| NC
    end

Figure 3 : Résident contre non résident. En non résident, l’enregistrement ne tient que la table de « où se trouvent les données réelles, et en quelle quantité » (les data runs).

Plus le nombre de data runs augmente, plus il faut parcourir des zones dispersées pour lire un seul fichier. C’est précisément l’identité de la fragmentation évoquée ensuite.

Cette structure explique plusieurs phénomènes que l’on rencontre sur le terrain.

La copie de petits fichiers empile le travail de registre fichier par fichier

Pour chaque fichier, il y a création d’un enregistrement MFT, enregistrement du nom, réglage de la sécurité : autant d’opérations de métadonnées. Le travail de registre finit par dominer le transfert de données lui-même (et chacune de ces opérations devient aussi une cible d’inspection pour les filtres vus dans la partie 6).

La fragmentation, c’est des data runs répartis sur plusieurs zones

Les données non résidentes sont enregistrées comme « une suite d’intervalles contigus de clusters (runs) ». Quand on ne peut pas obtenir de zone contiguë, le nombre de runs augmente et les seeks nécessaires à la lecture aussi — c’est la fragmentation. On peut inspecter l’arrangement réel des runs avec fsutil file layout.

Un répertoire est aussi un fichier, porteur d’un index pour retrouver les noms

Un répertoire est « un fichier qui possède un index (index) des noms de fichiers vers les numéros d’enregistrement MFT ». Sur le registre, tout repose sur le même mécanisme.

3. Les données ne sont qu’un des flux

3.1. Un fichier, plusieurs suites d’octets

Sous NTFS, un même fichier peut avoir plusieurs flux de données. Ce que l’on lit et écrit habituellement avec ReadFile/WriteFile est le flux par défaut, sans nom, et la syntaxe nom_de_fichier:nom_du_flux permet de créer un flux de données alternatif (ADS).²

flowchart LR
    subgraph F["Le fichier report.docx (un enregistrement MFT)"]
        D0["Flux par défaut (sans nom)<br/>= le contenu que l'on voit d'habitude"]
        D1[":Zone.Identifier<br/>information d'origine (Mark of the Web)"]
        D2[":n'importe quel nom<br/>information annexe propre à une application"]
    end

Figure 4 : Flux de données multiples. Seul le flux par défaut apparaît dans l’affichage de la taille de l’Explorateur.

Zone.Identifier est le flux qui porte l’information d’origine

L’exemple le plus familier est Zone.Identifier. L’origine d’un fichier téléchargé par un navigateur (le fait qu’il vienne d’Internet, par exemple) y est enregistrée, et elle devient le matériau de décision de SmartScreen (« Windows a protégé votre PC ») et du Mode protégé d’Office.

Le mécanisme de l’avertissement a été traité dans « Pourquoi Windows affiche « Windows a protégé votre PC » ». Le mécanisme du côté qui stocke cette information d’origine, c’est le flux supplémentaire de NTFS.

3.2. Les pièges que rencontrent les développeurs

Un listing ou un affichage de taille ordinaires ne les montrent pas

Ils n’apparaissent ni dans la taille de l’Explorateur, ni dans un listing dir. On les vérifie avec dir /r ou avec streams de Sysinternals.¹¹

Ils se perdent selon la destination ou le chemin

Une ADS est une fonction de NTFS, donc elle tend à disparaître lors d’une copie vers une clé USB en FAT ou via un stockage cloud. « L’avertissement de téléchargement a disparu après la copie » vient de là.

On peut les utiliser depuis une application, mais pas y stocker les données métier

Il suffit d’inclure un deux-points dans le chemin, comme CreateFile("data.txt:meta", ...), pour lire et écrire.² C’est pratique, mais on hérite aussi de la propriété « on ne peut pas les transporter » du point précédent, ce n’est donc pas l’endroit où mettre le corps des données métier.

4. Le nom aussi est un attribut — liens physiques et noms 8.3

4.1. Liens physiques — plusieurs noms pour le même enregistrement

La figure 2 indiquait que l’on peut avoir plusieurs attributs de nom de fichier. Au sein d’un même volume, plusieurs chemins référencent un seul fichier — c’est un lien physique (CreateHardLink / mklink /H).³

flowchart TB
    subgraph DIR1["Index de C:\app\"]
        E1["config.json → enregistrement n°1234"]
    end
    subgraph DIR2["Index de C:\backup\"]
        E2["config-link.json → enregistrement n°1234"]
    end
    REC["Enregistrement MFT n°1234<br/>corps des données (ou référence aux runs)<br/>nombre de liens : 2"]
    E1 --> REC
    E2 --> REC

Figure 5 : Lien physique. Les index de répertoire pointent simplement vers le même enregistrement MFT, et les deux noms sont également « réels ».

Chaque nom pointe vers le même fichier

Modifier le fichier via n’importe lequel de ses noms, c’est le même fichier, donc le contenu coïncide immédiatement.³ Plutôt que de voir l’un comme l’original et l’autre comme une copie, il faut le voir comme une même entité portant des noms de même rang.

Distinguer le détachement d’un nom de la disparition de l’entité

Quand il y a des liens physiques, DeleteFile signifie « détacher un nom ». L’entité ne disparaît que lorsque le dernier nom a été détaché, que tous les handles ouverts ont été fermés, et que toutes les références internes au noyau, comme une section mappée en mémoire, ont elles aussi disparu.

Les deux étapes de la partie 1, cleanup (quand le dernier handle se ferme) et close (quand la dernière référence disparaît), concernent aussi cette durée de vie de la suppression.

Partager le contenu et actualiser l’affichage des attributs ne sont pas la même chose

Modifier un attribut via un lien peut laisser l’affichage apparent des attributs via un autre lien à une valeur ancienne. C’est une particularité d’affichage également notée dans la documentation officielle.³

4.2. Noms 8.3 — un nom caché de plus

Le nom court est un alias conservé pour la compatibilité

Pour des raisons de compatibilité historique, NTFS peut générer automatiquement un nom court au format 8.3, du type REPORT~1.DOC, pour un nom de fichier long. C’est lui aussi « un nom de plus » qui cohabite dans le même enregistrement.

Dans un dossier qui contient un grand nombre de fichiers, la génération des noms courts et l’évitement des collisions ont aussi un coût. fsutil 8dot3name permet de désactiver la génération ou de supprimer les noms courts existants.⁴

Cela dit, si une ancienne application enregistre un nom court dans un chemin de registre, la suppression la casse. C’est précisément pour cela qu’il existe une fonction d’inspection de l’impact avant le strip.⁴

Vérifier le paramètre de génération avant de s’appuyer sur les noms courts

L’existence même d’un nom court dépend de l’environnement. La valeur de registre qui fixe le comportement par défaut, NtfsDisable8dot3NameCreation, a les quatre réglages suivants.⁴

Avec 2, on peut basculer volume par volume. « Sous Windows, il y a forcément un nom court du type PROGRA~1 » n’est pas toujours vrai.

Avant d’écrire du code ou une procédure qui dépend des noms courts, vérifiez l’état avec fsutil 8dot3name query C:. En omettant le volume, on obtient le réglage par défaut commun à tous les volumes.

Les pièges autour des chemins et des noms (MAX_PATH, noms réservés, point final) sont traités en détail dans « MAX_PATH et les pièges des chemins et noms de fichiers Windows ». En rapprochant la résolution de noms de la partie 1 (le gestionnaire d’objets) et ce chapitre (les noms à l’intérieur du système de fichiers), on obtient le tableau d’ensemble des « noms » sous Windows.

5. Points d’analyse — le mécanisme de « on ouvre, on se retrouve ailleurs »

L’étiquette décide du traitement à l’ouverture

On peut attacher un point d’analyse à un fichier ou à un répertoire. Dans les faits, c’est un attribut qui porte une étiquette et des données définies par l’utilisateur.

À l’ouverture d’un fichier porteur d’un point d’analyse, le traitement bascule selon l’étiquette. Tantôt un pilote filtre qui comprend l’étiquette le prend en charge, tantôt une étiquette de type redirection de nom fait reprendre la résolution sur le chemin cible.⁵

sequenceDiagram
    participant App as Application
    participant IOM as Gestionnaire d'E/S
    participant FS as NTFS

    App->>IOM: CreateFile("C:\data\link.txt")
    IOM->>FS: IRP_MJ_CREATE (le monde de la partie 1)
    Note over FS: Point d'analyse trouvé sur la cible<br/>l'étiquette et les données sont renvoyées
    alt Lien symbolique / jonction (redirection de nom)
        FS-->>IOM: « le vrai emplacement est ici »
        IOM->>FS: La résolution reprend sur le chemin cible
    else Étiquette gérée par un filtre (fichiers cloud, etc.)
        Note over FS: Un filtre qui comprend l'étiquette<br/>prend le traitement en charge (partie 6)
    end

Figure 6 : Résolution d’un point d’analyse. C’est le crochet officiel qui s’intercale dans l’opération « ouvrir ».

Liens symboliques, jonctions et fichiers à la demande

Des fonctions familières s’alignent sur ce seul mécanisme.

• Lien symbolique (mklink) — un panneau qui conserve le chemin cible. Il peut pointer vers un autre volume ou un chemin UNC.⁶
• Jonction / point de montage — le mécanisme de longue date qui relie un répertoire à un emplacement d’un autre volume local.³
• Fichiers à la demande de OneDrive — un fichier dont les données réelles ne sont pas présentes localement est représenté par un point d’analyse, et à l’instant où on l’ouvre un filtre le télécharge et livre le contenu. C’est l’identité de « c’est visible dans l’Explorateur, mais l’ouvrir déclenche du trafic réseau » (le mécanisme des filtres lui-même vient dans la partie 6).

Un code qui parcourt une arborescence vérifie les points d’analyse

En pratique, l’important est que le bout d’un chemin n’est pas forcément l’emplacement local qu’il paraît être. Un code qui n’en tient pas compte marche sur des problèmes de ce genre.

• Un parcours récursif boucle sur une jonction.
• Les totaux de taille sont comptés deux fois.
• Une sauvegarde déclenche une hydratation massive de fichiers cloud.

Le point d’entrée pour s’en occuper est de vérifier FILE_ATTRIBUTE_REPARSE_POINT avec la famille FindFirstFile.⁵

6. Les deux journaux — $LogFile et le journal USN

On dit souvent « NTFS est un système de fichiers journalisé », mais NTFS a deux journaux aux rôles distincts. Les confondre, c’est mal lire ce qui est garanti.

flowchart TB
    subgraph J1["$LogFile — journal préalable (pour ne pas se corrompre)"]
        A1["Les opérations de métadonnées (mise à jour d'enregistrement, renommage, etc.)<br/>sont consignées dans le journal avant d'être exécutées"]
        A2["Au démarrage suivant une défaillance système<br/>le journal est rejoué pour restaurer la cohérence de la structure"]
        A1 --> A2
    end
    subgraph J2["Journal USN — historique des changements (pour savoir ce qui a changé)"]
        B1["À chaque modification d'un fichier ou d'un répertoire<br/>le contenu du changement et le nom sont enregistrés"]
        B2["Sauvegarde, index de recherche et outils de synchronisation<br/>apprennent « ce qui a changé depuis la dernière fois » sans parcours complet"]
        B1 --> B2
    end

Figure 7 : Les deux journaux. $LogFile existe pour ne pas se corrompre, le journal USN pour savoir ce qui a changé.

Mis en tableau, les écarts se présentent ainsi.

Tableau 2 : Les deux journaux comparés

$LogFile restaure la cohérence de la structure

$LogFile est un journal préalable des opérations de métadonnées. Après une défaillance système, NTFS utilise le journal et les informations de point de contrôle au démarrage suivant pour restaurer automatiquement la cohérence du système de fichiers.⁷

Ce qui est protégé ici, c’est la cohérence de la structure, pas le contenu des données écrites dans un fichier. Comme on l’a vu dans la partie 4, les données sales présentes dans le cache peuvent être perdues en cas de coupure de courant. Tenez séparées l’idée « on peut restaurer la structure » et l’idée « le contenu de la dernière écriture survit ».

Le journal USN est le registre pour savoir ce qui a changé depuis la dernière fois

Le journal USN enregistre, à chaque modification d’un fichier ou d’un répertoire du volume, le contenu du changement et le nom de la cible.⁸

C’est le mécanisme qui permet aux sauvegardes et aux indexeurs de ne ramasser que ce qui a changé depuis la dernière fois, sans parcours complet, et il sert aussi à éviter de reconstruire un index après un incident.⁸

Dans une investigation, fsutil usn readjournal peut servir de registre de recoupement qui complète les événements que FileSystemWatcher laisse passer. Pour les événements manqués eux-mêmes, voir « Guide pratique de FileSystemWatcher ».

7. Fichiers clairsemés et compression — quand il y a deux « tailles »

Sous NTFS, la longueur logique d’un fichier et l’espace réellement alloué sont gérés séparément. Ce sont la « Taille » et la « Taille sur le disque » de la boîte de propriétés. Deux choses, surtout, les écartent.

Le mode clairsemé conserve les plages de zéros comme des « trous »

Un fichier clairsemé n’alloue pas d’espace réel aux plages qui ne contiennent que des zéros et les gère comme des « trous ».⁹ Qu’un fichier de disque virtuel de 42 Go en taille logique n’utilise que 500 Mo sur le disque est un cas ordinaire. Lire un trou renvoie des zéros ; y écrire alloue exactement cette quantité.

flowchart LR
    subgraph L["Le fichier logique (taille : 1 Go)"]
        R1["Données 10 Mo"]
        H1["Trou (zéros) 500 Mo"]
        R2["Données 5 Mo"]
        H2["Trou (zéros) le reste"]
    end
    subgraph P["Allocation sur le disque (15 Mo + informations de gestion)"]
        A1["Run : substance de R1"]
        A2["Run : substance de R2"]
    end
    R1 --> A1
    R2 --> A2

Figure 8 : Fichier clairsemé. Un « trou » n’a pas d’allocation, donc la taille logique et la taille sur le disque s’écartent.

La compression concerne non seulement l’espace utilisé, mais aussi le comportement des E/S

La compression NTFS comprime et stocke les données par unité de compression.¹⁰ C’est transparent et pratique, mais le coût ne l’est pas : chaque lecture et chaque écriture déclenchent une décompression ou une recompression, et la fragmentation avance plus facilement. Et comme on l’a vu dans le chapitre 5 de la partie 2, l’accès à un fichier compressé ne devient jamais asynchrone (le système de fichiers le convertit en synchrone). C’est l’un des endroits à suspecter quand « j’ai passé en E/S asynchrones, mais certains fichiers n’ont pas accéléré ».

Quatre facteurs à vérifier quand les tailles ne correspondent pas

La taille réelle, fondée sur l’allocation, s’obtient avec GetCompressedFileSize. Quand « le total des tailles de fichiers » et « l’espace disque utilisé » ne correspondent pas, vérifiez les quatre points suivants dans l’ordre.

Séparer la longueur logique de l’espace alloué rend les écarts d’affichage beaucoup plus faciles à suivre.

8. Le voir de ses propres yeux

Cette fois encore, on peut tout observer sur sa propre machine Windows (une partie exige des privilèges d’administrateur). Pour que vous puissiez juger vous-même si le résultat est le bon, chaque commande est accompagnée d’une note sur où regarder et ce que cela vous dit.

8.1. Repérer une ADS à la ligne qui porte un nom de flux

:: Examiner les flux de données alternatifs
dir /r C:\Users\%USERNAME%\Downloads

Où regarder : sous les lignes de fichiers ordinaires, des lignes indentées de la forme nom_de_fichier:Zone.Identifier:$DATA s’alignent avec leur longueur. Si une telle ligne est là, ce fichier porte le Mark of the Web (chapitre 3). Les fichiers téléchargés par un navigateur l’ont ; ceux que vous avez créés vous-même ne l’ont pas. Exécuter la commande aux deux endroits et comparer rend la présence ou l’absence d’ADS évidente.

8.2. Examiner le stockage résident et non résident, et la disposition des données

:: Examiner la disposition d'un fichier sur la MFT (ses runs) et ses attributs
fsutil file layout C:\path\to\file.dat

:: Examiner les extents seulement (une sous-commande décrite dans la documentation officielle)
fsutil file queryextents C:\path\to\file.dat

Où regarder : layout aligne, par flux, la taille et la taille allouée, et pour un flux non résident une liste d’extents (triplets VCN, LCN et nombre de clusters). Un tout petit fichier qui n’affiche aucune ligne d’extent est résident (section 2.2) ; un fichier réparti sur plusieurs lignes est fragmenté. L’exécuter sur un fichier texte de quelques octets et sur un fichier de quelques centaines de mégaoctets, puis comparer, est le moyen le plus rapide de sentir la différence résident / non résident.

8.3. Comparer le paramètre de génération des noms courts avec les noms réels

:: Le paramètre de génération des noms courts 8.3, et les noms courts existants
fsutil 8dot3name query C:
dir /x

Où regarder : query indique si la génération des noms courts est activée ou désactivée sur ce volume (en omettant le volume, on obtient le réglage par défaut commun à tous les volumes).⁴ dir /x affiche une colonne de noms courts à côté des noms longs, donc une colonne vide signifie qu’aucun nom court n’a été créé. Cela permet de confirmer, dans votre propre environnement, le « il n’y a pas forcément de nom court » de la section 4.2.

8.4. Examiner l’état du journal USN et la progression de l’enregistrement

:: L'état du journal USN
fsutil usn queryjournal C:

Où regarder : s’affichent l’identifiant du journal, la plage des USN valides (First USN / Next USN), la taille maximale cible (MaximumSize) et l’unité d’allocation (AllocationDelta).¹² Créez un fichier et relancez : Next USN devrait avoir avancé, ce qui confirme que les changements sont enregistrés. MaximumSize est l’ordre de grandeur de « jusqu’où on peut remonter » abordé au chapitre 6. Sur un volume où le journal est désactivé, la commande renvoie une erreur.

8.5. Examiner l’attribut et l’étiquette d’un point d’analyse

:: Vérifier les points d'analyse (la cible et l'étiquette)
dir /aL C:\Users\%USERNAME%
fsutil reparsepoint query "C:\Users\%USERNAME%\OneDrive"

Où regarder : ce qui apparaît dans dir /aL est un point d’analyse (quelque chose pour lequel FILE_ATTRIBUTE_REPARSE_POINT est positionné). Les liens symboliques et les jonctions s’affichent avec un type comme <SYMLINKD> ou <JUNCTION>. fsutil reparsepoint query affiche la valeur de l’étiquette de reparse et, pour une étiquette de type redirection de nom, le chemin cible. Pointer la commande vers une cible qui n’est pas un point d’analyse renvoie une erreur : obtenir une erreur est donc elle-même la confirmation qu’« il s’agit ici d’un dossier ordinaire ».

8.6. Suivre les opérations réelles sur les fichiers avec Procmon

En suivant les opérations sur les fichiers avec Procmon, les personnages de cet article défilent sous leur vrai nom (écritures dans $LogFile, chemins portant un nom de flux, traitement des points d’analyse). Pour son utilisation, voir « Guide pratique de Process Monitor (ProcMon) ».

9. Résumé

• Le cœur de NTFS, c’est la MFT. Tous les fichiers sont des enregistrements du registre, et l’information se trouve soit « à l’intérieur de l’enregistrement », soit « dans la zone externe que désigne l’enregistrement ». Les petites données sont résidentes, les grandes sont référencées par des runs : la lenteur du traitement d’un grand nombre de petits fichiers, tout comme la fragmentation, sont des conséquences de cette structure.¹
• Un fichier peut avoir plusieurs flux de données. Zone.Identifier (Mark of the Web) n’est rien d’autre qu’une ADS : elle se voit avec dir /r, et ne voyage pas hors de NTFS.²¹¹
• Le nom est un attribut, et il peut y en avoir plusieurs. Un lien physique est un nom de même rang pointant vers le même enregistrement ; le nom 8.3 est un nom de plus, conservé pour la compatibilité. « Suppression » signifie « détacher un nom », et l’entité elle-même ne disparaît que lorsque le dernier nom, le dernier handle et toutes les références internes au noyau (section mappée, etc.) ont disparu.³⁴
• Le point d’analyse est le crochet officiel de l’« ouverture », et les liens symboliques, les jonctions et les fichiers à la demande en sont tous des applications. Un code qui parcourt une arborescence doit tenir compte de FILE_ATTRIBUTE_REPARSE_POINT.⁵⁶
• Il y a deux journaux. $LogFile restaure la cohérence de la structure (pour ne pas se corrompre) ; le journal USN est l’historique des changements (ce qui a changé). « C’est journalisé, donc les données aussi sont sûres » ne s’ensuit pas — la durabilité des données se construit avec les outils de la partie 4.⁷⁸
• La taille logique et l’allocation sont deux choses distinctes. Mode clairsemé, compression, ADS et arrondi au cluster sont les quatre grandes causes du « les tailles ne correspondent pas ». Avec le fait qu’un fichier compressé ne passe jamais en asynchrone, c’est un tiroir à garder sous la main pour les investigations de performance.⁹¹⁰

La suite, et le dernier volet, est la partie 6 : « Pilotes filtres et minifiltres — pourquoi Procmon et les antivirus peuvent intercepter les E/S ». Comment les « intermédiaires » apparus par intermittence depuis la partie 1 — antivirus, Procmon, OneDrive, chiffrement — interceptent-ils réellement les E/S ? En guise de point d’orgue de la série, nous révélerons la véritable identité des habitants installés dans les interstices de la pile de périphériques.

Articles connexes

• Les profondeurs de l’E/S Windows (partie 1) — Chaque lecture et écriture devient un IRP : la vue d’ensemble du système d’E/S
• Les profondeurs de l’E/S Windows (partie 2) — E/S synchrones et asynchrones : ce que signifie vraiment OVERLAPPED
• Les profondeurs de l’E/S Windows (partie 4) — Le gestionnaire de cache : quand votre WriteFile atteint-il vraiment le disque ?
• Pourquoi Windows affiche « Windows a protégé votre PC »
• MAX_PATH et les pièges des chemins et noms de fichiers Windows — la limite de 260 caractères, les noms réservés, les points de fin et la casse
• Guide pratique de FileSystemWatcher - Gérer les événements manqués et les doublons
• Les pièges des lecteurs réseau et des chemins UNC — Travailler avec un serveur de fichiers (dossier partagé) depuis une application métier
• Guide pratique de Process Monitor (ProcMon) — identifier en 10 minutes un « paramètre non pris en compte » ou un ACCESS DENIED

Domaines de conseil associés

KomuraSoft LLC prend en charge la conception et l’investigation des applications métier Windows dont les comportements déroutants — taille de fichier, performances de copie, bugs liés aux liens ou aux flux — trouvent leur origine dans le fonctionnement de NTFS.

• Développement d’applications Windows
• Investigation de bugs et analyse de cause racine
• Réutilisation des actifs existants et accompagnement à la migration
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Qu'est-ce que la MFT (Master File Table) ?

C'est la structure de données au cœur d'un volume NTFS : un registre qui contient au moins une entrée (un enregistrement de fichier) pour chaque fichier du volume, y compris une entrée pour la MFT elle-même. Tout ce qui concerne un fichier — sa taille, ses horodatages, ses autorisations d'accès, et jusqu'au contenu des données lui-même — est stocké soit à l'intérieur d'une entrée de la MFT, soit dans une zone hors MFT que l'entrée désigne. Un petit fichier tient entièrement, données comprises, dans son entrée de MFT (il est résident) ; un gros fichier ne conserve dans son entrée qu'une référence à l'emplacement de ses données (une suite de clusters) (il est non résident). Supprimer un fichier marque son entrée comme libre pour réutilisation, mais la taille de la MFT elle-même ne diminue jamais.

Qu'est-ce que la donnée invisible « Zone.Identifier » attachée à un fichier ?

C'est l'un des flux de données multiples de NTFS (un flux de données alternatif). Sous NTFS, un même fichier peut contenir plusieurs suites d'octets (flux) ; ce que l'on lit et écrit habituellement est le flux par défaut, sans nom. Dans un flux supplémentaire désigné par deux-points, comme « file.txt:Zone.Identifier », Windows enregistre la provenance du fichier (par exemple le fait qu'il a été téléchargé depuis Internet). C'est ce qu'on appelle le Mark of the Web, un élément utilisé par SmartScreen et par le Mode protégé d'Office pour leurs décisions. Les flux alternatifs n'apparaissent pas dans l'affichage de la taille de l'Explorateur ; on peut les vérifier avec la commande dir /r ou l'outil streams de Sysinternals. Notez aussi qu'ils ne sont pas conservés lors d'une copie vers un système de fichiers autre que NTFS, comme FAT.

Quelle est la différence entre un lien physique et un lien symbolique ?

Un lien physique, c'est « un nom de plus, de même rang, qui pointe vers la même entité de fichier (le même enregistrement MFT) ». Il ne peut être créé qu'au sein d'un même volume ; quel que soit le nom utilisé pour y accéder, c'est le même fichier, et supprimer un nom ne fait pas disparaître le fichier tant qu'un autre nom subsiste. Un lien symbolique est « un panneau indicateur qui redirige vers un autre chemin », implémenté comme un point d'analyse. Comme il ne conserve que la chaîne de caractères du chemin cible, il peut pointer vers un autre volume ou un emplacement distant, mais devient une impasse si la cible disparaît. En pratique, la règle de base est la suivante : le lien physique partage l'entité (ce qui change le sens de la suppression), le lien symbolique redirige un chemin (pour un déplacement ou une redirection).

NTFS est un système de fichiers journalisé : cela signifie-t-il que les données survivent à une coupure de courant ?

Il faut comprendre précisément ce qui est protégé. Ce que protège le journal de transactions de NTFS ($LogFile), c'est la cohérence de la structure du système de fichiers (ses métadonnées). Même en cas de défaillance système, NTFS restaure automatiquement la cohérence à l'aide du journal au démarrage suivant, ce qui évite que le volume ne devienne corrompu et illisible. Mais cela ne signifie pas que le contenu même du fichier en cours d'écriture est restauré. Comme nous l'avons vu dans la partie 4 de la série, les données sales présentes dans le cache sont perdues en cas de coupure de courant. Autrement dit, la bonne compréhension est : « le volume ne se corrompt pas, mais le contenu de la dernière écriture peut disparaître ». Si vous avez besoin de la durabilité des données elles-mêmes, il faut la construire avec FlushFileBuffers, WRITE_THROUGH, ou une conception d'écriture côté application (fichier temporaire puis renommage, etc.).

Pourquoi la « taille » d'un fichier diffère-t-elle de sa « taille sur le disque » ?

Parce que NTFS gère séparément la longueur logique d'un fichier et l'espace disque réellement alloué. Même un fichier ordinaire présente un écart, car l'allocation est arrondie à l'unité de cluster (4 Ko par défaut), mais l'écart devient important pour les fichiers clairsemés et les fichiers compressés. Un fichier clairsemé n'alloue pas d'espace réel aux plages qui ne contiennent que des zéros ; il les gère comme des « trous ». Il est donc parfaitement possible qu'un fichier de plusieurs gigaoctets en taille logique n'occupe que quelques mégaoctets sur le disque. Un fichier compressé n'a que sa taille après compression qui est allouée. À l'inverse, si la « taille sur le disque » paraît plus grande, la cause est souvent l'arrondi au cluster ou un flux de données alternatif.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.