Les données sont récupérées depuis le matériel à partir de différentes sources : disque dur, dvd, clés usb, partages réseaux, etc. Tous ont en commun d'utiliser des apis permettant de gérer les "entrées/sorties" des flux de données entre le stockage et votre programme qui manipule les données voulues. Les fichiers et répertoires ont un nomage qui sont une partie du concept du chemin, lequel lui-même correspond à l'adresse pour savoir ou se trouvent les données associées, que ce soit pour les retrouver sur le réseau durant une opération spécifique.

Nous allons passés en revus les éléments ci-dessous en revue sur les fichiers :

1. Nom des fichiers et répertoires
2. Chemins des fichiers / répertoires
3. Nom d'espaces

1. Nom des fichiers et répertoires

Tous les systèmes de fichiers suivent les mêmes conventions générales de dénomination 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, tel que NTFS, CDFS, exFAT, UDFS, FAT et FAT32, peut avoir des règles spécifiques et différentes concernant la formation des composants individuels dans le chemin vers un répertoire ou un fichier. Notez qu'un répertoire est simplement un fichier avec un attribut spécial le désignant comme répertoire, mais sinon il doit suivre toutes les mêmes règles de dénomination qu'un fichier normal. Étant donné que le terme répertoire se réfère simplement à un type spécial de fichier en ce qui concerne le système de fichiers, certains documents de référence utiliseront le terme général 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 dénomination ou d'utilisation ou les exemples d'un fichier doivent également s'appliquer à un répertoire. Le terme chemin fait référence à un ou plusieurs répertoires, des 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 peuvent varier en fonction du système de fichiers et du format de préfixe de nom de chemin utilisé. Ceci est encore compliqué 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 3 caractères pour l'extension, pour un total de 12 caractères, y compris le séparateur de points. Ceci est communément appelé un 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 toujours en charge la version 8.3 des noms de fichiers longs.

Conventions de nommage

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

