I think we're on the same page - feel free to rant away if it helps :-)
Just to be fair and supply some of my own analysis somewhere in this thread,
since I can still reproduce my problem with the original tool and think
there is a potential gotcha behavior change between b20 and 1.1.0, and for
those who haven't fallen asleep reading it yet ...
Given that pipe() itself wasn't the problem, I rooted around a bit and my
new and improved root failure seems to be that stdin/stdout in my server are
being created in text mode, not binary. I've verified this by checking the
result of a setmode() on server startup.
As I think I mentioned in my original note, I'm using rsync, so the server
side is just being spawned out of a named pipe server that happens to be run
from a console window for testing purposes. It's thinking it's running in
rsh mode so the server just uses stdin/stdout for the traffic. That's the
rub.
So, without asking for too much specific help (treading cautiously here :-))
- is it possible that line 157 in hinfo.cc should be changed from:
int bin = __fmode;
to
int bin = (__fmode ? __fmode : O_BINARY)
in order to make the default for stdin/stdout binary even if CYGWIN isn't
set? That seems to mirror the way that pipe.cc checks things when it's
making the pipes.
I haven't yet run a full build of the DLL locally, so I'll have to schedule
some time tomorrow to do that to test the change locally? But adding a
setmode(O_BINARY) on both stdin and stdout in the rsync code did resolve the
problem without having to add the CYGWIN environment variable.
-- David
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com