by Michael S. Kaplan, published on 2007/10/24 10:16 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/10/24/5647711.aspx
I gave blathered about the importance of preserving case and of getting the preserved case in posts like In any CASE, it is somewhat INSENSITIVE to point out to someone how well PRESERVED they are and If you don't always preserve case, you don't always preserve meaning, and What happens when people don't consistently preserve case? They cause bugs!. But I haven't talked much about how to get that preserved case....
Then by coincidence someone asked how this is done in .NET!
Inbar's question, which properly balances how to preserve case even in the face of user input that may not match the case of the file, was:
Does anyone know how to use System.IO to get the preserved case of a file-name? For example say the user gives me the filename “FoO.tXt” and the file on disk is stored as “foo.txt”. I can certainly open the file using “FoO.tXt” or “foo.txt” or any other casing I choose. But how do I get the original casing?
The solution can be found in a call to System.IO.Directory.GetFiles(String path, string searchPattern).
The return value in array of files that match the search pattern in their actual case on disk, and when the search pattern is restrictive enough (no wild cards, I mean -- just the file name itself), it will return an array containing just the one entry.
Of course that entry point does take wildcards, so if the filename is something provided by the user then if they include a wildcard the method would return multiple files -- you would want to decide what is the acceptable behavior there is -- select multiple files, give an error, whatever. It is likely that just choosing the first file only is probably a bad idea here....
This method will completely respect the rules of the directory being looked in when you think about issues like case, an issue I will be exploring in an upcoming post minutes from now in a post entitled In Case you have problems that you might think are ǸȦȘȚȲ. This respect becomes very important, as you'll see when you see how NASTY (or should I say ǸȦȘȚȲ?) the directory can become depending on when it was formatted and sometimes even when it was updated by CHKDSK (an issue I'll talk about a little there but will cover more fully another day).
Undernath it all, the various overloads of GetFiles all depend on Win32's FindFirstFile/FindNextFile to get their work done, which should give hints on both how the wildcard behavior will actually work and also how to accomplish the same goal in Win32.
Now file system stuff is covered here, but the entire issue does not work exactly this way in the case of URLs, a definite subject for another time....
This post brought to you by * (U+002a, a.k.a. ASTERISK)
referenced by