J'ai récemment heurté une fonctionnalité étrange de Microsoft:
supposons que notre dossier a) Invocation de Selon Microsoft Ceci est le comportement attendu (voir la note dans MSDN ).
Mes questions sont:
Pourquoi Microsoft a-t-il décidé d'avoir une fonctionnalité aussi étrange?
Comment puis-je surmonter ce problème? c: \ tmp123 contient 3 fichiers -
1.txt
2.txtx
3.txtxt
Directory.getfiles (@ "c: \ tmp123", "* .txt") rendements dans 3 articles retournés.
b) Invocation de Directory.getfiles (@ "c: \ tmp123", "* .txtx") rendements dans 1 articles retournés.
IE Comment ai-je un modèle de recherche qui retournerait *. txt extension uniquement et ne renvoie pas *. TXTX , *. TXTSTARNGEFCONCÉculant , etc. ?
4 Réponses :
Je serais prêt à miser, c'est quelque chose à voir avec la compatibilité en arrière. Je ne vois pas ce problème exact mentionné, mais Ce Raymond Chen Blogpost mentionne un certain nombre de bizarreries dans ce domaine:
[...] quelques bizarreries de l'algorithme de correspondance FCB persistent dans Win32 parce que ils sont devenus idiom.
Par exemple, si votre motif se termine dans
. * , le. * est ignoré. Sans cette règle, le modèle*. * ne correspondrait que fichiers qui contenaient un point, qui briserait probablement 90% de tous les fichiers de lots sur la planète, ainsi que la mémoire musculaire de tout le monde, puisque Tout le monde exécutant Windows NT 3.1 a grandi dans un monde où*. * signifiait Tous les fichiers.comme un autre exemple, un motif qui se termine par un point ne fait pas réellement que correspond à des fichiers qui se terminent par un point; Il correspond aux fichiers sans extension. Et un point d'interrogation peut correspondre à zéro caractères s'il vient immédiatement avant un point.
La raison en est la compatibilité à l'envers.
Windows a été initialement construit comme une interface graphique au-dessus de MSDO qui n'avait que des fichiers avec 8 caractères pour le nom et un maximum de 3 pour l'extension. Les extensions vers les systèmes de fichiers MSDOS ont permis à Windows d'avoir des noms de fichiers et des extensions plus longs, mais ils apparaîtraient toujours comme 8,3 noms de fichiers dans MSDOS.
Étant donné que l'invite de commande sous Windows est une évolution de l'ancien interprète de commande dans MSDO, cela signifie que certains comportements "anachronistiques" (comme le modèle de recherche de 3 lettres) ont été conservés afin que des applications et des scripts construits dans les "vieux jours" ou par " Les anciens minuteries "ne parsaient pas.
(un autre exemple est le fait que la plupart des systèmes de fichiers Windows sont insensibles en cas de cas, oui, vous devinez, car le MSDOS one n'avait pas de boîtier)
Si vous voulez une solution de contournement, vous pouvez simplement récupérer tous les chemins de fichiers , puis les filtrer par extension au besoin
Voici une autre solution de contournement qui vous aidera à filtrer des fichiers avec des extensions telles que ".txtxt":