Click here to Skip to main content
14,698,806 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')
Posted
Updated 17-Sep-20 3:02am
Comments
Sergey Alexandrovich Kryukov 31-Jan-11 18:49pm
   
Voted 5 for the question, because you're right.
--SA

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"));
   
v2
Comments
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.
--SA
Henry Minute 1-Feb-11 16:33pm
   
Really good, Abishek! +5
   
I also added case improvement in my last answer.
--SA
Sergey Alexandrovich Kryukov 13-Feb-11 12:36pm
   
Abhishek,
Thank you very much for explaining this problem to me back then.
Also, ToLower should be added to Where to make it completely correct -- see my new Answer.
--SA
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.

—SA
   
Comments
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.
--SA
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 :-)
--SA
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?
   
v2
Comments
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: http://www.simple-talk.com/community/blogs/andras/archive/2008/08/01/65554.aspx
Seems like there's no solution other than to check each returned result...
[EDIT]

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:

Note:
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.

—SA
   
v3
Comments
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...
--SA
Nish Nishant 31-Jan-11 18:20pm
   
It's not a .NET issue, it is Win32 API behavior.

See http://social.msdn.microsoft.com/Forums/en/csharpgeneral/thread/49cbae5b-9c54-432e-9f0e-0fd1f94db287
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.
--SA
Sergey Alexandrovich Kryukov 31-Jan-11 18:31pm
   
Unfortunately, you and OP are right. (I tested on v.3.5). And yes, it is per documentation.
That must die!

Sorry, I'll fix my answer.
--SA
Sergey Alexandrovich Kryukov 31-Jan-11 18:48pm
   
I fixed my Answer and admitted my mistake.
--SA
Sergey Alexandrovich Kryukov 31-Jan-11 18:34pm
   
Unfortunately, somebody voted "1" absolutely correctly, please see my comment.
I'll fix my Answer.
Microsoft unfortunately works now like "it should be" but "as documented".
--SA
fjdiewornncalwe 31-Jan-11 17:20pm
   
Not sure why you got the 1. Excellent and thorough answer. +5 from me.
Nish Nishant 31-Jan-11 18:19pm
   
I did not vote the 1, but the answer is incorrect.
Sergey Alexandrovich Kryukov 31-Jan-11 18:49pm
   
But the vote of "1" was quote correct, see my update.
--SA
Sergey Alexandrovich Kryukov 31-Jan-11 18:32pm
   
The vote of "1" is valid. What I said is not true. I'll have to admit it (see my comment)
--SA
fjdiewornncalwe 31-Jan-11 19:31pm
   
I now stand corrected as well. This is something I learned today... But your honesty in admitting error means I'll keep my vote at 5 nonetheless.
Sergey Alexandrovich Kryukov 31-Jan-11 20:04pm
   
Well, thank you. After all, I fixed my answer.
--SA
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>();
     stack.Push(directory);
     List<string> current_dir = new List<string>();
     int extention_length = pattern.Length - 1;
     while (stack.Count > 0)
     {
         string dir = stack.Pop();
         try
         {
             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)
                 {
                     current_dir.RemoveAt(i);
                     i--;
                 }
             }
             result.AddRange(current_dir);
             current_dir.Clear();

             // Add all directories at this directory.
             foreach (string dn in Directory.GetDirectories(dir))
             {
                 stack.Push(dn);
             }
         }
         catch
         {
             // Couldn't open the directory
         }
     }
     return result;
 }
   
v2

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