Status Query - Please respond - Re: Patch to avoid 'Connection reset by peer' error for rsync on cygwin
Max Bowsher
maxb at ukf.net
Tue May 14 05:50:05 EST 2002
> 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.
More information about the rsync
mailing list