• Utilisez un point pour séparer le nom du 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 divise le nom de fichier du chemin d'accès 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 il s'agit d'un caractère réservé qui sépare les noms en composants.
• Utilisez une barre oblique inverse si nécessaire dans le cadre des noms de volume, par exemple, le "C: \" dans "C: \ chemin \ fichier" ou le "\\ 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 Limitation de la longueur maximale du chemin.
• N'assumez pas la sensibilité à la casse. Par exemple, considérez que les noms OSCAR, Oscar et oscar sont identiques, même si certains systèmes de fichiers (comme un système de fichiers compatible POSIX) peuvent les considérer comme différents. Notez que NTFS prend en charge la sémantique POSIX pour la sensibilité à la casse, mais ce n'est pas le comportement par défaut. Pour plus d'informations, consultez CreateFile.
• Les indicateurs de volume (lettres de lecteur) sont également insensibles à 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 actuelle pour un nom, y compris les caractères Unicode et les caractères du jeu de caractères étendu (128–255), à l'exception des éléments suivants:
• Les caractères réservés suivants:
  • < (Inférieur à)
  • > (supérieur à)
  • : (deux-points)
  • " (double citation)
  • / (barre oblique)
  • \ (barre oblique inverse)
  • | (barre verticale ou tuyau)
  • ? (point d'interrogation)
  • * (astérisque)
  • Valeur entière zéro, parfois appelée caractère ASCII NUL.
  • Caractères dont les représentations entières sont comprises entre 1 et 31, sauf pour les 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 non autorisé par le système de fichiers cible.
• Utilisez un point comme composant de répertoire dans un chemin pour représenter le répertoire courant, par exemple ". \ Temp.txt". Pour plus d'informations, consultez Chemins.
• Utilisez deux points consécutifs (..) comme composant de répertoire dans un chemin pour représenter le parent du répertoire en cours, par exemple ".. \ temp.txt". Pour plus d'informations, consultez Chemins.
• N'utilisez pas les noms réservés suivants pour le nom d'un fichier:
  • CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, ​​COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8 et LPT9. Évitez également ces noms suivis immédiatement d'une extension; par exemple, NUL.txt n'est pas recommandé. Pour plus d'informations, consultez Espaces de noms
• 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 de tels noms, le shell Windows et l'interface utilisateur ne le font pas. Cependant, il est acceptable de spécifier un point comme premier caractère d'un nom. Par exemple, ".temp".

Nom court contre nom long

Un nom de fichier long est considéré comme tout nom de fichier qui dépasse la convention de dénomination de style MS-DOS (également appelée 8.3) courte. Lorsque 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 la stocker également sur le disque. Cet alias 8.3 peut être désactivé pour des raisons de performances à l'échelle du système ou pour un volume spécifié, en fonction du système de fichiers particulier.

Windows Server 2008, Windows Vista, Windows Server 2003 et Windows XP: l'alias 8.3 ne peut pas être désactivé pour les volumes spécifiés jusqu'à Windows 7 et Windows Server 2008 R2.

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

Pour demander des noms de fichiers 8.3, des noms de fichiers longs ou le chemin complet d'un fichier à partir du système, envisagez les options suivantes:

Pour obtenir la forme 8.3 d'un nom de fichier long, utilisez la fonction GetShortPathName.
Pour obtenir la version de nom de fichier long d'un nom court, utilisez la fonction GetLongPathName.
Pour obtenir le chemin d'accès complet à un fichier, utilisez la fonction GetFullPathName.
Sur les systèmes de fichiers plus récents, tels que NTFS, exFAT, UDFS et FAT32, Windows stocke les noms de fichiers longs sur le disque en Unicode, ce qui signifie que le nom de fichier long d'origine est toujours conservé. Cela 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 les partitions du système de fichiers NTFS et les partitions du système de fichiers Windows FAT sans perdre aucune information de nom de fichier. Cela peut ne pas être vrai pour l'ancien MS-DOS FAT 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 possible.

2. Chemins des fichiers / répertoires

Le chemin d'accès à 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. Il est souvent essentiel pour l'interprétation du système d'un chemin à quoi ressemble le début, ou le préfixe, du chemin. Ce préfixe détermine l'espace de noms utilisé par le chemin, ainsi que les caractères spéciaux utilisés et à quelle position dans le chemin, dernier caractère compris.

Si un composant du chemin est un nom de fichier, ce doit être le dernier composant.

Chaque composant du chemin sera également contraint par la longueur maximale spécifiée pour un système de fichiers particulier. En général, ces règles se divisent en deux catégories: courtes ou longues. 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 les règles de dénomination des fichiers s'appliquent également aux noms de répertoire. 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 fichier ou un nom de répertoire particulier.

Chemin absolu ou chemin relatif 

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

• Un nom UNC de n'importe quel format, qui commence toujours par deux barres obliques inversées ("\\"). Pour plus d'informations, consultez la section suivante.
• Un indicateur de disque avec une barre oblique inverse, par exemple "C: \" ou "d: \".
• Une seule barre oblique inverse, par exemple, "\ directory" ou "\ file.txt". Ceci est également appelé chemin absolu.

Si un nom de fichier commence par un seul identificateur de disque mais pas par la barre oblique inverse après les deux points, il est interprété comme un chemin relatif vers le répertoire actuel sur le lecteur avec la lettre spécifiée. Notez que le répertoire en cours peut ou non être le répertoire racine en fonction de ce qu'il a été défini lors de la dernière opération de «changement de répertoire» sur ce disque. Des exemples de ce format sont les suivants:

• «C: tmp.txt» fait référence à un fichier nommé «tmp.txt» dans le répertoire en cours sur le lecteur C.
• «C: tempdir \ tmp.txt» fait référence à un fichier dans un sous-répertoire du répertoire actuel sur le lecteur C.

Un chemin est également dit relatif s'il contient des "doubles points"; c'est-à-dire, deux périodes ensemble dans un composant du chemin. Ce spécificateur spécial est utilisé pour désigner le répertoire au-dessus du répertoire courant, autrement appelé "répertoire parent". Des exemples de ce format sont les suivants:

• ".. \ tmp.txt" spécifie un fichier nommé tmp.txt situé dans le parent du répertoire courant.
• ".. \ .. \ tmp.txt" spécifie un fichier situé à deux répertoires au-dessus du répertoire courant.
• ".. \ tempdir \ tmp.txt" spécifie un fichier nommé tmp.txt situé dans un répertoire nommé tempdir qui est un répertoire homologue du répertoire courant.

Les chemins relatifs peuvent combiner les deux types d'exemples, par exemple "C: .. \ tmp.txt". Ceci est utile car, bien que le système garde une trace du lecteur actuel avec le répertoire actuel de ce lecteur, il garde également une trace des répertoires actuels dans chacune des différentes lettres de lecteur (si votre système en a plus d'une), indépendamment de quel indicateur de lecteur est défini comme lecteur actuel.

