Nommage des fichiers, des chemins et des espaces de noms

Article
02/26/2024

Tous les systèmes de fichiers pris en charge par Windows utilisent le concept de fichiers et de répertoires pour accéder aux données stockées sur un disque ou un périphérique. Les développeurs Windows qui travaillent avec les API Windows pour les E/S de fichiers et de périphériques doivent comprendre les différentes règles, conventions et limitations des noms pour les fichiers et les répertoires.

Les données sont accessibles sur les disques, les périphériques et les partages réseau en utilisant des API d’E/S de fichiers. Les fichiers et répertoires ainsi que les espaces de noms font partie du concept de chemin, qui est une représentation sous forme de chaîne de l’emplacement où obtenir les données, qu’elles proviennent d’un disque, d’un périphérique ou d’une connexion réseau pour une opération spécifique.

Certains systèmes de fichiers, comme NTFS, prennent en charge les fichiers et répertoires liés, qui suivent également les conventions et les règles de nommage des fichiers, tout comme un fichier ou un répertoire standard. Pour plus d’informations, consultez Liens physiques et jonctions et Points de réanalyse et opérations de fichiers.

Pour en savoir plus sur la configuration de Windows pour le support des chemins d'accès longs, reportez-vous à la rubrique Limitation de la longueur maximale des chemins d'accès.

Noms de fichiers et de répertoires

Tous les systèmes de fichiers suivent les mêmes conventions générales de nommage pour un fichier individuel : un nom de fichier de base et une extension facultative, séparés par un point. Cependant, chaque système de fichiers, comme NTFS, CDFS, exFAT, UDFS, FAT et FAT32, peut avoir des règles spécifiques et différentes quant à la formation des composants individuels dans le chemin d’un répertoire ou d’un fichier. Notez qu’un répertoire est simplement un fichier avec un attribut spécial le désignant comme répertoire, mais qu’il doit suivre les mêmes règles de nommage qu’un fichier standard. Comme le terme répertoire fait simplement référence à un type spécial de fichier en ce qui concerne le système de fichiers, certains documents de référence utilisent le terme général de fichier pour englober à la fois les concepts de répertoires et de fichiers de données en tant que tels. Pour cette raison, sauf indication contraire, les règles de nommage ou d’utilisation, ou les exemples pour un fichier doivent également s’appliquer à un répertoire. Le terme chemin fait référence à un ou plusieurs répertoires, barres obliques inverses et éventuellement un nom de volume. Pour plus d’informations, consultez la section Chemins.

Les limitations du nombre de caractères peuvent également être différentes, et varier en fonction du système de fichiers et du format du préfixe de nom de chemin utilisé. Cette situation est encore compliquée par la prise en charge des mécanismes de compatibilité descendante. Par exemple, l’ancien système de fichiers MS-DOS FAT prend en charge un maximum de 8 caractères pour le nom de fichier de base et de 3 caractères pour l’extension, pour un total de 12 caractères, incluant le point séparateur. Ceci est couramment appelé nom de fichier 8.3. Les systèmes de fichiers Windows FAT et NTFS ne sont pas limités aux noms de fichiers 8.3, car ils prennent en charge les noms de fichiers longs, mais ils prennent néanmoins toujours en charge la version 8.3 des noms de fichiers longs.

Conventions d'affectation de noms

Les règles fondamentales suivantes permettent aux applications de créer et de traiter des noms valides pour les fichiers et les répertoires, quel que soit le système de fichiers :

