Am 08.08.2025 um 22:10 schrieb matthew patton via Cygwin:
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.
I had expected someone might brand my proposed solution is inefficient
but launching a powershell certainly has much more overhead :)
Basically the .Net API properly handles case. The windows systemcall APIs do
not.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
