Windows 2000 inclut une version améliorée du système de fichiers NTFS qui gère le cryptage de fichier, la possibilité d'ajouter de l'espace disque à un volume NTFS sans redémarrage, le suivi des liaisons distribuées (qui permet de résoudre les raccourcis et les liaisons OLE (Object Linking and Embedding) dans les fichiers NTFS ayant fait l'objet d'une modification du nom ou du chemin d'accès) et des quotas de disque par utilisateur pour surveiller et limiter l'utilisation de l'espace disque, ainsi que de nombreuses améliorations des performances.

Jean-Claude Bellamy nous livre ses secrets :

Structure d'un secteur de boot

Adresse
(hexa)

Contenu

Taille
(octets)
000 Instruction de saut à la routine de boot 3
003 Nom du fabricant et n° version(p.ex.NTFS) 8
00B Octets par secteur (0x200 = 512) 2
00D Secteurs par cluster (variable) 1
00E Nbre secteurs réservés (0x00) 2
010 inutilisé (0x00) 1
011 inutilisé (0x0000) 2
013 inutilisé (0x0000) 2
015 Descripteur de support (0xF8 pour un disque dur) 1
016 inutilisé (0x0000) 2
018 Nbre de secteurs par piste (variable) 2
01A Nbre de têtes (variable) 2
01C Distance entre 1er secteur du volume et 1er secteur du support 4
020 inutilisé (0x0000) 4
024 inutilisé (0x0000) 4
028 Nombre total de secteurs 8
030 N°logique de cluster de $MFT (Master File Table) 8
038 N°logique de cluster de $MFTMirr (Miroir de Master File Table) 8
040 Nombre de cluster par segment de fichier 4
044 Nombre de clusters par block d'index 4
048 N° de série du disque (créé au formatage à partir de la date) 8
050 Checksum 4
054
à 1FD		 Routine de boot 426
1FE AA55 (code d'identification, id.secteur de partition) 2

Remarques :

  • La zone qui s'étend de l'offset 00B à l'offset 023 s'appelle "BIOS Parameter Block" (BPB) 
  • La zone qui s'étend de l'offset 024 à l'offset 053 s'appelle "extended BIOS Parameter Block" (EBPB) 
  • La routine de boot fait en réalité plus de 426 octets et peut s'étendre sur les 15 secteurs suivants
  • La MFT (Master File Table) d'une partition NTFS n'est pas située à une adresse fixe, comme peut l'être  la FAT (File Allocation Table) d'une partition FAT. Son emplacement est défini par le contenu de l'offset 030
  • Le nombre de secteurs par cluster dépend de la taille de la partition. Il est de 1 jusqu'à 512Mo, 2 jusqu'à 1 Go, ..., 64 jusqu'à 32 Go, et 128 au delà.

Structure de la MFT (Master File Table)

Bien que sa structure soit radicalement différente, la MFT est un peu à une partition "NTFS" ce que la FAT est à une partition "FAT". Cette table n'a pas d'emplacement prédéfini sur le disque, à la différence de la FAT qui se situe à partir du secteur 2 d'une partition FAT (et avec une taille fixe).
Son adresse est inscrite dans le secteur de boot (offset 0x30), et peut varier suivant les circonstances (secteur défectueux p.ex.), étant donné qu'un "mirroring" de cette table (adresse en 0x38) est effectué en permanence.

La MFT est constituée d'entrées de 1ko chacune, à raison d'une entrée par fichier (ou répertoire) existant dans la partition. Chaque entrée contient successivement les attributs suivants :

  • Informations standards : attributs "classiques" de fichier (Read only, System,..), dates de création, modification, accès, liens symboliques. 
    On retrouve ces mêmes informations dans le répertoire contenant le fichier
  • Nom : le nom du fichier en UNICODE. Il peut y avoir plusieurs noms (en particulier le nom "court" 8.3)
  • Descripteur de sécurité : informations de contrôle d'accès au fichier.
  • Données non nommées : le contenu (total ou partiel) du fichier sous la forme d'un flux "anonyme"
  • Données nommées : autre(s) flux de données, non anonyme(s) (facultatif(s))
  • Index : Seulement pour les gros répertoires
  • Filtre : Un filtre du système de fichiers utilisé lors de l'accès au fichier ou répertoire

Quand un nouveau fichier est créé, le système créé les attributs nécessaires dans une nouvelle entrée de la MFT, mais il y a un problème évident :

La plupart des attributs ont une taille variable (Nom(s), données) et dépassent facilement le ko.

  • Si ça peut tenir, l'attribut est appelé "attribut résident", et donc le fichier est contenu INTÉGRALEMENT dans la MFT.
  • Si ça ne tient pas, le système écrit le contenu de l'attribut ailleurs sur le disque, et inscrit un pointeur vers cette zone dans l'entrée de la MFT. (attribut non résident)

Un fichier raccourci (.lnk) arrive à tenir sans problème dans une entrée la MFT, si bien que son accès est très rapide. Par ailleurs, comme les attributs habituels des fichiers sont stockés dans la MFT, les opérations de recherches de fichiers (FindFirst, FindNext) ne nécessitent pas d'autre accès disque que celui de la MFT.
C'est pourquoi chercher un fichier sur une NTFS est beaucoup plus rapide que sur une FAT!

(En FAT, si on recherche p.ex. tous les .txt sur un disque, il va falloir parcourir toute l'arborescence de chaque sous-répertoire, donc vraisemblablement explorer tout le disque)

Au départ (NT 3.x), la taille de chaque entrée était de 4 ko, mais MicroSoft l'a réduite à 1 ko avec NT4 pour perdre moins de place dans la MFT.

Les flux multiples

Un fichier peut contenir plusieurs "flux", ou lots, ou "versions" de données. Cette fonctionnalité est très rarement employée pour l'instant (un fichier = un flux de données), avant tout pour des questions de compatibilité (il faut être en NTFS) mais elle peut (pourrait) s'avérer très pratique avec certains types de données.
C'est le cas p.ex. des bitmaps. On peut inclure à la fois le bitmap lui-même, mais aussi une "vignette". Ainsi, un éditeur de bitmap utilisant cette propriété, quand il va accéder à un fichier, pourra soit afficher le bitmap complet, soit la vue réduite, sans autre manipulation que de sélectionner le flux auquel il veut accéder.

De même, un traitement de texte pourra(it) stocker plusieurs versions du même document, dans un fichier unique!

Exercice sur les flux (très basique) (partition NTFS obligatoire) :

Dans une fenêtre de commande, taper les 2 commandes suivantes :

M:\>echo "May the Force be with You" > Starswar.txt:Yoda
on crée le fichier texte "Starswar.txt", dans lequel on crée un flux nommé "Yoda"

M:\>echo "You don't know the power of the dark side" > Starswar.txt:Vador
on ajoute à ce fichier un 2ème flux nommé "Vador"

Si maintenant on tape la commande "dir Starswar.txt", on risque d'être déçu :

M:\>dir Starswar.txt
Le volume dans le lecteur M s'appelle DOWNLOAD
Le numéro de série du volume est 5C8D-4ABF

Répertoire de M:\
25/11/99 14:09 0 Starswar.txt
1 fichier(s) 0 octets
56 837 632 octets libres

Cette taille de 0 octets peut surprendre, mais c'est du au fait que "dir" ne s'intéresse qu'aux flux anonymes (standards) !

On peut s'assurer que le fichier n'est pas vide en réalité :

M:\>more <Starswar.txt:Yoda
"May the Force be with You"

M:\>more <Starswar.txt:Vador
"You don't know the power of the dark side"

Si on édite avec notepad (ou autre) le fichier Stawswar.txt, on le découvrira vide! (parce que les éditeurs texte habituels savent accéder qu'aux flux anonymes)
(Ces flux nommés peuvent servir d'astuce pour stocker certaines infos confidentielles !!! ;+))

Les liens symboliques

Cette fonctionnalité existe depuis toujours, ou presque, dans UNIX! (et est requise d'ailleurs par tout OS conforme à POSIX)

Un lien symbolique (à ne pas confondre avec un raccourci) est un fichier virtuel qui pointe vers un fichier réel. Il va apparaître dans un répertoire cible, mais se limitera à une entrée dans le répertoire, et un lien symbolique dans la MFT, faisant la liaison entre le fichier réel et l'endroit où il apparaît virtuellement.

A l'opposé, un raccourci est un authentique fichier, bien réel, à extension ".lnk", qui contient des infos diverses qui seront interprétées par le shell pour aller chercher le fichier d'origine.
Un inconvénient d'un raccourci est qu'il ne "passe" pas les réseaux (si on monte un disque réseau, et que l'on clique sur un raccourci dans ce disque, on aura des surprises, le shell allant chercher le fichier sur la machine locale et non pas sur la machine distante). Il n'y a pas cet inconvénient avec un "vrai lien symbolique", puisque dès qu'un veut y accéder, il y a immédiatement un ré-aiguillage automatique vers le fichier d'origine.

Il faut bien avoir en tête savoir que les liens symboliques ne sont possibles qu'avec des partitions NTFS. Donc les logiciels habituels, prévus pour tourner indifféremment sur des FAT ou des NTFS, n'ont pas prévu cela.

Si on veut programmer un peu, on peut utiliser la (nouvelle) fonction suivante de la KERNEL32.DLL :

BOOL CreateHardLink(LPCTSTR pszFileName,
LPCTSTR pszExistingFileName,
LPSECURITY_ATTRIBUTES
lpSecurityAttributes);

cette fonction se trouve à l'index 59 (CreateHardLinkA) et 60 (CreateHardLinkW) (versions ANSI et UNICODE) de kernel32.dll

Pour créer un lien, on lui passe :

  • pszFileName : le nouveau chemin (= le lien)
  • pszExistingFileName : le chemin du fichier réel
  • lpSecurityAttributes : pointeur éventuel (car il peut être égal à "null") vers une structure contenant un nouveau descripteur de sécurité (cela permet d'avoir un contrôle d'accès au lien différent de celui du fichier réel)

Une fois que l'on a appelé "CreateHardLink", le répertoire donné pour le lien contient un nouveau fichier (en apparence). Si on ouvre ce fichier, on ouvre en réalité le fichier d'origine.

Conclusion

Tout ce qui précède n'est qu'un aperçu des possibilités offertes par NTFS et sa MFT. Beaucoup sont encore inutilisées, ou partiellement utilisées.
Au niveau des inconvénients, la MFT peut s'avérer assez gourmande en espace disque (puisque 1 ko par fichier quel qu'il soit, en plus de la taille réelle du fichier s'il est >1 ko)

Lire le NTFS sous Windows 9x/ME ?

Le programme NTFS for Windows 98 remplit parfaitement cette mission.