John J Foerch wrote:
So I may take up your suggestion for my own use, but I did want to put
forward the idea that since in my experience, trailing slash
interpretation is an often-mentioned stumbling-block for rsync users,
maybe it would be appropriate for rsync itself to provide a convenient
On Sat, Jan 7, 2012 at 10:32 PM, R. Pietsch rp.rs...@pcs-at.com wrote:
I try to capture such a rsync-stream with wireshark.
Hmmm... receiving or transmitting side?
I *assume* the transmitting side given the time difference between the
packets and their ACKs.
the times are for example:
I had network data transfer issue some time ago where transfers in one (A
to B) direction were at full network speed.. Transfers in opposite
directions (B to A) where going at 1 to 2 Kbit/sec.
Eventually the cause was tracked down and it turned out to be a duplex
mismatch caused by
Tomasz wrote:
I had network data transfer issue some time ago where transfers in one (A
to B) direction were at full network speed.. Transfers in opposite
directions (B to A) where going at 1 to 2 Kbit/sec.
Eventually the cause was tracked down and it turned out to be a duplex
mismatch
Am 2012-01-09 11:37, schrieb t...@vandradlabs.com.au:
I had network data transfer issue some time ago where transfers in one (A
to B) direction were at full network speed.. Transfers in opposite
directions (B to A) where going at 1 to 2 Kbit/sec.
Eventually the cause was tracked down and it
Voelker, Bernhard bernhard.voel...@siemens-enterprise.com writes:
John J Foerch wrote:
So I may take up your suggestion for my own use, but I did want to put
forward the idea that since in my experience, trailing slash
interpretation is an often-mentioned stumbling-block for rsync users,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2012-01-09 12:03, schrieb Voelker, Bernhard:
Tomasz wrote:
I had network data transfer issue some time ago where transfers in one (A
to B) direction were at full network speed.. Transfers in opposite
directions (B to A) where going at 1 to 2
