As a gentoo user I use rsync quite a lot, and am generally happy with your product. Since not so long I've been getting rsync errors when connecting with a timeout of 30secs. My internet connection is quite fast, but my laptop HDD is dead slow. I suspect the time-out was the problem, since changing it to 180s solved my problems. But I didn't have time to find out about this solution before today. Normally I get errors of this kind: dev-libs/gdome2/ dev-libs/geoip/ dev-libs/gmp/ rsync: connection unexpectedly closed (3412222 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(189) >>> retry ... >>> Starting retry 1 of 3 with rsync://81.223.20.162/gentoo-portage >>> checking server timestamp ... But this problems seems solved by changing my timeout settings. Now, while I was experimenting with rsync options, trying to solve this problem this morning I ran into some extreme rsync behaviour that might be interesting to you developers: Gentoo-Users: You've hit rsync1.at.gentoo.org/81.223.20.162 receiving file list ... overflow: flags=0x65 l1=0 l2=1308622849 lastname=media-libs/a52dec ERROR: buffer overflow in receive_file_entry rsync error: error allocating core memory buffers (code 22) at util.c(121) >>> retry ... >>> Starting retry 2 of 3 with rsync://62.197.40.130/gentoo-portage >>> checking server timestamp ... rsync: connection unexpectedly closed (0 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(189) >>> retry ... >>> Starting retry 3 of 3 with rsync://213.239.215.148/gentoo-portage >>> checking server timestamp ...
The overflow error indicates that the data read over the socket for the size of the filename was somehow invalid (e.g. it might have gotten corrupted in transit). If you have a reproducable test case, I'd be glad to take a look at the bug. If not, there's very little I can do.
http://lists.samba.org/archive/rsync/2005-April/012104.html(In reply to comment #1) > The overflow error indicates that the data read over the socket for the size of > the filename was somehow invalid (e.g. it might have gotten corrupted in > transit). If you have a reproducable test case, I'd be glad to take a look at > the bug. If not, there's very little I can do. > I have recieved a similiar error to the poster. ERROR: buffer overflow in receive_file_entry rsync error: error allocating core memory buffers (code 22) at util.c(126) I also found a similiar error using google.com here.. http://lists.samba.org/archive/rsync/2005-April/012104.html I have tested 2.6.6 and 2.6.8 This fix is for 2.6.8 The changes I have made to fix my error were in flist.c (489.c) static struct file_struct *receive_file_entry(struct file_list *flist, unsigned short flags, int f) I changed the following lines: static char lastname[MAXPATHLEN], *lastdir; char thisname[MAXPATHLEN]; if (l2 >= MAXPATHLEN - l1) { to: static char lastname[BIGPATHBUFLEN], *lastdir; char thisname[BIGPATHBUFLEN]; if (l2 >= BIGPATHBUFLEN - l1) { I haven't done full debugged this, but it compiles and runs, and does what I want so far. The cause for this, was very long file names.
The original error was for an impossibly large filename length, and thus an indication of a protocol issue. If increasing the receive buffer size to something bigger makes rsync work, that is an indication that your system files are buggy, because any string larger than MAXPATHLEN should not be accepted by things like open(). So, for the issue reported by Daniel, the correct fix is not to change rsync, but to get the system include files fixed. Failing that, you could kluge a larger, more correct value for MAXPATHLEN in rsync.h using a combination of #undef MAXPATHLEN and #define MAXPATHLEN <some-larger-but-still-supported-by-the-filesystem-functions-buffer-len-value>. As before, if someone has a reproducible case for an actual protocol error, please let us know.