[SCM] The rsync repository. - branch master updated
The branch, master has been updated via c90b87e0 Avoid a failed test if dirs report 1 hlink (e.g. WSL weirdness). from ad17b218 Silence fall-through warnings. https://git.samba.org/?p=rsync.git;a=shortlog;h=master - Log - commit c90b87e021709be78853354bd7776acfdd1c95d9 Author: Wayne Davison Date: Fri Jan 4 21:43:50 2019 -0800 Avoid a failed test if dirs report 1 hlink (e.g. WSL weirdness). --- Summary of changes: testsuite/xattrs.test | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Changeset truncated at 500 lines: diff --git a/testsuite/xattrs.test b/testsuite/xattrs.test index f7d9a6df..86165e0c 100644 --- a/testsuite/xattrs.test +++ b/testsuite/xattrs.test @@ -163,7 +163,7 @@ checkit "$RSYNC -aiX $XFILT $dashH --fake-super --link-dest=../chk . ../to" "$ch cd "$todir" xls $dirs $files | diff $diffopt "$scratchdir/xattrs.txt" - -sed -n -e '/^[^ ][^ ]* *[^ ][^ ]* *[^ ][^ ]* *1 /p' "$scratchdir/ls-to" >"$scratchdir/ls-diff-all" +sed -n -e '/^[^d ][^ ]* *[^ ][^ ]* *[^ ][^ ]* *1 /p' "$scratchdir/ls-to" >"$scratchdir/ls-diff-all" fgrep -v './file1' "$scratchdir/ls-diff-all" >"$scratchdir/ls-diff" || : if [ -s "$scratchdir/ls-diff" ]; then echo "Missing hard links on:" -- The rsync repository. ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
[SCM] The rsync repository. - branch master updated
The branch, master has been updated
via ad17b218 Silence fall-through warnings.
from a3668685 Avoid a potential out-of-bounds read in daemon mode if
argc is 0.
https://git.samba.org/?p=rsync.git;a=shortlog;h=master
- Log -
commit ad17b2188958dabe2f957cde1357ae70f75d3bbd
Author: Wayne Davison
Date: Fri Jan 4 15:06:30 2019 -0800
Silence fall-through warnings.
---
Summary of changes:
acls.c | 6 ++
case_N.h | 16
cleanup.c | 7 ---
hashtable.c| 11 +++
tls.c | 2 +-
util.c | 4
zlib/inflate.c | 3 ++-
7 files changed, 32 insertions(+), 17 deletions(-)
Changeset truncated at 500 lines:
diff --git a/acls.c b/acls.c
index 8d97df63..7351ad68 100644
--- a/acls.c
+++ b/acls.c
@@ -1117,14 +1117,12 @@ int default_perms_for_dir(const char *dir)
case ENOSYS:
/* No ACLs are available. */
break;
- case ENOENT:
- if (dry_run) {
+ default:
+ if (dry_run && errno == ENOENT) {
/* We're doing a dry run, so the containing
directory
* wasn't actually created. Don't worry about
it. */
break;
}
- /* Otherwise fall through. */
- default:
rprintf(FWARNING,
"default_perms_for_dir: sys_acl_get_file(%s,
%s): %s, falling back on umask\n",
dir, str_acl_type(SMB_ACL_TYPE_DEFAULT),
strerror(errno));
diff --git a/case_N.h b/case_N.h
index a21cf94d..f15d1d60 100644
--- a/case_N.h
+++ b/case_N.h
@@ -25,51 +25,67 @@
case 0:
#elif !defined CASE_N_STATE_1
#define CASE_N_STATE_1
+ /* FALLTHROUGH */
case 1:
#elif !defined CASE_N_STATE_2
#define CASE_N_STATE_2
+ /* FALLTHROUGH */
case 2:
#elif !defined CASE_N_STATE_3
#define CASE_N_STATE_3
+ /* FALLTHROUGH */
case 3:
#elif !defined CASE_N_STATE_4
#define CASE_N_STATE_4
+ /* FALLTHROUGH */
case 4:
#elif !defined CASE_N_STATE_5
#define CASE_N_STATE_5
+ /* FALLTHROUGH */
case 5:
#elif !defined CASE_N_STATE_6
#define CASE_N_STATE_6
+ /* FALLTHROUGH */
case 6:
#elif !defined CASE_N_STATE_7
#define CASE_N_STATE_7
+ /* FALLTHROUGH */
case 7:
#elif !defined CASE_N_STATE_8
#define CASE_N_STATE_8
+ /* FALLTHROUGH */
case 8:
#elif !defined CASE_N_STATE_9
#define CASE_N_STATE_9
+ /* FALLTHROUGH */
case 9:
#elif !defined CASE_N_STATE_10
#define CASE_N_STATE_10
+ /* FALLTHROUGH */
case 10:
#elif !defined CASE_N_STATE_11
#define CASE_N_STATE_11
+ /* FALLTHROUGH */
case 11:
#elif !defined CASE_N_STATE_12
#define CASE_N_STATE_12
+ /* FALLTHROUGH */
case 12:
#elif !defined CASE_N_STATE_13
#define CASE_N_STATE_13
+ /* FALLTHROUGH */
case 13:
#elif !defined CASE_N_STATE_14
#define CASE_N_STATE_14
+ /* FALLTHROUGH */
case 14:
#elif !defined CASE_N_STATE_15
#define CASE_N_STATE_15
+ /* FALLTHROUGH */
case 15:
#elif !defined CASE_N_STATE_16
#define CASE_N_STATE_16
+ /* FALLTHROUGH */
case 16:
#else
#error Need to add more case statements!
diff --git a/cleanup.c b/cleanup.c
index 95595f10..c3ae7999 100644
--- a/cleanup.c
+++ b/cleanup.c
@@ -138,7 +138,6 @@ NORETURN void _exit_cleanup(int code, const char *file, int
line)
who_am_i(), code, file, line);
}
- /* FALLTHROUGH */
#include "case_N.h"
switch_step++;
@@ -152,7 +151,6 @@ NORETURN void _exit_cleanup(int code, const char *file, int
line)
}
}
- /* FALLTHROUGH */
#include "case_N.h"
switch_step++;
@@ -183,7 +181,6 @@ NORETURN void _exit_cleanup(int code, const char *file, int
line)
}
}
- /* FALLTHROUGH */
#include "case_N.h"
switch_step++;
@@ -195,7 +192,6 @@ NORETURN void _exit_cleanup(int code, const char *file, int
line)
if (!exit_code && !code)
io_flush(FULL_FLUSH);
- /* FALLTHROUGH */
#include "case_N.h"
switch_step++;
@@ -226,7 +222,6 @@ NORETURN void _exit_cleanup(int code, const char *file, int
line)
|| am_daemon || (logfile_name && (am_server ||
!INFO_GTE(STATS, 1
log_exit(exit_code, exit_file, exit_line);
- /* FALLTHROUGH */
#include "case_N.h"
switch_step++;
@@ -238,7 +233,6 @@ NORETURN
Re: --link-dest. Time to 'building file list' incrementing
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 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 the whole log file which correctly identifies that > > no files have changed) > > > > The number of files is as might be expected as is everything else. It's > > just the time taken "building file list" is significantly larger. > > > >
