[SCM] The rsync repository. - branch master updated

[Rsync CVS commit messages]

The branch, master has been updated
   via  e5610f18 Avoid a yodl macro warning.
  from  c3761706 Make sure that some memory zeroing always happens.

https://git.samba.org/?p=rsync.git;a=shortlog;h=master


- Log -
commit e5610f1877ebb2a3fa7fb864d78cf41d0246701d
Author: Wayne Davison 
Date:   Tue Jan 8 16:39:48 2019 -0800

Avoid a yodl macro warning.

---

Summary of changes:
 rsyncd.conf.yo | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


Changeset truncated at 500 lines:

diff --git a/rsyncd.conf.yo b/rsyncd.conf.yo
index c041cf93..8f004ae6 100644
--- a/rsyncd.conf.yo
+++ b/rsyncd.conf.yo
@@ -83,7 +83,7 @@ default for that parameter.
 
 You may use references to environment variables in the values of parameters.
 String parameters will have %VAR% references expanded as late as possible (when
-the string is used in the program), allowing for the use of variables that
+the string is first used in the program), allowing for the use of variables 
that
 rsync sets at connection time, such as RSYNC_USER_NAME.  Non-string parameters
 (such as true/false settings) are expanded when read from the config file.  If
 a variable does not exist in the environment, or if a sequence of characters is
@@ -819,7 +819,7 @@ are run using the permissions of the user that started the 
daemon (not the
 module's uid/gid setting) without any chroot restrictions.
 
 These settings honor 2 environment variables: use RSYNC_SHELL to set a shell to
-use when running the command (which otherwise uses your system() call's default
+use when running the command (which otherwise uses your code(system()) call's 
default
 shell), and use RSYNC_NO_XFER_EXEC to disable both options completely.
 
 )


-- 
The rsync repository.

___
rsync-cvs mailing list
rsync-cvs@lists.samba.org
https://lists.samba.org/mailman/listinfo/rsync-cvs

Re: rsync remote raw block device with --inplace

[Gionatan Danti via rsync]

Il 02-01-2019 21:16 Steve Newcomb via rsync ha scritto:

To summarize: while diskrsync is looking like the most suitable
solution known to us, it would still be more convenient, gentler,
kinder, and wiser if the ability to transfer raw block device content
were added to rsync.


Can I suggest you to try blocksync [1]?
I'm using the git version in production without problems, but (as 
always) you mileage may vary.


[1] https://github.com/shodanshok/blocksync

--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.da...@assyoma.it - i...@assyoma.it
GPG public key ID: FF5F32A8

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

[Bug 13522] Patch fileflags.diff and crtimes.diff

[just subscribed for rsync-qa from bugzilla via rsync]

https://bugzilla.samba.org/show_bug.cgi?id=13522

--- Comment #3 from Wayne Davison  ---
The download page mentions all of the ways to grab the source, including git:

https://rsync.samba.org/download.html

The git source is safe, as it only contains bug fixes since the last release.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

[Bug 13707] zlib/inflate.c:1528

[just subscribed for rsync-qa from bugzilla via rsync]

https://bugzilla.samba.org/show_bug.cgi?id=13707

Wayne Davison  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Wayne Davison  ---
This has been fixed in git for a long time.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

[SCM] The rsync repository. - branch master updated

[Rsync CVS commit messages]

The branch, master has been updated
   via  48163179 Avoid a yodl macro warning.
   via  b4c1b27e Fix 2 spelling errors pointed out by bug 13734.
  from  c90b87e0 Avoid a failed test if dirs report 1 hlink (e.g. WSL 
weirdness).

https://git.samba.org/?p=rsync.git;a=shortlog;h=master


- Log -
commit 48163179ebb1cc79a207a8cd80bb11c1f455bc00
Author: Wayne Davison 
Date:   Tue Jan 8 13:38:19 2019 -0800

Avoid a yodl macro warning.

commit b4c1b27e03d470f757e6d3ff98172bad865ed6c3
Author: Wayne Davison 
Date:   Tue Jan 8 13:29:18 2019 -0800

