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..