https://bugs.winehq.org/show_bug.cgi?id=44373
Jason Edmeades us@edmeades.me.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC| |us@edmeades.me.uk
--- Comment #2 from Jason Edmeades us@edmeades.me.uk --- I started to look into the canonical case part of this but am really questioning the benefit unless we know an app is affected by it.
I'm attaching a patch which starts to fix it for the case of the filename portion but FindFirstFile is the best way to get the case of a filename, but it fails on wine when passed an explicit file and just returns what is passed in. I'll submit a bug with test case for this
To do this properly, we need to get the case of all the path leading up to the filename as well, which isnt worth the performance issue unless its causing problems, which makes me question the benefit if no apps need this
As to the other part, from your results it looks like on Windows if you start with quotes, then the leading quote and if there is one, trailing quote is removed. It then behaves as normal (searches path etc) except the 'full path' used to represent the batch program is 'replaced' by the parameter without the quotes. This is odd, and whilst we could implement it by keeping a second copy of data (where the file is, and where we say it is), I again question the benefit of adding the complexity without a need.
My gut feeling is this should be closed as wontfix, unless an app comes along which needs specifric behaviour. Fabian was right, its worth having bugs to highlight where there is differences, and if it was easy I would have fixed this. I wont close as its not really my call, but wanted to add my thoughts in here as I work some of the cmd bugs.