Fix 2 spelling errors pointed out by bug 13734.

---

Summary of changes:
 rsync.yo | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)


Changeset truncated at 500 lines:

diff --git a/rsync.yo b/rsync.yo
index 99177363..7bf005cc 100644
--- a/rsync.yo
+++ b/rsync.yo
@@ -238,7 +238,7 @@ which forwards all data to port 873 (the rsync daemon) on 
the targethost
 
 Note also that if the RSYNC_SHELL environment varibable is set, that
 program will be used to run the RSYNC_CONNECT_PROG command instead of
-using the default shell of the system() call.
+using the default shell of the code(system()) call.
 
 manpagesection(USING RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL CONNECTION)
 
@@ -1330,7 +1330,7 @@ batch-writing option is in effect.
 
 dit(bf(--checksum-choice=STR)) This option overrides the checksum algoriths.
 If one algorithm name is specified, it is used for both the transfer checksums
-and (assuming bf(--checksum) is specifed) the pre-transfer checksumming. If two
+and (assuming bf(--checksum) is specified) the pre-transfer checksumming. If 
two
 comma-separated names are supplied, the first name affects the transfer
 checksums, and the second name affects the pre-transfer checksumming.
 
@@ -2340,7 +2340,7 @@ units of 1024.
 
 The default is human-readable level 1.  Each bf(-h) option increases the level
 by one.  You can take the level down to 0 (to output numbers as pure digits) by
-specifing the bf(--no-human-readable) (bf(--no-h)) option.
+specifying the bf(--no-human-readable) (bf(--no-h)) option.
 
 The unit letters that are appended in levels 2 and 3 are: K (kilo), M (mega),
 G (giga), or T (tera).  For example, a 1234567-byte file would output as 1.23M


-- 
The rsync repository.

___
rsync-cvs mailing list
rsync-cvs@lists.samba.org
https://lists.samba.org/mailman/listinfo/rsync-cvs

[Bug 13734] spelling mistakes in rsync.yo

[just subscribed for rsync-qa from bugzilla via rsync]

https://bugzilla.samba.org/show_bug.cgi?id=13734

Wayne Davison  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #1 from Wayne Davison  ---
Fix committed to git.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: --link-dest. Time to 'building file list' incrementing

[John Simpson via rsync]

Don't know how I missed this when I was trying to figure out the cheapest 
solution. I don't need the complexity but it seems to be worth investigating. 
ThanksOn 8 Jan 2019 16:15, Andrew McGlashan via rsync  
wrote:
>
> On 8/1/19 8:56 pm, John Simpson via rsync wrote:
> > Any ideas anyone?
>
> How about using snapshots and doing the rsync off those?
>
> https://www.thewindowsclub.com/vss-volume-shadow-copy-service
>
> https://blogs.technet.microsoft.com/josebda/2007/10/10/the-basics-of-the-volume-shadow-copy-service-vss/
>
> Cheers
> A.
>
> -- 
> Please use reply-all for most replies to avoid omitting the mailing list.
> To unsubscribe or change options: 
> https://lists.samba.org/mailman/listinfo/rsync
> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: --link-dest. Time to 'building file list' incrementing

[Andrew McGlashan via rsync]

On 8/1/19 8:56 pm, John Simpson via rsync wrote:
> Any ideas anyone?

How about using snapshots and doing the rsync off those?

https://www.thewindowsclub.com/vss-volume-shadow-copy-service

https://blogs.technet.microsoft.com/josebda/2007/10/10/the-basics-of-the-volume-shadow-copy-service-vss/


Cheers
A.

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: --link-dest. Time to 'building file list' incrementing

[John Simpson via rsync]

