From the documentation for Directory.GetFiles Method (String, String)

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.

I realize this behavior is probably well known to Windows developers, but seriously, WTF? How do I match on three character file extensions (i.e. the majority of file extensions) without getting cruft as well (e.g. matching on .cpp files without getting Emacs backups with .cpp~ file extensions)?

Now playing: Mystikal - I Smell Smoke


Tuesday, September 11, 2007 7:32:22 AM (GMT Daylight Time, UTC+01:00)
To be fair it isn't a .NET bug, it is a compatibility requirement for Windows.

In Windows, every file has an 8.3 name so that 16-bit applications, and braindead 32-bit ones, can access it. As a result, your .NET application has no way to know if you are looking for the 8.3 names or if you only want files that match using the long file names.

Still, they could have included a flag or something.
Jonathan Allen
Tuesday, September 11, 2007 4:44:59 PM (GMT Daylight Time, UTC+01:00)
You have to do your own filtering on in addition to - its pretty simple to use ends with to check for this though. Nice feature eh?
Tuesday, September 11, 2007 5:06:04 PM (GMT Daylight Time, UTC+01:00)
I figured that out. The question is why the .NET API couldn't just do that if the underlying Windows API is so retarded instead of propagating the behavior into a new API. As Jonathan mentioned, they could have a flag to enable to backwards compatible behavior and defaulted to sensible behavior.
Tuesday, September 11, 2007 11:25:31 PM (GMT Daylight Time, UTC+01:00)
My guess -- in v1.0 of .NET they didn't notice this. And by v1.1 they had their own backward compatability issue to deal with :)
Comments are closed.