getting the on-disk case for a path

[matthew patton]

> > Background: I'm trying to debug some test failures in Clang, due to a
> > warning that's supposed to be issued when you #include "foo.h" but the
> > file on disk that it opened is "Foo.h".

sounds like Clang is misbehaved. If it opened the file regardless of case it should just continue. Is it doing a gratuitous stat() call or something else to compare actual vs requested? Why? That's just unnecessary meddling and introducing breakage for no good reason. actually stat() is "broken" as it just blindly returns the command-line argument rather than the accurate representation of what is ON the disk.

My spidey sense says we had a whole conversation about this and Cygwin lying to the user some years back.
System.IO.FileInfo() lies. The only "easy" solution I have is run powershell> (get-Item $pwd).GetFiles('foo.h').Name 
which will give you the correct answer.

Similarly PS> (get-item("foo.h*")).Name
emits the correct case. Please note the wildcard is MANDATORY for it to work.

Basically the .Net API properly handles case. The windows systemcall APIs do not.