Thanks. I'll give this a go and report back.
On 8 Jan 2019 10:03, Ben RUBSON  wrote:Hi,As you are on Cygwin, you should consider the notexec & noacl mount options :https://cygwin.com/cygwin-ug-net/using.html#mount-tableThey impact stat() performance.BenOn 8 Jan 2019, at 10:56, John Simpson via rsync  wrote:Any ideas anyone?I still need at least a weekly backup of all data.The current workaround is just for the most active directories.Are there any diagnostics I can do which might shed some light on this?ThanksJohnOn 4 Jan 2019 09:53, John Simpson via rsync  wrote:KevinThe link-dest parameter is a single directory (the previous day's directory), the destination is today's directory.I haven't tried deleting a backup,  there's no particular need in space terms,  at the current rate there's enough space for several years of daily backups.I've reverted to daily backups on a small subset of the total; the full backup now takes around 30 hours.  Clearly not practical.As the small subset takes only a few minutes to complete I can't yet see if this time is incrementing too.John   On 3 Jan 2019 17:06, Kevin Korb via rsync  wrote:It does normally take some time to analyze large trees of files.  It has to call stat() on each file to get the size and timestamp. However, 15 hours seems a bit excessive even though I have never tried to do this on Windows or a NAS system.  Just to be clear, is your --link-dest parameter a single directory or are you trying to tell it to use all of the previous backups? Also, have you deleted a backup yet?  In my experience that takes a lot longer than running one so if you need 15 hours to run a backup I would expect deleting one to take about a week. On 1/3/19 4:23 AM, John Simpson via rsync wrote: I've been running rsync as a cygwin task on Windows Server 2008 for about two months now. I'm using the --link-dest option to do a daily 'snapshot' of the contents of a server containing about 10TB of data, about 13 million files, to a Linux based NAS server. Things started out great but I soon noticed that the time take to complete was slowly incrementing. It started at around three hours, but is now around fifteen. The command is as follows... rsync -rlptDhPR \  --password-file=password \  --Chmod=Du=rwx,Dgo=rx,Fu=rw,Fgo=r \  --Stats \  --delete \  --log-file=logfilename \  --link-dest=linkdestpath \  sourceDirectory \  rsync@192.168.1.2::destinationDirectory I'm not using the full -a option as the differences between the Windows and Linux ownership stuff messed things up. The first log file looked like this... 2018/10/01 23:00:14 [2164] building file list ...transfer file list here 2018/10/02 02:11:30 [2164] Number of files: 13,759,998 (reg: 12,260,176, dir: 1,499,821, link: 1) 2018/10/02 02:11:30 [2164] Number of created files: 302 (reg: 291, dir: 11) 2018/10/02 02:11:30 [2164] Number of regular files transferred: 310 2018/10/02 02:11:30 [2164] Total file size: 10.40T bytes 2018/10/02 02:11:30 [2164] Total transferred file size: 664.31K bytes 2018/10/02 02:11:30 [2164] Literal data: 277.91K bytes 2018/10/02 02:11:30 [2164] Matched data: 386.40K bytes 2018/10/02 02:11:30 [2164] File list size: 10.42M 2018/10/02 02:11:30 [2164] File list generation time: 0.154 seconds 2018/10/02 02:11:30 [2164] File list transfer time: 0.000 seconds 2018/10/02 02:11:30 [2164] Total bytes sent: 235.68M 2018/10/02 02:11:30 [2164] Total bytes received: 7.51M 2018/10/02 02:11:30 [2164] sent 235.68M bytes  received 7.51M bytes  21.17K bytes/sec 2018/10/02 02:11:30 [2164] total size is 10.40T  speedup is 42,753.79 the most recent looks like this... 2018/11/24 23:00:15 [2924] building file list 2018/11/24 23:00:17 [2924] cd..t.. /cygdrive/ 2018/11/25 13:21:16 [2924] Number of files: 13,776,423 (reg: 12,274,642, dir: 1,501,780, link: 1) 2018/11/25 13:21:16 [2924] Number of created files: 0 2018/11/25 13:21:16 [2924] Number of regular files transferred: 0 2018/11/25 13:21:16 [2924] Total file size: 10.49T bytes 2018/11/25 13:21:16 [2924] Total transferred file size: 0 bytes 2018/11/25 13:21:16 [2924] Literal data: 0 bytes 2018/11/25 13:21:16 [2924] Matched data: 0 bytes 2018/11/25 13:21:16 [2924] File list size: 10.35M 2018/11/25 13:21:16 [2924] File list generation time: 0.316 seconds 2018/11/25 13:21:16 [2924] File list transfer time: 0.000 seconds 2018/11/25 13:21:16 [2924] Total bytes sent: 236.55M 2018/11/25 13:21:16 [2924] Total bytes received: 7.51M 2018/11/25 13:21:16 [2924] sent 236.55M bytes  received 7.51M bytes  4.72K bytes/sec 2018/11/25 13:21:16 [2924] total size is 10.49T  speedup is 42,996.96 As you can see the start time is 11:00PM (23:00) in both cases. The first log shows that identifying the files to transfer took about three hours (I've omitted the file list - it's quite long), the second log takes fourteen hours to do the same job (in this case this was done at the weekend and I've include 

