Click here to Skip to main content
15,937,602 members
Please Sign up or sign in to vote.
4.33/5 (6 votes)
See more:
Directory.GetFiles(dir, "*.exe")

File names like "file.exeandsomethingelse" will be also returned. Hot to fix?
Please, help.
(Loop through array and check each file - it's not variant, - it's plan 'B')
Updated 17-Sep-20 2:02am
Sergey Alexandrovich Kryukov 31-Jan-11 18:49pm    
Voted 5 for the question, because you're right.

Directory.GetFiles actually internally invokes Win32 native FindNextFile to get all the files that matches the search pattern.

As your windows is made up of both long and short filenames (8,3), it will match everything after 3 letters in extension.

If you try Dir *.exe in DOS prompt, you will see the similar output.

I think you need to use

var files = Directory.GetFiles(dir, "*.exe").Where(item => item.EndsWith(".exe"));
Share this answer
Nish Nishant 31-Jan-11 18:12pm    
Voted 5. Proposed as answer.
AspDotNetDev 31-Jan-11 18:15pm    
That would still match a file called "file.exexe", which would be incorrect. But good insight into the DOS filenames.
Nish Nishant 31-Jan-11 18:18pm    
That's right. The EndsWith should check for ".exe".
Sergey Alexandrovich Kryukov 31-Jan-11 20:25pm    
Now, that's correct work-around for Windows lame.
My 5.
Henry Minute 1-Feb-11 16:33pm    
Really good, Abishek! +5
A little fix the the correct answer of Abhishek Sur:

const string ExtExe = ".exe";
const string MaskExe = "*" + ExtExe;
var files =
   Directory.GetFiles(dir, MaskExe).Where(item => item.ToLower().EndsWith(ExtExe));

I think it's good the make the predicate Where case-insensitive.

Share this answer
Jonathan Gilbert 22-Oct-12 15:59pm    
The string.EndsWith method has an overload that accepts a StringComparison enumeration value. Thus, instead of creating a new string for each item in lowercase, I believe you can save time & memory churn like this:

.Where(item => item.EndsWith(ExtExe, StringComparison.InvariantCultureIgnoreCase))

(This also takes culture calculations out of the equation -- since we know we're comparing against the string ".exe", it doesn't matter what the current locale is, because the upper/lowercase rules for the ".exe" file extension are pretty much guaranteed not to involve culture-specific special cases. The basic string.ToLower() method is based on the character traits for the current locale.)
Sergey Alexandrovich Kryukov 22-Oct-12 16:40pm    
Agree that this improvements is useful and most practical, but I believe behind the scene it takes nearly as much of memory and CPU cycles. It can be measured though...
Thank you for this comment.
Jonathan Gilbert 22-Oct-12 16:53pm    
I've just benchmarked it and find, on my system, the variant which does not create a new string object to be almost twice as fast. For 10,000,000 loops, each one containing 8 assorted capitalizations with assorted pass/fail statuses:

.EndsWith(StringComparison): 00:00:08.5870000 9,316,408.52 / sec
.ToLower().EndsWith(): 00:00:15.9700000 5,009,392.61 / sec
Sergey Alexandrovich Kryukov 22-Oct-12 20:52pm    
Well, interesting result, thanks for sharing. In time-critical situations, it could be quite a reason to improve some code :-)
On this[^] page, in the notes section it says:
When using the question mark wildcard character, this method returns only files that match the specified file extension. For example, given two files, "file1.txt" and "file1.txtother", in a directory, a search pattern of "file?.txt" returns just the first file, while a search pattern of "file*.txt" returns both files.

I haven't tried it but would something like *?.exe do it?
Share this answer
Sergey Alexandrovich Kryukov 31-Jan-11 16:38pm    
No, *?.exe is not different from *.exe. "?" means exactly one (any) character, will be absorbed by '*'.
DaveyM69 31-Jan-11 17:20pm    
@SAKryukov: You are correct - I misread the documentation.
This blog explains it better than MSDN:
Seems like there's no solution other than to check each returned result...

