Do not use _wfopen() for DOS device filenames

[dscho]

It appears that CONIN$ can be opened correctly by fopen(), but not
_wfopen() (with "CONIN$" passed in the correct format, of course).

Reported by Ray Kolbe.

It was also reported in msysgit/msysgit#153, for
some definition of "reported": it was not only reported to the wrong
repository but also so incomplete as to be contemptous of the time of the
people asked for help.

Signed-off-by: Johannes Schindelin johannes.schindelin@gmx.de

[buildhive]

MSysGit - the development behind Git for Windows » git #158 SUCCESS
This pull request looks good
(what's this?)

[dscho]

@sschuberth it does work with fopen, though. The problem with CreateFile (and you probably actually meant CreateFileW, didn't you?) is that it returns a HANDLE, not a FILE *, therefore we would have to override all of the FILE * functions in compat/mingw.c. That would be a huge undertaking and very fragile (because who knows what enterprisey upstream decides to use next in terms functions operating on FILE *?).

So even while that list is ugly (which is only the failure of the Win32 API to provide a function to query the list of reserved DOS device names), I am really hesitant to replace a functional, small work-around by an unwieldy, time-consuming and fragile bigger work-around.

[dscho]

I merged this with the intent of fixing the bug in the short run, and if it is too ugly (or too unmaintainable) dropping it in a future revision in favor of a cleaner solution.

[kusma]

@dscho We wouldn't need to overload all functions operating on FILE-pointers, we only need to _open_osfhandle and _fdopen, no?

[dscho]

@kusma well, if we overload the fopen() function to use something internally that returns a HANDLE instead of a FILE *, we need to turn the former into the latter before we can return something valid... Therefore, _fdopen(_open_osfhandle(CreateFileW("CONIN$"))) should indeed do the job. I say "should" because I haven't tested it ;-)

[kblees]

The culprit seems to be GetFullPathNameW converting CONIN$ to an absolute path (i.e. "C:\whatever\CONIN$"). I'd prefer to revert #86 instead of adding more workarounds.

[sschuberth]

Indeed, after reading thorough the issues again I agree with @kblees that we should revert both #86 and this one.

[dscho]

@sschuberth I agree. Maybe we give @vangdfang a chance to speak up before that?

[vangdfang]

I've reused the change here a bit in #113 to clean up the issue that #86 introduced. I agree, the string list isn't the nicest thing, but it's also perhaps the most accurate way to ensure we don't have a "special" DOS name.