On Tue, Jul 12, 2011 at 3:12 PM, Carlos Carvalho wrote:
> The new feature is indeed very useful but something else is needed: print
> the IP of the server even when the connection is successful, and also print
> any IPs that were tried but didn't work.
Looks nice to me. I tweaked it a bit and c
This is to ask for a slight enhancement in the new multi-protocol IP
printing. I'm keeping the bug thread because in our machines it
revealed another problem with the code that's already there.
The new feature is indeed very useful but something else is needed:
print the IP of the server even when
add "--timeout="
Where is how many seconds you would like it to wait before giving
up.
On Tue, Jul 12, 2011 at 2:50 PM, Larry Irwin wrote:
> Hi All,
> I have an rsync client that is not re-starting and/or timing out when the
> server processes die/go away...
> The client is rsync version 3.0
Hi All,
I have an rsync client that is not re-starting and/or timing out when
the server processes die/go away...
The client is rsync version 3.0.4 protocol version 30, natively
compiled on Debian 6, kernel 2.6.32.5-amd64.
The server is a QNAP NAS device running rsync version 3.0.6 protocol
On 12.07.2011 11:10, Donald Pearson wrote:
...
A 'trick' i personally use for an unreliable connection is an
OpenSSH-Tunnel.
Altough any VPN-solution should to the trick.
That way the connection between the two rsync-halvs isn't directly tied
to the internet-connection.
In my case that means
On 7/12/2011 11:10 AM, Donald Pearson wrote:
@Eberhard: I understand what you're trying to say, but in this
environment the reality is rsync reaches and impasse where it is unable
to get beyond work that has already been completed before link failure
cuts it off again.
@Leen: A combination of
Hi,
On Tue, 12 Jul 2011, Donald Pearson wrote:
[very selective cited, just to lighten one aspect]
@Eberhard: I understand what you're trying to say, but in this environment
the reality is rsync reaches and impasse where it is unable to get beyond
work that has already been completed before li
@Eberhard: I understand what you're trying to say, but in this environment
the reality is rsync reaches and impasse where it is unable to get beyond
work that has already been completed before link failure cuts it off again.
@Leen: A combination of --append with --partial is what I tried, howeve
On 11.07.2011 16:01, Donald Pearson wrote:
> I am looking to do state-full resume of rsync transfers.
>
> My network environment is is an unreliable and slow satellite
> infrastructure, and the files I need to send are approaching 10 gigs in
> size. In this network environment often times links c
