search for: parse_argu

Hello, I found the reason why "refuse options" is ignored on the server side. When then 5th argument (int val) in the poptOption struct is set to zero, the parsing function poptGetNextOpt() just continues with the next arg, without returning. So check_refuse_options() is simply not called in such cases. The attached patch makes "refuse options" work with checksum and

...reated attachment 13732 --> https://bugzilla.samba.org/attachment.cgi?id=13732&action=edit patch to handle argc == 0 $ bin/rsync --version rsync version 3.1.3dev protocol version 31 this exist in 3.1.2 as well. rsyncd reads in arguments from the connecting client. These are parsed in parse_arguments.parse_arguments parses what it can via popt, and increments argv and decrements argc to reflect the consumed values. The problem is that do_server_sender is expecting at least 1 argument to use as dir 786 char *dir = argv[0]; When there are no arguments in argv this leads a a NULL dere...

Hopefully the email to the announce list will show up soon. Until then, you can get a jump on the rest by checking out the rsync home page to read the announcement: http://rsync.samba.org/ It includes a security note about a fix that affects read/write daemons that are not using chroot. If that includes you, you should look into upgrading (or maybe enabling chroot on an older rsync).

...har *addr, char *host) ic_recv = (iconv_t)-1; } } +#endif if (!numeric_ids && (use_chroot ? lp_numeric_ids(i) != False : lp_numeric_ids(i) == True)) diff --git a/options.c b/options.c index 7f69bd2..75ceeeb 100644 --- a/options.c +++ b/options.c @@ -1137,7 +1137,9 @@ int parse_arguments(int *argc_p, const char ***argv_p, int frommain) break; case OPT_NO_ICONV: +#ifdef ICONV_OPTION iconv_opt = NULL; +#endif break; case OPT_MAX_SIZE:

..."compiler-rt"'s CMake needs to know about targets in the Clang build tree ("clang") and in LLVM build tree ("FileCheck", llvm-* command-line tools, googletest etc.), and uses common macro from LLVM's CMake modules like "configute_lit_site_cfg", "parse_arguments". 2) top-level targets from compiler-rt's CMake files are visible at the root of LLVM's build tree, so that I can run "make check-asan" or even "make clang_rt.asan-x86_64" from the root of the build tree. Will we easily retain all these capabilities if we turn...

I'm having an issue with the --suffix and -b flags - I've tried the following commands: rsync -avbr --backup-dir=/rsyncbackup rsynctest user@server.com::module rsync -avbr --backup-dir=/rsyncbackup --suffix="" rsynctest user@server.com::module and either way, I wind up with a tilde as a suffix on all the files moved into the backup directory at time of synchronization.

Kudos all that maintain this awesome and enduring piece of software. Awesome job, many thanks. I’ve come across a use case that would greatly benefit form a —delete-older-than <secs> argument. This would behave the same as —delete only sparing files dest that have a creating time less than <secs> ago. How hard would this be to implement? Where would I start ? TIA, Francois

...&do_compression, 0, 0, 0 }, @@ -1163,6 +1173,7 @@ static void set_refuse_options(char *bp) refused_archive_part = op->val; break; case 'z': + case 'Z': refused_compress = op->val; break; case '\0': @@ -1575,6 +1586,16 @@ int parse_arguments(int *argc_p, const char ***argv_p) do_compression++; break; + case 'Z': +#ifdef HAVE_LIBZSTD + do_compression_zstd++; +#else + snprintf(err_buf, sizeof err_buf, + "Support for zstd is not enabled.\n"); + return 0; +#endif + break; + case 'M'...

