Re: The source and destination cannot both be remote :-(

2010-05-07 Thread Christian Huldt
7 maj 2010 kl. 21.20 skrev Kyle Lanclos: It would likely increase the latency, but it should not significantly impact the required bandwidth, assuming that you have a full-duplex connection. If you have a half-duplex connection, yes, the bandwidth consumption would double. I stand corrected an

--files-from= broken when run from cron?

2010-05-07 Thread Joshua Smith
Hello everyone, running rsync version 3.0.7 if i call a shell script with the content: *rsync -a -e 'ssh -i /home/mapsync/.ssh/id_rsa' --bwlimit=1221 --files-from=/tmp/tf2maplist --no-relative / maps...@foo.com: /home/mapsync/tf2maps* Everything runs great from a shell and /tmp/tf2maplist is a fil

Re: The source and destination cannot both be remote :-(

2010-05-07 Thread Kyle Lanclos
Christian Huldt wrote: > That I have no idea about, but I believe it would double the bandwith > requirements or half the speed compared to > > ssh r...@client "rsync /var/tmp/in tom...@fileserver:/opt/" It would likely increase the latency, but it should not significantly impact the required b

Re: The source and destination cannot both be remote :-(

2010-05-07 Thread Christian Huldt
7 maj 2010 kl. 17.43 skrev Michael Renner: Moin, this is something for the wish list: a 'rsync in the middle' mode. It would make sense: rsync is running at a server. Copyying files from one maschine to a file server. rsync r...@client:/var/tmp/in tom...@fileserver:/opt/ Would this be poss

The source and destination cannot both be remote :-(

2010-05-07 Thread Michael Renner
Moin, this is something for the wish list: a 'rsync in the middle' mode. It would make sense: rsync is running at a server. Copyying files from one maschine to a file server. rsync r...@client:/var/tmp/in tom...@fileserver:/opt/ Would this be possible without breaking the hard link mechanism? CU