{"id":1513,"date":"2014-03-13T07:00:00","date_gmt":"2014-03-13T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2014\/03\/13\/why-does-the-directory-getfiles-method-sometimes-ignore-html-files-when-i-ask-for-htm\/"},"modified":"2014-03-13T07:00:00","modified_gmt":"2014-03-13T07:00:00","slug":"why-does-the-directory-getfiles-method-sometimes-ignore-html-files-when-i-ask-for-htm","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20140313-00\/?p=1513","title":{"rendered":"Why does the Directory.GetFiles method sometimes ignore *.html files when I ask for *.htm?"},"content":{"rendered":"<p>The <a href=\"http:\/\/msdn.microsoft.com\/en-us\/library\/ms143316(v=vs.110).aspx\"> documentation for the <code>Directory.Get&shy;Files<\/code> method<\/a> says<\/p>\n<blockquote class=\"q\"><p> When using the asterisk wildcard character in a <i>search&shy;Pattern<\/i>, such as &#8220;*.txt&#8221;, the matching behavior when the extension is exactly three characters long is different than when the extension is more or less than three characters long. A <i>search&shy;Pattern<\/i> with a file extension of exactly three characters returns files having an extension of three or more characters, where the first three characters match the file extension specified in the <i>search&shy;Pattern<\/i>. A <i>search&shy;Pattern<\/i> with a file extension of one, two, or more than three characters returns only files having extensions of exactly that length that match the file extension specified in the <i>search&shy;Pattern<\/i>. When using the question mark wildcard character, this method returns only files that match the specified file extension. For example, given two files, &#8220;file1.txt&#8221; and &#8220;file1.txtother&#8221;, in a directory, a search pattern of &#8220;file?.txt&#8221; returns just the first file, while a search pattern of &#8220;file*.txt&#8221; returns both files. <\/p><\/blockquote>\n<p> A customer reported that one of their programs stopped working, and they traced the problem to the fact that a search for <code>*.htm<\/code> on some machines was no longer return files like <code>awesome.html<\/code>, contrary to the documentation. What&#8217;s going on?\n What&#8217;s going on is that the documentation is trying too hard to explain an observed behavior. (My guess is that some other customer reported the behavior, and the documentation team incorporated the customer&#8217;s observations into the documentation without really thinking it through.)\n The real issue is that the <code>Get&shy;Files<\/code> method matches against both short file names and long file names. If a long file name has an extension that is longer than three characters, the extension is truncated to form the short file name. And it is that short file name that gets matched by <code>*.htm<\/code> or <code>*.txt<\/code>.\n Even as originally written, in the presence of short file names, the documentation is wrong, because it would imply that a search for <code>reallylong*.txt<\/code> could match <code>reallylong_filename.txtother<\/code>. But try it: It doesn&#8217;t. That&#8217;s because the short name is probably <code>REALLY~1.TXT<\/code>, and that doesn&#8217;t match <code>reallylong*.txt<\/code>.\n What happened is that short file name generation was disabled on the drive at the time the files were created, so there was no short file name available, so there was consequently no <code>SHORTN~1.HTM<\/code> file to match against.<\/p>\n<p> The documentation should really say something more like this: <\/p>\n<blockquote class=\"q\"><p> Because this method checks against file names with both the 8.3 file name format (if available) and the long file name format, a search pattern like &#8220;*.txt&#8221; may return unexpected results. For example, the file <code>longfilename.txtother<\/code> may be returned if the short file name for the file is <code>LONGFI~1.TXT<\/code>. <\/p><\/blockquote>\n<p> <b>Update<\/b>: It looks like the documentation has added my alternate remarks, but they kept the original misleading remarks as well, so now it&#8217;s double-confusing. And to make things even more confusing, the original misleading remark has been made <i>even more misleading<\/i> in the part where it talks about question marks overriding the three-character rule. This is another failed attempt to explain observed behavior. If you search for &#8220;file?.txt&#8221;, it will not match &#8220;file1.txtother&#8221;. But the reason is not that the question mark overrides the three-character rule. The reason is that the short name for &#8220;file1.txtother&#8221; is &#8220;FILE1~1.TXT&#8221;, and the question mark matches only one character. <\/p>\n","protected":false},"excerpt":{"rendered":"<p>The documentation for the Directory.Get&shy;Files method says When using the asterisk wildcard character in a search&shy;Pattern, such as &#8220;*.txt&#8221;, the matching behavior when the extension is exactly three characters long is different than when the extension is more or less than three characters long. A search&shy;Pattern with a file extension of exactly three characters returns [&hellip;]<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-1513","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"<p>The documentation for the Directory.Get&shy;Files method says When using the asterisk wildcard character in a search&shy;Pattern, such as &#8220;*.txt&#8221;, the matching behavior when the extension is exactly three characters long is different than when the extension is more or less than three characters long. A search&shy;Pattern with a file extension of exactly three characters returns [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/1513","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=1513"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/1513\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=1513"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=1513"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=1513"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}