See my initial answer below.

This kind of wildcard is too simple.

Not true "file.exeandsomethingelse" does not match "*.exe". This pattern is correct, if you simply want to get "all file names ending with '.exe'". Did you try?

If the pattern was "*.exe*", then yes, "file.exeandsomethingelse" would match it. Don't mix up with sloppy liberal treatment of wildcards in Windows Search.

One note, just in case: in file system there is no such thing as "extension", not anymore. No it is exactly line in Unix. Dot inside name is treated as any other character (it is not put next to directory separator). (Don't mix it up with Shell "extension", which is still used in registered "file types".)

Unfortunately, Halabella and Nishant were right, and I was wrong — my apologies.
The vote of "1" for my answer was quite correct.
I just tested it and found it works like Microsoft documented:

When using the asterisk wildcard character in a searchPattern, such as "*.txt", 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 searchPattern 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 searchPattern. A searchPattern 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 searchPattern. When using the question mark wildcard character, this method returns only files that match the specified file extension. For example, given two files, "file1.txt" and "file1.txtother", in a directory, a search pattern of "file?.txt" returns just the first file, while a search pattern of "file*.txt" returns both files.

The following list shows the behavior of different lengths for the searchPattern parameter:

"*.abc" returns files having an extension of .abc, .abcd, .abcde, .abcdef, and so on.
"*.abcd" returns only files having an extension of .abcd.
"*.abcde" returns only files having an extension of .abcde.
"*.abcdef" returns only files having an extension of .abcdef.

Below, this strange behavior gets some explanation:

Because this method checks against file names with both the 8.3 file name format and the long file name format, a search pattern similar to "*1*.txt" may return unexpected file names. For example, using a search pattern of "*1*.txt" returns "longfilename.txt" because the equivalent 8.3 file name format is "LONGFI~1.TXT".

What we have here I would call an epic fail of Microsoft, it renders this API not really usable if we need reasonable masking behavior. It needs work around.
This looks like one of the "this is not a bug, this is a feature" cases.
I must say, in all shells I used masking works as I expected it.

Again, sorry for trouble caused by incorrect Answer.

See also: added ToLower in my other answer.

Share this answer
Espen Harlinn 31-Jan-11 16:59pm    
5+, Good answer :)
Nish Nishant 31-Jan-11 18:10pm    
Hey Kryukov,

That's not correct. Directory.GetFiles does not work that way. *.exe will match a.exe as well as a.exe2. This is by design and is also documented.
Sergey Alexandrovich Kryukov 31-Jan-11 18:19pm    
Really? If you're right, API is useless crap. I want to check it up now...
Nish Nishant 31-Jan-11 18:20pm    
It's not a .NET issue, it is Win32 API behavior.

Sergey Alexandrovich Kryukov 31-Jan-11 20:07pm    
Who would doubt this is an issue of "must die"?
The level of new .NET functionality always better; this is just some interop.
What's funny, even old flicker in components created in Windows 3* is still there.
Thank you.
Thanks for discussion! To make this topic helpful for someone:
List <string> exes = SearchFilesRecursive(@"d:\", "*.exe");

public List<string> SearchFilesRecursive(string directory, string pattern)
     Stack<string> stack = new Stack<string>();
     List<string> result = new List<string>();
     List<string> current_dir = new List<string>();
     int extention_length = pattern.Length - 1;
     while (stack.Count > 0)
         string dir = stack.Pop();
             current_dir.AddRange(Directory.GetFiles(dir, pattern));
             for (int i = 0; i < current_dir.Count; i++)
                 if (current_dir[i].LastIndexOf(".") != current_dir[i].Length - extention_length)

             // Add all directories at this directory.
             foreach (string dn in Directory.GetDirectories(dir))
             // Couldn't open the directory
     return result;
Share this answer

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900