Utilisez un point pour séparer le nom de fichier de base de l’extension dans le nom d’un répertoire ou d’un fichier.
Utilisez une barre oblique inverse (\) pour séparer les composants d’un chemin. La barre oblique inverse sépare le nom de fichier de son chemin, et un nom de répertoire d’un autre nom de répertoire dans un chemin. Vous ne pouvez pas utiliser de barre oblique inverse dans le nom du fichier ou du répertoire réel, car c’est un caractère réservé qui sépare les noms en composants.
Utilisez une barre oblique inverse si nécessaire dans les noms de volume, par exemple « C:\ » dans « C:\chemin\fichier » ou « \\serveur\partage » dans « \\serveur\partage\chemin\fichier » pour les noms UNC (Universal Naming Convention). Pour plus d’informations sur les noms UNC, consultez la section Limite maximale de la longueur des chemins.
Ne faites pas l’hypothèse que la casse est respectée. Par exemple, considérez les noms OSCAR, Oscar et oscar comme étant identiques, même si certains systèmes de fichiers (comme un système de fichiers conforme à POSIX) peuvent les considérer comme différents. Notez que NTFS prend en charge la sémantique POSIX pour le respect de la casse, mais ce n’est pas le comportement par défaut. Pour plus d’informations, consultez CreateFile.
De façon similaire, ce qui désigne les volumes (les lettres de lecteur) ne respectent pas la casse. Par exemple, « D:\ » et « d:\ » font référence au même volume.
Utilisez n’importe quel caractère de la page de codes active pour un nom, y compris les caractères Unicode et les caractères du jeu de caractères étendus (128 à 255), à l’exception des éléments suivants :
- Les caractères réservés suivants :
  - < (inférieur à)
  - > (supérieur(e) à)
  - : (deux-points)
  - " (guillemet double)
  - / (barre oblique)
  - \ (barre oblique inverse)
  - | (barre verticale ou pipe)
  - ? (point d’interrogation)
  - * (astérisque)
- Valeur entière zéro, parfois appelée caractère ASCII NULL.
- Caractères dont les représentations entières sont comprises entre 1 et 31, à l’exception des flux de données alternatifs, où ces caractères sont autorisés. Pour plus d’informations sur les flux de fichiers, consultez Flux de fichiers.
- Tout autre caractère que le système de fichiers cible n’autorise pas.
Utilisez un point comme composant d’un répertoire dans un chemin pour représenter le répertoire actif, par exemple « .\temp.txt ». Pour plus d’informations, consultez Chemins.
Utilisez deux points consécutifs comme composant d’un répertoire dans un chemin pour représenter le parent du répertoire actif, par exemple « ..\temp.txt ». Pour plus d’informations, consultez Chemins.
N’utilisez pas les noms réservés suivants comme nom d’un fichier :

CON, PRN, AUX, NUL, COM0, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, COM¹, COM², COM³, LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, LPT¹, LPT², et LPT³. Évitez également ces noms suivis immédiatement d’une extension ; par exemple, NUL.txt et NUL.tar.gz sont tous deux équivalents à NUL. Pour plus d’informations, consultez l’article Espaces de noms.

Remarque

Windows reconnaît les chiffres de 8 bits ISO/IEC 8859-1 en exposant ¹, ² et ³ comme des chiffres et les considère comme des parties valides des noms de périphériques COM# et LPT#, ce qui les rend réservés dans tous les répertoires. Par exemple, echo test > COM¹ ne parvient pas à créer un fichier.
Ne terminez pas un nom de fichier ou de répertoire par un espace ou un point. Bien que le système de fichiers sous-jacent puisse prendre en charge ces noms, ce n’est pas le cas du shell et de l’interface utilisateur Windows. Il est cependant acceptable de spécifier un point comme premier caractère d’un nom. Par exemple, « temp ».

Noms courts et Noms longs

Un nom de fichier est considéré comme long quand il dépasse la convention de nommage de style MS-DOS courte (également appelée 8.3). Quand vous créez un nom de fichier long, Windows peut également créer une forme courte 8.3 du nom, appelée alias 8.3 ou nom court, et le stocker également sur le disque. Cette version 8.3 de l'aliasing peut être désactivée pour des raisons de performances, soit à l'échelle du système, soit pour un volume spécifique, en fonction du système de fichiers concerné.

Windows Server 2008, Windows Vista, Windows Server 2003 et Windows XP : les alias 8.3 ne peuvent pas être désactivés pour les volumes spécifiés avant Windows 7 et Windows Server 2008 R2.

Sur de nombreux systèmes de fichiers, un nom de fichier contient un tilde (~) dans chaque composant du nom qui est trop long pour se conformer aux règles de nommage de 8.3.

Remarque

Tous les systèmes de fichiers ne suivent pas la convention de substitution de tilde, et les systèmes peuvent être configurés pour désactiver la génération d’alias 8.3, même s’ils la prennent normalement en charge. Par conséquent, ne supposez pas que les alias 8.3 existent déjà sur un disque.

Pour demander des noms de fichiers 8.3, des noms de fichiers longs ou le chemin complet d’un fichier au système, considérez les options suivantes :

