Si vous travaillez assez longtemps avec Windows, en particulier avec des dossiers et des fichiers longs, vous rencontrerez une erreur bizarre : Windows signale que le chemin du dossier ou le nom du fichier est trop long pour être déplacé vers une nouvelle destination ou même supprimé. Alors, l'autre jour, je réorganisais des fichiers sur mon ordinateur, créant des dossiers, ce genre de choses. Ensuite, lorsque je déplaçais des fichiers dans un dossier, j'obtenais un message, indiquant que le chemin du dossier résultant serait trop long. J'étais confus. Je sais que chaque système d'exploitation depuis DOS prend en charge les noms de fichiers longs, mais Windows prétend que le chemin est trop long? Pourquoi cela arrive-t-il?

Sincèrement,

M. Désorganisé

Le problème que vous rencontrez est une intersection malheureuse de deux systèmes qui, dans ce cas, génère une erreur. Pour comprendre exactement d'où vient l'erreur, nous devons creuser dans l'histoire des noms de fichiers longs (LFN) et comment Windows interagit avec eux avant de plonger dans des solutions.

Les noms de fichiers longs ont été introduits, via l'architecture MS-DOS sous-jacente , dans Windows 95. Le nouveau système LFN autorisé pour les noms de fichiers et de répertoires de 255 caractères maximum. Il s'agissait d'une extension bienvenue du système de noms de fichiers précédent, généralement appelé 8.3 nom de fichier car le nom était limité à huit caractères et à une extension à trois chiffres, mais également connu sous le nom Short File Name (SFN). Comme vous pouvez l'imaginer, à l'époque, il y avait encore beaucoup d'applications sous DOS et il y avait plus de quelques casse-tête qui essayaient de faire en sorte que les nouveaux LFN et les SFN hérités se jouent bien les uns avec les autres. Si vous avez déjà rencontré une ancienne disquette ou un CD-ROM avec des fichiers bizarrement tronqués (comme abcdef ~ 1.txt) ce nom de fichier a été coupé par une application héritée de SFN utilisant un LFN plus long et non supporté (comme abcdefghijk. txt).

