I have just discovered that the recently implemented pipe chunking
protocol is broken on Windows. This is because the pipes are operating
in text mode and doing LF->CR-LF translation, so the number of bytes
received is not the number transmitted and set in the protocol header.
I have not yet
Andrew Dunstan wrote:
>
> I have just discovered that the recently implemented pipe chunking
> protocol is broken on Windows. This is because the pipes are operating
> in text mode and doing LF->CR-LF translation, so the number of bytes
> received is not the number transmitted and set in the proto
Erik Jones <[EMAIL PROTECTED]> writes:
> improvement that went into that release. I could test turning it
> back on this week if you like -- I certainly would like to have my
> blks_read/cach_hits stats back. Toggling stats_block_level will
> respond to a reload, yes?
Yes, as long as you h
Magnus Hagander wrote:
Andrew Dunstan wrote:
I have just discovered that the recently implemented pipe chunking
protocol is broken on Windows. This is because the pipes are operating
in text mode and doing LF->CR-LF translation, so the number of bytes
received is not the number transmitted
Andrew Dunstan wrote:
>>> I have just discovered that the recently implemented pipe chunking
>>> protocol is broken on Windows. This is because the pipes are operating
>>> in text mode and doing LF->CR-LF translation, so the number of bytes
>>> received is not the number transmitted and set in the
Magnus Hagander wrote:
Andrew Dunstan wrote:
I have just discovered that the recently implemented pipe chunking
protocol is broken on Windows. This is because the pipes are operating
in text mode and doing LF->CR-LF translation, so the number of bytes
received is not the number transmitted
Andrew Dunstan wrote:
>> Uh, see port.h, lines 212-224. If you're using the pipe() command to
>> create it, it's used.
>>
>
> No, it's the other way around :-) If you use pgpipe() on Unix you're
> calling pipe():
D'oh. You're right, of course. I'm obviously not in a state where I
should be rea
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
Andrew Dunstan wrote:
>
> 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
Andreas Pflug wrote:
Andrew Dunstan wrote:
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
Andrew Dunstan wrote:
>>
>>> 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.
Yes this was intentional, notepad still doesn't like LF line endings.
Not my prefe
Andreas Pflug wrote:
Andrew Dunstan wrote:
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.
Yes this was intentional, notepad still doesn't lik
Andrew Dunstan wrote:
>
> Not for Wordpad though, and it's pretty universal too. And Notepad
> won't load a file of any great size anyway. Furthermore, we just can't
> have this alongside the pipe chunking protocol, so I'm inclined to
> blow it away altogether, unless there are pretty loud squawk
Andreas Pflug wrote:
Andrew Dunstan wrote:
Not for Wordpad though, and it's pretty universal too. And Notepad
won't load a file of any great size anyway. Furthermore, we just can't
have this alongside the pipe chunking protocol, so I'm inclined to
blow it away altogether, unless there are
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 b
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 b
Andreas Pflug wrote:
Andrew Dunstan wrote:
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
17 matches
Mail list logo