Pour obtenir la forme 8.3 d’un nom de fichier long, utilisez la fonction GetShortPathName.
Pour obtenir la version en nom de fichier long d’un nom court, utilisez la fonction GetLongPathName.
Pour obtenir le chemin complet d’un fichier, utilisez la fonction GetFullPathName.

Sur les systèmes de fichiers plus récents, comme NTFS, exFAT, UDFS et FAT32, Windows stocke les noms de fichiers longs sur le disque au format Unicode, ce qui signifie que le nom de fichier long d’origine est toujours conservé. C’est vrai même si un nom de fichier long contient des caractères étendus, quelle que soit la page de codes active pendant une opération de lecture ou d’écriture sur disque.

Les fichiers utilisant des noms de fichiers longs peuvent être copiés entre des partitions du système de fichiers NTFS et des partitions du système de fichiers Windows FAT sans perdre d’informations du nom de fichier. Cela peut ne pas être vrai pour le système MS-DOS FAT plus ancien et certains types de systèmes de fichiers CDFS (CD-ROM), selon le nom de fichier réel. Dans ce cas, le nom de fichier court est remplacé si c’est possible.

Chemins d'accès

Le chemin vers un fichier spécifié se compose d’un ou plusieurs composants, séparés par un caractère spécial (une barre oblique inverse), chaque composant étant généralement un nom de répertoire ou un nom de fichier, mais avec quelques exceptions notables décrites ci-dessous. Le début, ou le préfixe du chemin est souvent critique pour l’interprétation d’un chemin par le système. Ce préfixe détermine l’espace de noms utilisé par le chemin ainsi que les caractères spéciaux qui sont utilisés dans le chemin et à quelle position, y compris le dernier caractère.

Si un composant d’un chemin est un nom de fichier, il doit s’agir du dernier composant.

Chaque composant d’un chemin est également limité par la longueur maximale spécifiée pour un système de fichiers particulier. En général, ces règles se répartissent en deux catégories : court et long. Notez que les noms de répertoire sont stockés par le système de fichiers en tant que type spécial de fichier, mais que les règles de nommage des fichiers s’appliquent également aux noms de répertoires. Pour résumer, un chemin est simplement la représentation sous forme de chaîne de la hiérarchie entre tous les répertoires qui existent pour un nom de fichier ou de répertoire particulier.

Chemins d’accès complets et Chemins d’accès relatifs

Pour les fonctions d’API Windows qui manipulent des fichiers, les noms de fichiers peuvent souvent être relatifs au répertoire actif, tandis que certaines API nécessitent un chemin complet. Un nom de fichier est relatif au répertoire actif s’il ne commence pas par un des éléments suivants :

Un nom UNC de n’importe quel format, qui commence toujours par deux caractères de barre oblique inverse (« \\ »). Pour plus d'informations, consultez la section suivante.
Un élément désignant un disque avec une barre oblique inverse, par exemple « C:\ » ou « d:\ ».
Une seule barre oblique inverse, par exemple « \répertoire » ou « \fichier.txt ». Ceci s’appelle aussi un chemin absolu.

Si un nom de fichier commence seulement par un élément désignant un disque mais sans barre oblique inverse après les deux-points, il est interprété comme un chemin relatif au répertoire actif sur le lecteur avec la lettre spécifiée. Notez que le répertoire actif peut ou non être le répertoire racine, selon ce qui a été défini lors de l’opération « changer de répertoire » la plus récente sur ce disque. Voici des exemples de ce format :

« C:tmp.txt » fait référence à un fichier nommé « tmp.txt » dans le répertoire actif sur le lecteur C.
« C:tmpdir\tmp.txt » fait référence à un fichier dans un sous-répertoire du répertoire actif sur le lecteur C.

Un chemin est également dit relatif s’il contient des « points doubles », c’est-à-dire deux points ensemble dans un composant du chemin. Ce spécificateur spécial est utilisé pour désigner le répertoire au-dessus du répertoire actif, autrement appelé « répertoire parent ». Voici des exemples de ce format :

« ..\tmp.txt » spécifie un fichier nommé tmp.txt situé dans le parent du répertoire actif.
« ..\..\tmp.txt » spécifie un fichier qui se trouve deux répertoires au-dessus du répertoire actif.
« ..\tempdir\tmp.txt » spécifie un fichier nommé tmp.txt situé dans un répertoire nommé tempdir qui est un répertoire de même niveau que le répertoire actif.