...{"out-format", 0, POPT_ARG_STRING, &stdout_format, 0, 0, 0 }, {"log-format", 0, POPT_ARG_STRING, &stdout_format, 0, 0, 0 }, /* DEPRECATED */ {"itemize-changes", 'i', POPT_ARG_NONE, 0, 'i', 0, 0 }, @@ -2359,7 +2363,10 @@ int parse_arguments(int *argc_p, const char ***argv_p) if (logfile_name && !am_daemon) { if (!logfile_format) { - logfile_format = "%i %n%L"; + if (log_after_transfer) + logfile_format = "%o %i %n%L"; + else + logfile_format = "%i %n%L"; logfile_format_...

...000 1.127 +++ options.c 27 Jan 2004 08:00:54 -0000 @@ -66,6 +66,7 @@ int read_only = 0; int module_id = -1; int am_server = 0; int am_sender = 0; +char *who_am_i = "receiver"; char *files_from = NULL; int filesfrom_fd = -1; char *remote_filesfrom_file = NULL; @@ -554,6 +555,7 @@ int parse_arguments(int *argc, const cha usage(FERROR); exit_cleanup(RERR_SYNTAX); } + who_am_i = "sender"; am_sender = 1; break;

...r delta-time to define what counts as 'recent' as well as the pattern to match for this rule to apply (which could just be a wildcard matching anything by default, but could also use the full pattern-matching capabilities if required). Have a look at: the 'make_backups' logic in parse_arguments(), where it adds a 'Preserve' pattern to match all backup files, name_is_excluded() and its subfunctions check_filter() and rule_matches() in exclude.c You'd need to: define a new filter-type character ('R' for preserve-Recent?) define the format of the filter rule for...

rsync-2.6.6 manpage says: --delete [...] This option has no effect unless directory recursion is enabled. True. In fact, I noted that --delete doesn't delete anything if --dirs is used rather than --recursive. Is there any reason for --delete not to delete when used with --dirs? Is there a way to get rsync to actually delete files on the receiving end when using

Hiya. While merging the 2.6.0 changes into our modified version of rsync, I noticed the following bit of code in 2.6.0's options.c: extern int sanitize_paths; if (sanitize_paths) sanitize_path(strdup(files_from), NULL); filesfrom_fd = open(files_from, O_RDONLY|O_BINARY); Since sanitize_path modifies its first argument in place, the path that open()

Using rsync 2.6.0 on both ends, I ran rsync -v --files-from files andrew@pimlott.net: . and got an error from the remote rsync. The reason is that the remote rsync is run as rsync --server --sender -vvR --files-from=- --from0 . which conflicts with a check in options.c that rsync must have two non-option arguments when --files-from is used. I tried again with the latest nightly

Patch to add an archive mode that includes deletion. -Rob -------------- next part -------------- Adds an archive mode that includes the delete option. --- orig/options.c 2004-09-23 13:39:05.000000000 -0400 +++ options.c 2004-11-13 09:56:27.000000000 -0500 @@ -39,6 +39,7 @@ int whole_file = -1; int archive_mode = 0; +int archive_delete_mode = 0; int keep_dirlinks = 0; int copy_links = 0;

Dear rsync people (particularly Wayne), I noticed that an rsync daemon counts on the client sending a --server option so that am_server gets set to 1. If the client doesn't supply this option, am_server remains 0 but the daemon runs start_server anyway. This is potentially dangerous and might lead to a security hole, although I haven't found one yet. I suggest that the daemon either

--- ?More work on backup-dir-dels... options.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/options.c b/options.c index 459ad58..ed21704 100644 --- a/options.c +++ b/options.c @@ -1479,6 +1479,11 @@ int parse_arguments(int *argc_p, const char ***argv_p, int frommain) backup_suffix); return 0; } + /* --suffix-dels defaults to --suffix, or empty for a client given an + * explicit --backup-dir-dels (just as --suffix defaults to empty when + * a --backup-dir is given). The second case does not apply...

...ERROR CCN3273 ./zlib/zlib.h:124 Missing type in declaration of gz_header. ERROR CCN3166 ./zlib/zlib.h:126 Definition of function gz_header requires pare ntheses. ERROR CCN3276 ./zlib/zlib.h:126 Syntax error: possible missing '{'? ERROR CCN3343 ./options.c:895 Redeclaration of parse_arguments differs from pr evious declaration on line 252 of "./proto.h". WARNING CCN3280 ./options.c:924 Function argument assignment between types "co nst char**" and "char**" is not allowed. WARNING CCN3280 ./options.c:942 Function argument assignment between t...

...buf at entry=0x7fffffffbe50 "xxh128 xxh3 xxh64 (xxhash) md5p8 md5 md4 none (", to_buf_len=to_buf_len at entry=256, dup_markup=dup_markup at entry=40 '(') at compat.c:478 #3 0x000000000043d717 in print_rsync_version (f=f at entry=FINFO) at usage.c:194 #4 0x000000000042fcee in parse_arguments (argc_p=argc_p at entry=0x7fffffffc0dc, argv_p=argv_p at entry=0x7fffffffc0d0) at options.c:1897 #5 0x0000000000404de1 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1747 %% Turns out the comment in rsync.h: (struct name_num_obj): struct name_num_item li...

Hi all, today we had a performance issue transfering a big amount of data where one file was over 50GB. Rsync was tunneled over SSH and we expected the data to be synced within hours. However after over 10 hours the data is still not synced ... The sending box has rsync running with 60-80 % CPU load (2GHz Pentium 4) while the receiver is nearly idle. So far I had no acces to the poblematic