cmd.exe: "del * .txt" supprime également * .txt1 etc [duplicate]

Duplicate possible:
commande WinXP dir: les extensions 3 et 4 caractères sont les mêmes?

Je suis agacé par un comportement étrange de cmd.exe depuis longtemps (au moins WinXP et Windows7). Une commande comme del *.txtsupprimera également les *.txt1fichiers (n'importe quel nombre de caractères après «.txt» fera l'affaire). Est-ce un bug bien connu ou quoi?

C'est un peu connu à l'occasion?

Une explication du comportement est ici , avec une solution de contournement possible.

Résumé: Cela vient de la façon dont NTFS gère les noms de fichiers courts (8.3), pour la compatibilité avec des éléments plus anciens qui ne peuvent pas gérer les noms de fichiers longs "nouveaux". dir /xpeut être utilisé pour afficher le nom de fichier court, comme ceci:

C:\>dir /x *~*
 ...
02/25/2011  08:18 AM    <DIR>          DOCUME~1     Documents and Settings
05/28/2011  12:02 AM    <DIR>          PROGRA~1     Program Files
 ...

Les extensions de plus de trois caractères seront simplement tronquées pour leur nom de fichier court; donc .txt1, .txtxtxtxt, .txt_file, etc, tous devenus .txt.

Les fichiers contenant plus de 4 lettres dans l'extension (et d'autres règles s'appliquent bien sûr également), obtenez un nom court, ainsi par exemple "foo.txt1" a le nom court "foo ~ 1.txt". DEL(comme DIRet peut-être la plupart des autres cmd.execommandes intégrées) fonctionneront également sur les noms courts. Pour une discussion sur un sujet connexe, voir ici: http://blogs.msdn.com/b/oldnewthing/archive/2005/07/20/440918.aspx

Serait-ce sur un système de fichiers FAT / VFAT? Si c'est le cas, vous êtes mordu par le piratage utilisé pour représenter les noms qui ne rentrent pas dans le schéma 8.3; il y a une DIRoption qui vous montre les noms courts déformés, qui commenceront par le nom de fichier réel mais auront un ~et un numéro avant l'extension, puis l'extension est limitée à 3 caractères. (Exemple: C:\Program Filesse traduit généralement par C:\PROGRA~1.) Un caractère générique peut correspondre de manière inattendue à ces noms. Cela ne devrait pas se produire sur NTFS ou (je pense) sur les partages réseau. sauf que DOS n'est toujours pas mort, semble-t-il ...

Vous pouvez probablement utiliser la Forfilescommande pour une solution de contournement

Par exemple.

Forfiles  -s -m *.txt -c "cmd /C del /q @path"

Correspond uniquement aux txtfins.