Les chemins relatifs peuvent combiner les deux types d’exemples, par exemple « C:..\tmp.txt ». Ceci est pratique car, bien que le système effectue le suivi du lecteur actif ainsi que du répertoire actif de ce lecteur, il fait également le suivi des répertoires actifs dans chacune des différentes lettres de lecteur (si votre système en a plusieurs), quel que soit le lecteur défini comme lecteur actif.

Limitation de longueur maximale du chemin

Dans les éditions de Windows antérieures à Windows 10 version 1607, la longueur maximale d’un chemin est MAX_PATH, qui est défini sur 260 caractères. Dans les versions ultérieures de Windows, la modification d’une clé du Registre ou l’utilisation de l’outil Stratégie de groupe est nécessaire pour supprimer la limite. Pour plus d’informations, consultez Limite maximale de la longueur des chemins.

Espaces de noms

Il existe deux catégories principales de conventions d’espace de noms utilisées dans les API Windows, communément appelées espaces de noms NT et espaces de noms Win32. L’espace de noms NT a été conçu pour être l’espace de noms du niveau le plus bas, sur lequel d’autres sous-systèmes et espaces de noms peuvent exister, y compris le sous-système Win32 et par extension, les espaces de noms Win32. POSIX est un autre exemple de sous-système dans Windows qui est basé sur l’espace de noms NT. Les premières versions de Windows définissaient aussi plusieurs noms prédéfinis, ou réservés, pour certains périphériques spéciaux, comme les ports de communication (série et parallèle) et la console d’affichage par défaut dans le cadre de ce qui est maintenant appelé « espace de noms de périphériques NT », et ces noms sont toujours pris en charge dans les versions actuelles de Windows pour la compatibilité descendante.

Espaces de noms de fichiers Win32

Les conventions et préfixes de l’espace de noms Win32 sont résumés dans cette section et la section suivante, avec des descriptions de leur utilisation. Notez que ces exemples sont destinés à être utilisés avec les fonctions de l’API Windows et qu’ils ne fonctionnent pas nécessairement avec des applications du shell Windows, comme l’Explorateur Windows. Pour cette raison, il existe une plus grande gamme de chemins possibles que ce qui est généralement disponible dans les applications du shell Windows, et les applications Windows qui en tirent parti peuvent être développées en utilisant ces conventions d’espace de noms.

Pour les E/S de fichiers, le préfixe « \\?\ » d’une chaîne de chemin indique aux API Windows de désactiver l’analyse de la chaîne et d’envoyer la chaîne qui la suit directement au système de fichiers. Par exemple, si le système de fichiers prend en charge des chemins et des noms de fichiers longs, vous pouvez dépasser les limites de MAX_PATH qui sont normalement appliquées par les API Windows. Pour plus d’informations sur la limite maximale normale des chemins, consultez la section précédente Limite maximale de la longueur des chemins.

Comme il désactive l’expansion automatique de la chaîne du chemin, le préfixe « \\?\ » autorise également l’utilisation de « .. » et de « . » dans les noms de chemins, ce qui peut être utile si vous tentez d’effectuer des opérations sur un fichier avec ces spécificateurs de chemins relatifs réservés dans le cadre du chemin complet.

De nombreuses API d’E/S de fichiers, mais pas toutes, prennent en charge « \\?\ » ; vous devez examiner la rubrique de référence pour chaque API pour vous en assurer.

Notez que les API Unicode doivent être utilisées pour s'assurer que le préfixe "\?\" vous permet de dépasser le MAX_PATH.

Espaces de noms de périphériques Win32

Le préfixe « \\.\ » va accéder à l’espace de noms de périphériques Win32 au lieu de l’espace de noms de fichiers Win32. C’est ainsi que l’accès aux disques et volumes physiques s’effectue directement, sans passer par le système de fichiers, si l’API prend en charge ce type d’accès. Vous pouvez accéder ainsi à de nombreux périphériques autres que les disques (en utilisant par exemple les fonctions CreateFile et DefineDosDevice).