Re: --link-dest. Time to 'building file list' incrementing

[Ben RUBSON via rsync]

Hi,

As you are on Cygwin, you should consider the notexec & noacl mount options :
https://cygwin.com/cygwin-ug-net/using.html#mount-table 


They impact stat() performance.

Ben

> On 8 Jan 2019, at 10:56, John Simpson via rsync  wrote:
> 
> Any ideas anyone?
> 
> I still need at least a weekly backup of all data.
> 
> The current workaround is just for the most active directories.
> 
> Are there any diagnostics I can do which might shed some light on this?
> 
> Thanks
> 
> John
> 
>> On 4 Jan 2019 09:53, John Simpson via rsync  wrote:
>> 
>> Kevin
>> 
>> The link-dest parameter is a single directory (the previous day's 
>> directory), the destination is today's directory.
>> 
>> I haven't tried deleting a backup,  there's no particular need in space 
>> terms,  at the current rate there's enough space for several years of daily 
>> backups.
>> 
>> I've reverted to daily backups on a small subset of the total; the full 
>> backup now takes around 30 hours.  Clearly not practical.
>> 
>> As the small subset takes only a few minutes to complete I can't yet see if 
>> this time is incrementing too.
>> 
>> John   On 3 Jan 2019 17:06, Kevin Korb via rsync  
>> wrote:
>>> 
>>> It does normally take some time to analyze large trees of files.  It has 
>>> to call stat() on each file to get the size and timestamp. 
>>> 
>>> However, 15 hours seems a bit excessive even though I have never tried 
>>> to do this on Windows or a NAS system.  Just to be clear, is your 
>>> --link-dest parameter a single directory or are you trying to tell it to 
>>> use all of the previous backups? 
>>> 
>>> Also, have you deleted a backup yet?  In my experience that takes a lot 
>>> longer than running one so if you need 15 hours to run a backup I would 
>>> expect deleting one to take about a week. 
>>> 
>>> On 1/3/19 4:23 AM, John Simpson via rsync wrote: 
 
 
 I've been running rsync as a cygwin task on Windows Server 2008 for about 
 two months now. I'm using the --link-dest option to do a daily 'snapshot' 
 of the contents of a server containing about 10TB of data, about 13 
 million files, to a Linux based NAS server. Things started out great but I 
 soon noticed that the time take to complete was slowly incrementing. It 
 started at around three hours, but is now around fifteen. 
 
 The command is as follows... 
 
 rsync -rlptDhPR \ 
  --password-file=password \ 
  --Chmod=Du=rwx,Dgo=rx,Fu=rw,Fgo=r \ 
  --Stats \ 
  --delete \ 
  --log-file=logfilename \ 
  --link-dest=linkdestpath \ 
  sourceDirectory \ 
  rsync@192.168.1.2::destinationDirectory 
 
 I'm not using the full -a option as the differences between the Windows 
 and Linux ownership stuff messed things up. 
 
 The first log file looked like this... 
 
 2018/10/01 23:00:14 [2164] building file list 
 ...transfer file list here 
 2018/10/02 02:11:30 [2164] Number of files: 13,759,998 (reg: 12,260,176, 
 dir: 1,499,821, link: 1) 
 2018/10/02 02:11:30 [2164] Number of created files: 302 (reg: 291, dir: 
 11) 
 2018/10/02 02:11:30 [2164] Number of regular files transferred: 310 
 2018/10/02 02:11:30 [2164] Total file size: 10.40T bytes 
 2018/10/02 02:11:30 [2164] Total transferred file size: 664.31K bytes 
 2018/10/02 02:11:30 [2164] Literal data: 277.91K bytes 
 2018/10/02 02:11:30 [2164] Matched data: 386.40K bytes 
 2018/10/02 02:11:30 [2164] File list size: 10.42M 
 2018/10/02 02:11:30 [2164] File list generation time: 0.154 seconds 
 2018/10/02 02:11:30 [2164] File list transfer time: 0.000 seconds 
 2018/10/02 02:11:30 [2164] Total bytes sent: 235.68M 
 2018/10/02 02:11:30 [2164] Total bytes received: 7.51M 
 2018/10/02 02:11:30 [2164] sent 235.68M bytes  received 7.51M bytes  
 21.17K bytes/sec 
 2018/10/02 02:11:30 [2164] total size is 10.40T  speedup is 42,753.79 
 
 the most recent looks like this... 
 
 2018/11/24 23:00:15 [2924] building file list 
 2018/11/24 23:00:17 [2924] cd..t.. /cygdrive/ 
 2018/11/25 13:21:16 [2924] Number of files: 13,776,423 (reg: 12,274,642, 
 dir: 1,501,780, link: 1) 
 2018/11/25 13:21:16 [2924] Number of created files: 0 
 2018/11/25 13:21:16 [2924] Number of regular files transferred: 0 
 2018/11/25 13:21:16 [2924] Total file size: 10.49T bytes 
 2018/11/25 13:21:16 [2924] Total transferred file size: 0 bytes 
 2018/11/25 13:21:16 [2924] Literal data: 0 bytes 
 2018/11/25 13:21:16 [2924] Matched data: 0 bytes 
 2018/11/25 13:21:16 [2924] File list size: 10.35M 
 2018/11/25 13:21:16 [2924] File list generation time: 0.316 seconds 
 2018/11/25 13:21:16 [2924] File list transfer time: 0.000 seconds 
 2018/11/25 13:21:16 [2924] Total bytes sent: 236.55M 
 2018/11/25 13:21:16 [2924] Total bytes 

