On Sat, Mar 05, 2005 at 06:53:08AM -0800, Lawrence Wong wrote: > # rsync -av --stats --delete --force > ftp.funet.fi::CPAN
Hmm, there's no destination directory specified there. Did you omit it? Or are you doing a file listing? > rsync: connection unexpectedly closed (9382362 bytes received so far) > [receiver] > rsync: connection unexpectedly closed (9382362 bytes received so far) > [generator] These come from the receiving side, so it is unknown why the sending side went away (since they didn't tell us). Try using --delete-after, which will avoid a big delay prior to the start of the transfer and see if that makes a difference. > rsync error: timeout in data send/receive (code 30) at io.c(153) > rsync: connection unexpectedly closed (837077 bytes received so far) > [receiver] This tells us that the other end of the connection timed out from lack of activity over the socket. See the --delete-after suggestion above. Even then, if relatively few files are modified in the local repository the transfer can still time out. The only solution for that (before 2.6.4 is released and is used on these servers) is to either break up the transfer into subdirs, or to touch small files at certain spots in the local hierarchy so that they will trigger periodic file transfers during the larger update. > I have tried RSYNC 2.6.4pre1 & 2.6.4pre2 but to no avail. Do you mean that they behaved in the same way as 2.6.3? They should have because it is the remote side that is going away. I assume that 2.5.7 would also behave in the same way on your updated system (possibly because your system is taking longer than it used to go through all the files looking for deletions and changes, and possibly because the other end of the connection has recently changed their timeout settings). ..wayne.. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