Par exemple, si vous souhaitez ouvrir le port 1 des communications série du système, vous pouvez utiliser « COM1 » dans l’appel de la fonction CreateFile. Ceci fonctionne, car COM1 à COM9 font partie des noms réservés dans l’espace de noms NT, bien que l’utilisation du préfixe « \\.\ » fonctionne également avec ces noms de périphériques. En comparaison, si vous avez installé une carte d’extension de 100 ports série et que vous voulez ouvrir COM56, vous ne pouvez pas l’ouvrir en utilisant « COM56 », car il n’existe pas d’espace de noms NT prédéfini pour COM56. Vous devez l’ouvrir en utilisant « \\.\COM56 », car « \\.\ » accède directement à l’espace de noms de périphériques sans essayer de trouver un alias prédéfini.

Un autre exemple d’utilisation de l’espace de noms de périphériques Win32 est l’utilisation de la fonction CreateFile avec « \\.\PhysicalDriveX » (où X est une valeur d’entier valide) ou « \\.\CdRomX ». Ceci vous permet d’accéder directement à ces périphériques, en contournant le système de fichiers. Ceci fonctionne, car ces noms de périphériques sont créés par le système quand ces périphériques sont énumérés, et certains pilotes créent également d’autres alias dans le système. Par exemple, le pilote de périphérique qui implémente le nom « C:\ » a son propre espace de noms qui se trouve également être le système de fichiers.

Les API qui passent par la fonction CreateFile fonctionnent généralement avec le préfixe « \\.\ », car CreateFile est la fonction utilisée pour ouvrir à la fois des fichiers et des périphériques, selon les paramètres que vous utilisez.

Si vous utilisez des fonctions d’API Windows, vous devez utiliser le préfixe « \\.\ » seulement pour accéder aux périphériques et non pas aux fichiers.

La plupart des API ne prennent pas en charge « \\.\ » ; seules celles qui sont conçues pour fonctionner avec l’espace de noms de périphériques le reconnaîtront. Pour en être sûr, vérifiez toujours la rubrique de référence pour chaque API.

Espaces de noms NT

Il existe également des API qui autorisent l’utilisation de la convention d’espace de noms NT, mais le Gestionnaire d’objets Windows rend cela inutile dans la plupart des cas. À titre d’exemple, il est utile de parcourir les espaces de noms Windows dans l’explorateur d’objets du système en utilisant l’outil Windows Sysinternals WinObj. Quand vous exécutez cet outil, vous voyez l’espace de noms NT commençant à la racine, ou « \ ». Le sous-dossier appelé « Global?? » est l’emplacement où se trouve l’espace de noms Win32. Les objets de périphériques nommés se trouvent dans l’espace de noms NT, dans le sous-répertoire « Device ». Vous pouvez également trouver ici Serial0 et Serial1, les objets de périphérique représentant les deux premiers ports COM, s’ils sont présents sur votre système. Un objet de périphérique représentant un volume serait quelque chose comme « HarddiskVolume1 », bien que le suffixe numérique puisse varier. Le nom « DR0 » sous le sous-répertoire « Harddisk0 » est un exemple d’objet de périphérique représentant un disque, etc.

Pour rendre ces objets de périphérique accessibles par des applications Windows, les pilotes de périphérique créent un lien symbolique (symlink) dans l’espace de noms Win32, « Global?? », vers leurs objets de périphérique respectifs. Par exemple, COM0 et COM1 sous le sous-répertoire « Global?? » sont simplement des liens symboliques vers Serial0 et Serial1, « C: » est un lien symbolique vers HarddiskVolume1, « Physicaldrive0 » est un lien symbolique vers DR0, etc. Sans un lien symbolique, un périphérique « Xxx » spécifié ne sera disponible pour aucune application Windows utilisant les conventions d’espace de noms Win32 comme décrit précédemment. Cependant, un descripteur peut être ouvert sur ce périphérique en utilisant des API qui prennent en charge le chemin absolu de l’espace de noms NT au format « \Device\Xxx ».

Avec l’ajout de la prise en charge multi-utilisateur via les services Terminal Server et les machines virtuelles, il est devenu plus tard nécessaire de virtualiser le périphérique racine à l’échelle du système au sein de l’espace de noms Win32. Ceci a été fait en ajoutant le lien symbolique nommé « GLOBALROOT » à l’espace de noms Win32, que vous pouvez voir dans le sous-répertoire « Global?? » de l’outil de navigateur WinObj précédemment mentionné, et vous pouvez y accéder via le chemin « \\?\GLOBALROOT ». Ce préfixe garantit que le chemin qui suit recherche dans le chemin racine réel du gestionnaire d’objets système et non pas dans un chemin dépendant de la session.