Re: --link-dest. Time to 'building file list' incrementing

[John Simpson via rsync]

Any ideas anyone?

I still need at least a weekly backup of all data.

The current workaround is just for the most active directories.

Are there any diagnostics I can do which might shed some light on this?

Thanks

JohnOn 4 Jan 2019 09:53, John Simpson via rsync  wrote:
>
> Kevin
>
> The link-dest parameter is a single directory (the previous day's directory), 
> the destination is today's directory.
>
> I haven't tried deleting a backup,  there's no particular need in space 
> terms,  at the current rate there's enough space for several years of daily 
> backups.
>
> I've reverted to daily backups on a small subset of the total; the full 
> backup now takes around 30 hours.  Clearly not practical.
>
> As the small subset takes only a few minutes to complete I can't yet see if 
> this time is incrementing too.
>
> John   On 3 Jan 2019 17:06, Kevin Korb via rsync  
> wrote:
> >
> > It does normally take some time to analyze large trees of files.  It has 
> > to call stat() on each file to get the size and timestamp. 
> >
> > However, 15 hours seems a bit excessive even though I have never tried 
> > to do this on Windows or a NAS system.  Just to be clear, is your 
> > --link-dest parameter a single directory or are you trying to tell it to 
> > use all of the previous backups? 
> >
> > Also, have you deleted a backup yet?  In my experience that takes a lot 
> > longer than running one so if you need 15 hours to run a backup I would 
> > expect deleting one to take about a week. 
> >
> > On 1/3/19 4:23 AM, John Simpson via rsync wrote: 
> > > 
> > > 
> > > I've been running rsync as a cygwin task on Windows Server 2008 for about 
> > > two months now. I'm using the --link-dest option to do a daily 'snapshot' 
> > > of the contents of a server containing about 10TB of data, about 13 
> > > million files, to a Linux based NAS server. Things started out great but 
> > > I soon noticed that the time take to complete was slowly incrementing. It 
> > > started at around three hours, but is now around fifteen. 
> > > 
> > > The command is as follows... 
> > > 
> > > rsync -rlptDhPR \ 
> > > --password-file=password \ 
> > > --Chmod=Du=rwx,Dgo=rx,Fu=rw,Fgo=r \ 
> > > --Stats \ 
> > > --delete \ 
> > > --log-file=logfilename \ 
> > > --link-dest=linkdestpath \ 
> > > sourceDirectory \ 
> > > rsync@192.168.1.2::destinationDirectory 
> > > 
> > > I'm not using the full -a option as the differences between the Windows 
> > > and Linux ownership stuff messed things up. 
> > > 
> > > The first log file looked like this... 
> > > 
> > > 2018/10/01 23:00:14 [2164] building file list 
> > > ...transfer file list here 
> > > 2018/10/02 02:11:30 [2164] Number of files: 13,759,998 (reg: 12,260,176, 
> > > dir: 1,499,821, link: 1) 
> > > 2018/10/02 02:11:30 [2164] Number of created files: 302 (reg: 291, dir: 
> > > 11) 
> > > 2018/10/02 02:11:30 [2164] Number of regular files transferred: 310 
> > > 2018/10/02 02:11:30 [2164] Total file size: 10.40T bytes 
> > > 2018/10/02 02:11:30 [2164] Total transferred file size: 664.31K bytes 
> > > 2018/10/02 02:11:30 [2164] Literal data: 277.91K bytes 
> > > 2018/10/02 02:11:30 [2164] Matched data: 386.40K bytes 
> > > 2018/10/02 02:11:30 [2164] File list size: 10.42M 
> > > 2018/10/02 02:11:30 [2164] File list generation time: 0.154 seconds 
> > > 2018/10/02 02:11:30 [2164] File list transfer time: 0.000 seconds 
> > > 2018/10/02 02:11:30 [2164] Total bytes sent: 235.68M 
> > > 2018/10/02 02:11:30 [2164] Total bytes received: 7.51M 
> > > 2018/10/02 02:11:30 [2164] sent 235.68M bytes  received 7.51M bytes  
> > > 21.17K bytes/sec 
> > > 2018/10/02 02:11:30 [2164] total size is 10.40T  speedup is 42,753.79 
> > > 
> > > the most recent looks like this... 
> > > 
> > > 2018/11/24 23:00:15 [2924] building file list 
> > > 2018/11/24 23:00:17 [2924] cd..t.. /cygdrive/ 
> > > 2018/11/25 13:21:16 [2924] Number of files: 13,776,423 (reg: 12,274,642, 
> > > dir: 1,501,780, link: 1) 
> > > 2018/11/25 13:21:16 [2924] Number of created files: 0 
> > > 2018/11/25 13:21:16 [2924] Number of regular files transferred: 0 
> > > 2018/11/25 13:21:16 [2924] Total file size: 10.49T bytes 
> > > 2018/11/25 13:21:16 [2924] Total transferred file size: 0 bytes 
> > > 2018/11/25 13:21:16 [2924] Literal data: 0 bytes 
> > > 2018/11/25 13:21:16 [2924] Matched data: 0 bytes 
> > > 2018/11/25 13:21:16 [2924] File list size: 10.35M 
> > > 2018/11/25 13:21:16 [2924] File list generation time: 0.316 seconds 
> > > 2018/11/25 13:21:16 [2924] File list transfer time: 0.000 seconds 
> > > 2018/11/25 13:21:16 [2924] Total bytes sent: 236.55M 
> > > 2018/11/25 13:21:16 [2924] Total bytes received: 7.51M 
> > > 2018/11/25 13:21:16 [2924] sent 236.55M bytes  received 7.51M bytes  
> > > 4.72K bytes/sec 
> > > 2018/11/25 13:21:16 [2924] total size is 10.49T  speedup is 42,996.96 
> > > 
> > > As you can see the start time is 11:00PM (23:00) in both cases. The first 
> > > log shows that