On Thu, Nov 12, 2009 at 10:00 PM, Matt McCutchen wrote:
> My point is that it's a clunky way to achieve the goal, and it would be
> simpler for the sender to just keep reading after a write error.
>
Yeah, that's a good idiom, and the latest code wasn't doing a good enough
job of that when the soc
On Thu, 2009-11-12 at 21:47 -0800, Wayne Davison wrote:
> On Thu, Nov 12, 2009 at 5:47 PM, Matt McCutchen
> wrote:
> It looks like the implementation has the receiver hang around
> for a
> hard-coded 10 seconds, accepting data from the sender and
> discarding it.
>
On Thu, Nov 12, 2009 at 5:47 PM, Matt McCutchen wrote:
> It looks like the implementation has the receiver hang around for a
> hard-coded 10 seconds, accepting data from the sender and discarding it.
>
No, it sets a timeout of 10 seconds (i.e. 10 seconds of inactivity), which
in the new protocol
On Sat, 2009-11-07 at 09:38 -0800, Wayne Davison wrote:
> Yeah, that's the long-standing issue where a fatal error on the server
> side can cause the client side to get a socket error trying to write
> to the socket before it has a chance to read the error(s) from the
> socket. The latest git arch
On Sun, 2009-11-08 at 01:57 -0500, Matt McCutchen wrote:
> I tested commit 2907af472d1f33b3c422cb9f601c121b242aa9c7 and, again, the
> output is different but the problem is not fixed:
>
> $ rsync-dev big-file small-fs/
> rsync: connection unexpectedly closed (146 bytes received so far) [sender]
>
On Sat, 2009-11-07 at 09:38 -0800, Wayne Davison wrote:
> On Wed, Nov 4, 2009 at 8:05 PM, Matt McCutchen
> wrote:
>
> With commit 84c11e85a4c4a12ecacba24afe9617222e4361e6, I get
> different
>
> output, but still not the desired "No space left on device":
>
On Wed, Nov 4, 2009 at 8:05 PM, Matt McCutchen wrote:
> With commit 84c11e85a4c4a12ecacba24afe9617222e4361e6, I get different
> output, but still not the desired "No space left on device":
>
Yeah, that's the long-standing issue where a fatal error on the server side
can cause the client side to g
On Tue, Nov 3, 2009 at 9:25 AM, Matt McCutchen wrote:
> rsync error: errors with program diagnostics (code 13) at log.c(340)
> [sender=3.1.0dev]
>
This means that you didn't update recently. Sadly, it appears my reply
mentioning that I fixed the problem only went to Carlos, and missed the
list.
On Tue, 2009-11-03 at 12:25 -0500, Matt McCutchen wrote:
> On Thu, 2009-10-29 at 13:20 -0200, Carlos Carvalho wrote:
> > Got this in the log:
> >
> > rsync error: errors with program diagnostics (code 13) at log.c(340)
> > [generator=
> > 3.1.0dev]
>
> I got this too on a big local run backing u
On Thu, 2009-10-29 at 13:20 -0200, Carlos Carvalho wrote:
> Got this in the log:
>
> rsync error: errors with program diagnostics (code 13) at log.c(340)
> [generator=
> 3.1.0dev]
I got this too on a big local run backing up my system to an external
disk using rsnapshot.
/etc/rsnapshot-rsync -a
Carlos Carvalho (car...@fisica.ufpr.br) wrote on 29 October 2009 13:20:
>Got this in the log:
>
>rsync error: errors with program diagnostics (code 13) at log.c(340)
>[generator= 3.1.0dev]
Another event:
rsync: read error: Connection reset by peer (104)rsync error: errors with
program diagno
Got this in the log:
rsync error: errors with program diagnostics (code 13) at log.c(340) [generator=
3.1.0dev]
What could it be? I suspect it's triggered by a timeout or disconnect
from the server side but I had never seen it.
--
Please use reply-all for most replies to avoid omitting the maili
12 matches
Mail list logo
