korry.douglas wrote:
>
>>> I have not yet succeeded in turning this behaviour off (_setmode()
>>> didn't seem to affect it). If we can't find a way to turn it off,
>>> the only solution short of abandoning its use on Windows that I can
>>> think of is to translate LF on input to something unlikely like 0x1C
>>> and then translate it back when we read it from the pipe.
>> Did you _setmode() the pipe, _setmode() stderr, or both? (And did
>> you try before or after calling dup2()?).
>>
>> It looks like the Win CRT implementation of dup2() copues the "mode"
>> from the pipe that you've created into stderr.
> Sorry, I was looking at the wrong chunk of code in syslogger.c.
> Why are you calling _open_osfhandle() with O_TEXT? That looks
> suspicious giving the problem that you are seeing with CR -> CR/LF
> translation.
>
>
I have no idea why that's done - it goes back to the origins of the
syslogger - probably because someone mistakenly thinks all WIndows text
files have to have CRLF line endings.
I tried changing that to _O_BINARY, and calling _setmode on both the
pipe before it's duped into stderr and stderr after the dup and both.
Nothing seemed to work.
But that's not the only problem. I am now getting log file corruption
even when I work around the text mode problem by not sending a '\n' at
all, which makes me think even small packets aren't safely written
atomically to Windows pipes. I wonder if we'd do better using the (so
far unused) pipe simulation using sockets that we have. Not sure if we
can dup a socket into stderr on Windows, but it might be worth trying,
or even working around that problem. If we could safely use that the
code would get a whole lot simpler - presumably we would no longer need
those extra syslogger threads on Windows.
cheers
andrew
