Status Query - Please respond - Re: Patch to avoid 'Connection reset by peer' error for rsync on cygwin

[Max Bowsher]

> After thinking about it a bit more I'm somewhat inclined to call it a
> bug in Cygwin and try to get them to fix it.

Well, you could, but I'd much prefer it if you didn't :-)
I guess its time for you to make an executive descision - Is it reasonable to
include code in rsync to close sockets, even though exit() does it anyway on
most platforms. I would argue that a few close_socket() calls woudn't cause any
clutter - but then my interest is obviously focused on cygwin.

If you do give the go-ahead, then should I fix this inconsistency whilst I am at
it: In main(), rsync decides whether to be a daemon, server, or client. The
functions for some code paths are designed not to return, whilst others are
designed to return. Would it be better for all code paths to return to main _as
long as that does not cause extra mess_?


Thanks,

Max.

More context below:

Martin Pool <mbp at samba.org> wrote:
> On 10 May 2002, Max Bowsher <maxb at ukf.net> wrote:
>
>> The problem was especially severe here, because rsync didn't even
>> close the socket in these cases - it would write its last data, then return a
>> couple of times, and exit().
>
> It should not matter:
>
>        The function _exit terminates the calling process
>        "immediately". Any open file descriptors belonging to the
>        process are closed; any children of the process are inherited
>        by process 1, init, and the process's parent is sent a SIGCHLD
>        signal.
>
>> We could have a shutdownsocket(). Is it worth it for just for 2 lines of
code?
>> shutdown(fd, SHUT_WR);
>> close(fd);
>
> Yes, because (if this is really necessary) then it's a workaround for
> a platform bug and so not obvious.
>
> After thinking about it a bit more I'm somewhat inclined to call it a
> bug in Cygwin and try to get them to fix it.