On Thu, Nov 12, 2009 at 10:00 PM, Matt McCutchen m...@mattmccutchen.netwrote:
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
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:
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 archive
On Thu, Nov 12, 2009 at 5:47 PM, Matt McCutchen m...@mattmccutchen.netwrote:
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
On Thu, 2009-11-12 at 21:47 -0800, Wayne Davison wrote:
On Thu, Nov 12, 2009 at 5:47 PM, Matt McCutchen
m...@mattmccutchen.net wrote:
It looks like the implementation has the receiver hang around
for a
hard-coded 10 seconds, accepting data from the sender and
On Wed, Nov 4, 2009 at 8:05 PM, Matt McCutchen m...@mattmccutchen.netwrote:
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
On Sat, 2009-11-07 at 09:38 -0800, Wayne Davison wrote:
On Wed, Nov 4, 2009 at 8:05 PM, Matt McCutchen
m...@mattmccutchen.net wrote:
With commit 84c11e85a4c4a12ecacba24afe9617222e4361e6, I get
different
output, but still not the desired No space
On Tue, Nov 3, 2009 at 9:25 AM, Matt McCutchen m...@mattmccutchen.netwrote:
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,
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 -aAXxx
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 up my system
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
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
12 matches
Mail list logo