Cependant, nous sommes loin du milieu des années 1990, et tout le long nom de fichier est (pour l'essentiel) fermement résolu. Si vous exécutez une version de Windows depuis les 10 dernières années, vous n'avez probablement jamais rencontré un conflit de longueur de nom de fichier comme nous l'avions l'habitude de revenir dans le DOS / Windows 95 jours. Cela dit, nous courons toujours dans le hoquet, comme vous l'avez découvert avec votre projet de nettoyage de disque. Mais pourquoi? Si le système Long Filename de Windows prend en charge les dossiers et les noms de fichiers de 255 caractères maximum par composant, quel mur utilisez-vous? Nous ne pouvons pas reprocher à NTFS (le système de fichiers utilisé par la grande majorité des machines Windows modernes) NTFS de prendre en charge un chaînage de dossiers et de noms de fichiers d'une longueur totale de 32 767 caractères. Cela va bien au-delà de la structure de répertoires typique dont la plupart des utilisateurs auraient besoin

Lorsque tout s'effondre, c'est une restriction artificielle que Windows empile au-dessus du système LFN / NTFS: la variable MAX_PATH. La variable MAX_PATH spécifie qu'une structure de répertoire complète dans Windows ne peut pas dépasser 260 caractères au total, y compris la lettre de lecteur, deux-points, barre oblique inverse et backlash null à la fin. Ainsi vous avez seulement un vrai MAX_PATH potentiel de 256 caractères, par exemple

C: votre-256-character-path

. Donc ce qui s'est passé quand vous nettoyiez votre ordinateur, c'est que vous aviez un répertoire avec un chemin déjà long (soit parce que les noms de dossier étaient longs, les noms de fichiers étaient longs, soit les deux) et lorsque vous avez essayé de déplacer un ou plusieurs de ces répertoires dans un autre répertoire avec un long chemin, la longueur totale du chemin le nom dépasse la limite de 260 caractères imposée par la variable MAX_PATH. Maintenant, vous pensez peut-être "Ah-hah! Nous allons juste changer la variable MAX_PATH et résoudre le problème! "Hélas, ce n'est pas si simple. Non seulement la variable MAX_PATH est-elle codée en dur dans Windows, mais même si vous aviez à subir les énormes tracas de la modification, vous finiriez par casser tellement que ça n'en valait pas la peine. Trop d'applications s'attendent à ce que la variable de chemin soit ce que Windows l'a longtemps spécifié. Nous ne pouvons pas tout changer sans créer un énorme gâchis.

Où cela vous laisse-t-il? Eh bien, la solution la plus simple consiste simplement à modifier les données de chemin. Par exemple, si vous avez une tonne d'articles sauvegardés où l'application / extension que vous avez utilisée pour les enregistrer sur le Web a créé un répertoire qui était le titre complet de l'article + le titre de l'article, puis le nom complet de l'article + le lead de l'article, il serait vraiment simple d'atteindre ou dépasser le MAX_PATH avec une seule sauvegarde. La modification de ces énormes titres de dossiers et d'articles à une taille plus raisonnable est un moyen facile de résoudre le problème.

Si vous avez un grand nombre de fichiers avec un long chemin et que vous ne voulez pas tous les modifier (ou vous voulez

supprimer

une tonne d'anciens répertoires qui sont trop longs pour que Windows puisse les gérer en cas de restriction par la variable MAX_PATH), il y a un travail en ligne de commande. Même si Windows est limité par la variable MAX_PATH, les ingénieurs de Windows ont réalisé qu'il y aurait des situations dans lesquelles les utilisateurs auraient besoin de gérer des noms de chemin plus longs. En tant que tel, l'API Windows a une fonction pour traiter les chemins extrêmement longs. Pour profiter de cette API et utiliser des outils de ligne de commande sur vos dossiers / noms de fichiers difficiles à manipuler, il vous suffit d'ajouter un nom de répertoire quelques caractères supplémentaires. Par exemple, si vous aviez une énorme structure de répertoires que vous vouliez supprimer (mais que vous aviez reçu une erreur en raison de la longueur du chemin), vous pourriez changer la commande de: rmdir c: documents some-really -super-long-dossier-nom-schéma

à:

rmdir \? c: documents certains-vraiment-super-long-dossier-nom-schéma

La clé est le ajout de la partie

\?

avant le début du chemin du fichier; ceci indique à Windows de ne pas tenir compte des limitations imposées par la variable MAX_PATH et d'interagir avec le chemin que vous venez de fournir tel qu'il est fourni / compris directement par le système de fichiers sous-jacent (qui peut clairement supporter un chemin plus long). Comme toujours, faites attention à l'invite de commande pour éviter de supprimer accidentellement les fichiers ou les répertoires que vous avez l'intention de laisser intacts.Si notre vue d'ensemble de ce problème vous a intriguée, consultez cet article de la bibliothèque Microsoft Developer Network, Naming Files, Chemins, et espaces de noms, pour plus d'informations sur ce qui se passe sous le capot.Vous avez une question technique urgente? Envoyez-nous un courriel à et nous ferons de notre mieux pour y répondre.

Comment trier les notifications iOS par application au lieu de Time

Par défaut, iOS affiche les notifications dans l'ordre dans lequel elles ont été reçues. Cela peut être pratique, bien sûr, mais si vous recevez beaucoup de notifications, il vous sera peut-être plus facile de grouper les notifications par l'application d'où elles viennent. Vous pouvez également trier les notifications manuellement afin que les applications qui vous intéressent affichent toujours leurs notifications en premier dans votre liste.

(how-to)

Comment regarder Netflix, Hulu et plus à travers un VPN sans être bloqué

Netflix a récemment annoncé son intention de sévir contre les VPN, proxy, et débloquer les utilisateurs DNS essayant d'accéder au contenu dans d'autres des pays. La bonne nouvelle: regarder des sites de streaming via un VPN peut être un peu plus difficile, mais cela sera toujours possible. Netflix n'est pas le seul, non plus: Hulu a réprimé les sites VPN pendant un certain temps que Netflix.

(how-to)