X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=gzst+wcQ7O7w2ExL
	Ws6ur+RVHtCnbIQRo10iB3b1YgvVomdnk+q/vzUnQgVNZXV1ONpNKR2hpI7qR/2h
	h3a/9KY+9BKyWE71GVYgk26HB+qwG7mvvpL1CqlFq6x9/l4wPY3gbGi/iJkxceh/
	3/TLEI5eQByLeV75gRjbQGvnCLU=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; s=default; bh=2dsVR9Y3+X/2l94GNMRWi1
	hT644=; b=LXzj9PxE4E6J/Cn/K/yspvVkjpMyU56ErMLrSZHJu/erX6LLXd8B9n
	lnecCiTldjzqKg6qFt9hXvUnfvPmAlUmQQR7r2qacC+uaxBT9IurobWXPLkjWn4i
	0JaBFUXdO0Iekwle9zN+P1MRnussSgnEnSSf1ponnyrllljWIGC8c=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=4.8 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,KAM_THEBAT,MIME_BASE64_BLANKS,SPF_SOFTFAIL autolearn=no version=3.3.2
X-HELO:	smtp.ht-systems.ru
Date:	Mon, 13 Jul 2015 19:34:20 +0300
From:	Andrey Repin <anrdaemon AT yandex DOT ru>
Reply-To:	cygwin AT cygwin DOT com
Message-ID:	<1632599002.20150713193420@yandex.ru>
To:	Warren Young <wyml AT etr-usa DOT com>, cygwin AT cygwin DOT com
Subject:	Re: Telnet / SSH connection timeout on LAN
In-Reply-To:	<F96E2C14-5C27-43A0-AC16-DDF01F05BB23@etr-usa.com>
References:	<1436142936994-119480 DOT post AT n5 DOT nabble DOT com> <7931485F-EEA3-4C1B-8B2C-E495EF5ED1A9 AT etr-usa DOT com> <1283519593 DOT 20150709090453 AT yandex DOT ru> <5C24455B-3D28-4C6D-A77B-70BB5D67F0AA AT etr-usa DOT com> <1023815842 DOT 20150711053838 AT yandex DOT ru> <F96E2C14-5C27-43A0-AC16-DDF01F05BB23 AT etr-usa DOT com>
MIME-Version:	1.0
X-IsSubscribed:	yes
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id t6DGZO7e003377

Greetings, Warren Young!

>>> Consider all the disk I/O required.  In its default mode, rsync must do a
>>> full directory tree scan on the directory to be transferred, on *both* ends.
>>> For each file with a different mtime or size, it must then recompute all the
>>> hashes in that file, again on both sides.
>> 
>> Wrong. In default mode, rsync only care about timestamp and size.
>> It will not go on hashing crusade unless explicitly told to.

> You misunderstood what I wrote.  Given a changed mtime or file size, rsync
> then must re-read the file on both sides in order to generate a series of
> checksums on chunks of the file in order to determine which parts of the
> file have changed, so that it transfers only the changes.  See:

>  
> https://en.wikipedia.org/wiki/Rsync#Determining_which_parts_of_a_file_have_changed

> If you skip this step, you must transfer the entire file contents to the
> other side, since a difference only in the mtime and/or file size doesn’t
> tell you which parts of the file have changed.

In my environment, a small touch to the original file cause changes throughout
the entirety of its stored image. ('cause storage format is actually an
archive, and a small change here and there in the source file cause massive
shifts in the resulting image.)
You see, it is a matter of application and environment.


-- 
With best regards,
Andrey Repin
Monday, July 13, 2015 19:31:58

Sorry for my terrible english...

- Raw text -