Limitation sur la taille maximale du chemin

Dans l'API Windows (à quelques exceptions près décrites dans les paragraphes suivants), la longueur maximale d'un chemin est MAX_PATH, qui est définie comme 260 caractères. Un chemin d'accès local est structuré dans l'ordre suivant: lettre de lecteur, deux-points, barre oblique inverse, composants de nom séparés par des barres obliques inverses et un caractère nul de fin. Par exemple, le chemin maximal sur le lecteur D est "D: \ une chaîne de chemin de 256 caractères <NUL>" où "<NUL>" représente le caractère nul de fin invisible pour la page de codes système actuelle. (Les caractères <> sont utilisés ici pour la clarté visuelle et ne peuvent pas faire partie d'une chaîne de chemin valide.)

L'API Windows a de nombreuses fonctions qui ont également des versions Unicode pour permettre un chemin de longueur étendue pour une longueur de chemin totale maximale de 32 767 caractères. Ce type de chemin est composé de composants séparés par des barres obliques inverses, chacun jusqu'à la valeur renvoyée dans le paramètre lpMaximumComponentLength de la fonction GetVolumeInformation (cette valeur est généralement de 255 caractères). Pour spécifier un chemin de longueur étendue, utilisez le préfixe "\\? \". Par exemple, "\\? \ D: \ chemin très long".

Le préfixe "\\? \" Peut également être utilisé avec des chemins construits selon la convention de dénomination universelle (UNC). Pour spécifier un tel chemin à l'aide de UNC, utilisez le préfixe "\\? \ UNC \". Par exemple, "\\? \ UNC \ serveur \ partage", où "serveur" est le nom de l'ordinateur et "partage" est le nom du dossier partagé. Ces préfixes ne sont pas utilisés dans le cadre du chemin lui-même. Ils indiquent que le chemin doit être transmis au système avec une modification minimale, ce qui signifie que vous ne pouvez pas utiliser de barres obliques pour représenter les séparateurs de chemin, ou un point pour représenter le répertoire courant, ou des points doubles pour représenter le répertoire parent. Comme vous ne pouvez pas utiliser le préfixe "\\? \" Avec un chemin relatif, les chemins relatifs sont toujours limités à un total de MAX_PATH caractères.

Il n'est pas nécessaire d'effectuer une normalisation Unicode sur les chaînes de chemin et de nom de fichier à utiliser par les fonctions API d'E / S de fichier Windows, car le système de fichiers traite les chemins et les noms de fichier comme une séquence opaque de WCHAR. Toute normalisation requise par votre application doit être effectuée dans cet esprit, en dehors de tout appel aux fonctions API d'E / S de fichiers Windows associées.

Lorsque vous utilisez une API pour créer un répertoire, le chemin spécifié ne peut pas être si long que vous ne pouvez pas ajouter un nom de fichier 8.3 (c'est-à-dire que le nom du répertoire ne peut pas dépasser MAX_PATH moins 12).

Le shell et le système de fichiers ont des exigences différentes. Il est possible de créer un chemin avec l'API Windows que l'interface utilisateur du shell n'est pas capable d'interpréter correctement.

Activer les noms long à partir de Windows 10 Version 1607

À partir de Windows 10, version 1607, les limitations MAX_PATH ont été supprimées des fonctions courantes de fichiers et de répertoires Win32. Cependant, vous devez accepter le nouveau comportement.

Pour activer le nouveau comportement de chemin long, les deux conditions suivantes doivent être remplies:

La clé de registre HKLM \ SYSTEM \ CurrentControlSet \ Control \ FileSystem LongPathsEnabled (Type: REG_DWORD) doit exister et être définie sur 1. La valeur de la clé sera mise en cache par le système (par processus) après le premier appel à un fichier ou répertoire Win32 concerné fonction (voir ci-dessous la liste des fonctions). La clé de registre ne sera pas rechargée pendant la durée de vie du processus. Pour que toutes les applications du système reconnaissent la valeur de la clé, un redémarrage peut être nécessaire car certains processus peuvent avoir démarré avant que la clé ne soit définie.

Le manifeste d'application doit également inclure l'élément longPathAware.

Voici les fonctions de gestion de fichiers qui n'ont plus de restrictions MAX_PATH si vous optez pour le comportement de chemin long: CopyFileW, CopyFile2, CopyFileExW, CreateFileW, CreateFile2, CreateHardLinkW, CreateSymbolicLinkW, DeleteFileW, FindFirstFileW, FindFirstFileExWributes, FindNextFileWttAtt, GetFirstFileExWributes, FindNextFileWtt, GetFileFileExWributes, FindNextFileWtt GetFullPathNameW, GetLongPathNameW, MoveFileW, MoveFileExW, MoveFileWithProgressW, ReplaceFileW, SearchPathW, FindFirstFileNameW, FindNextFileNameW, FindFirstStreamW, FindNextStreamW, GetCompressedFileSizeW, GetFinalPathName

3. Nom d'espaces

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 de 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 construit au-dessus de l'espace de noms NT. Les premières versions de Windows définissaient également plusieurs noms prédéfinis ou réservés pour certains périphériques spéciaux tels que les ports de communication (série et parallèle) et la console d'affichage par défaut dans le cadre de ce que l'on appelle maintenant l'espace de noms de périphérique NT, et sont toujours pris en charge dans les versions actuelles de Windows pour la compatibilité descendante.

Namespace Win32

Le préfixage et les conventions 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 ne fonctionnent pas nécessairement tous avec les applications shell Windows telles que l'Explorateur Windows. Pour cette raison, il existe une gamme plus large de chemins possibles que ce qui est généralement disponible dans les applications 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 fichier, le préfixe "\\? \" D'une chaîne de chemin indique aux API Windows de désactiver toute analyse de 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 les chemins d'accès et les noms de fichiers volumineux, vous pouvez dépasser les limites MAX_PATH qui sont autrement appliquées par les API Windows. Pour plus d'informations sur la limitation de chemin maximale normale, consultez la section précédente Limitation de longueur de chemin maximale.

Puisqu'il désactive l'expansion automatique de la chaîne de chemin, le préfixe "\\? \" Permet également l'utilisation de ".." et "." dans les noms de chemin, ce qui peut être utile si vous essayez d'effectuer des opérations sur un fichier avec ces spécificateurs de chemin d'accès relatifs réservés dans le cadre du chemin d'accès complet.

Beaucoup d'API d'E / S de fichiers, mais pas toutes, prennent en charge "\\? \"; vous devriez regarder la rubrique de référence pour chaque API pour être sûr.

Namespace Win32 Device

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

Par exemple, si vous souhaitez ouvrir le port de communication série 1 du système, vous pouvez utiliser "COM1" dans l'appel à la fonction CreateFile. Cela fonctionne car COM1 – COM9 font partie des noms réservés dans l'espace de noms NT, bien que l'utilisation du préfixe «\\. \» Fonctionnera également avec ces noms de périphériques. Par comparaison, si vous disposez d'une carte d'extension série 100 ports installée et que vous souhaitez ouvrir COM56, vous ne pouvez pas l'ouvrir à l'aide de «COM56» car il n'y a pas d'espace de noms NT prédéfini pour COM56. Vous devrez l'ouvrir en utilisant "\\. \ COM56" car "\\. \" Accède directement à l'espace de noms du périphérique sans essayer de localiser un alias prédéfini.

Un autre exemple d'utilisation de l'espace de noms de périphérique Win32 est l'utilisation de la fonction CreateFile avec "\\. \ PhysicalDiskX" (où X est une valeur entière valide) ou "\\. \ CdRomX". Cela vous permet d'accéder directement à ces périphériques, en contournant le système de fichiers. Cela fonctionne car ces noms de périphériques sont créés par le système lorsque ces périphériques sont énumérés, et certains pilotes créeront é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 être également 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 les fichiers et les périphériques, selon les paramètres que vous utilisez.

Si vous travaillez avec les fonctions de l'API Windows, vous devez utiliser le préfixe "\\. \" Pour accéder uniquement aux périphériques et non aux fichiers.

La plupart des API ne prennent pas en charge "\\. \"; seuls ceux qui sont conçus pour fonctionner avec l'espace de noms du périphérique le reconnaîtront. Vérifiez toujours la rubrique de référence de chaque API pour être sûr.

Namespace NT

Il existe également des API qui permettent l'utilisation de la convention d'espace de noms NT, mais le gestionnaire d'objets Windows rend cela inutile dans la plupart des cas. Pour illustrer cela, il est utile de parcourir les espaces de noms Windows dans le navigateur d'objets système à l'aide de l'outil Windows Sysinternals WinObj. Lorsque vous exécutez cet outil, ce que vous voyez est l'espace de noms NT commençant à la racine, ou "\". Le sous-dossier appelé "Global ??" est l'endroit où réside l'espace de noms Win32. Les objets de périphérique nommés résident dans l'espace de noms NT dans le sous-répertoire "Périphérique". Ici, vous pouvez également trouver 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 périphérique représentant un volume serait quelque chose comme "HarddiskVolume1", bien que le suffixe numérique puisse varier. Le nom "DR0" dans le sous-répertoire "Harddisk0" est un exemple de l'objet périphérique représentant un disque, et ainsi de suite.

Pour rendre ces objets périphériques accessibles par les applications Windows, les pilotes de périphériques créent un lien symbolique (lien symbolique) dans l'espace de noms Win32, "Global ??", vers leurs objets périphériques respectifs. Par exemple, COM0 et COM1 sous le "Global ??" Les sous-répertoires sont simplement des liens symboliques vers Serial0 et Serial1, "C:" est un lien symbolique vers HarddiskVolume1, "Physicaldrive0" est un lien symbolique vers DR0, et ainsi de suite. Sans lien symbolique, un périphérique spécifié "Xxx" ne sera disponible pour aucune application Windows utilisant les conventions d'espace de noms Win32 comme décrit précédemment. Cependant, un handle peut être ouvert sur ce périphérique à l'aide de n'importe quelle API prenant en charge le chemin absolu de l'espace de noms NT au format "\ Device \ Xxx".

Avec l'ajout de la prise en charge multi-utilisateurs via les services Terminal Server et les machines virtuelles, il est devenu nécessaire de virtualiser le périphérique racine à l'échelle du système dans l'espace de noms Win32. Cela a été accompli en ajoutant le lien symbolique nommé "GLOBALROOT" à l'espace de noms Win32, que vous pouvez voir dans le "Global ??" sous-répertoire de l'outil de navigation WinObj discuté précédemment, et peut accéder via le chemin "\\? \ GLOBALROOT". Ce préfixe garantit que le chemin qui le suit recherche dans le véritable chemin racine du gestionnaire d'objets système et non dans un chemin dépendant de la session.