Hello rsync developers and users, I've just updated some of our CentOS servers from 7.4 to 7.5, and rsync on these servers went from version 3.0.9 to 3.1.2. This newer rsync version appears to be sending -C and -x options to the server, even though they are not set on the client side. The client is called like this: rsync -rlptgo -qz --del --timeout=180 user at server /local/path On the server, we have a wrapper script that parses all the options that the client sends, with: options=$(getopt -l server,sender,timeout: -o vnlogDtprzde.iLsf -- $SSH_ORIGINAL_COMMAND) Now getopt keeps emitting errors that the -C and -x options are unrecognised. Is this a recent change in rsync to set these options even if the user hasn't specified them? Regards, Anand
On Wed, May 16, 2018 at 10:04 AM Anand Buddhdev via rsync < rsync at lists.samba.org> wrote:> This newer rsync version appears to be sending -C and -x options to the > server, even though they are not set on the client side. >It's not. What it is doing is sending information in the -eSTRING option that tells the server some extra compatibility info that can apply to even older protocol versions. In the --server -e arg's string the 'x' and 'C' flag characters can be present these days, and more internal flags may be added in the future. So, it sounds like you just need to fix your option parsing to recognize that -e is followed by a free-form string arg. Also note that when --server is specified, the -e arg has a different meaning than it does to the client, so don't be confused by the -e option in the manpage. ..wayne.. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.samba.org/pipermail/rsync/attachments/20180516/180a1cb3/attachment.html>