Question

I ask for your patience about the lack of code snippets in this question and the its vagueness, but I’m totally clueless, I don’t have any clue about the location of the bug, and I cannot paste an entire application.

I have a cross platform application which opens a file through the normal C API (fopen etc), writes some data (first passing the buffer to zlib to deflate it, but I don’t think that this is relevant) for a consistent time, and finally flushes and close it.

This works perfectly fine on all platform, except for the 64 bit build on Windows OS x64 with UAC turned on. Basically, on that precise setup, it seems that the file buffer is literally interlaced with what I’ve sent to stdout between the time I open the file and I flush it, as if any write to stdout used the same buffer of the other file.

It is important to note that this shouldn’t be related to any file system virtualization (the VirtualStore mechanism), as I’m writing in %USERPROFILE%\Saved Games\. The problem is surely related to UAC because if I turn it off, the problem isn’t happening. No problem in wine64 also.

Any pointer is valuable. Compiler is g++ 4.7.0 (cross compiling from linux).

Answer 1

I have found a workaround for this problem.

First blocker was that I compiled my application with -mwindows, and that prevented my application to be attached to the parent process console. But switching to -mconsole didn’t just fix it up. Even with this change everything I sent to stdout wasn’t being sent to the console. I didn’t state this issue in the question because it wasn’t a big deal, the application has another sort of console in it.

I am certain that the whole problem is due to some bug (or some very poorly documented behaviour change) in msvcrt. Basically, when my application starts up, stdout is a valid pointer, but it is not really attached to the parent console. I have to do a freopen( "CON", "wt", stdout ); to see the output. Besides, fileno(stdout) without UAC returns 1 correctly, but with UAC on, stdout is still a valid pointer, but a call to fileno(stdout) return -1! I am wondering then where is really stdout pointing to in the second case.

It is interesting to note that when compiling with -mwindows, fileno(stdout) returns 3! I don’t know if the POSIX standard requires stdout to have a file descriptor number of 1, but the choice of 3 is, at least, unusual.