Bug 10951 - Emtpy parameter triggers unwanted behavior, but no error message
Emtpy parameter triggers unwanted behavior, but no error message
Product: rsync
Classification: Unclassified
Component: core
x64 Linux
: P5 major
: ---
Assigned To: Wayne Davison
Rsync QA Contact
Depends on:
  Show dependency treegraph
Reported: 2014-11-21 07:46 UTC by Stian Ertvåg
Modified: 2014-11-27 18:40 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Stian Ertvåg 2014-11-21 07:46:33 UTC
If you add a parameter (ex. --exclude <path>) to the rsync command without a value, you get some unwanted behavior running the command. No error message will be triggered, and no output will be shown (especially if running the command from remote server through a SSH session).

We were running the following command for backup of a remote server: "/usr/bin/ssh -x -l backuppc <servername>.<domain>.lan sudo /usr/bin/rsync --numeric-ids --perms --owner --group -D --links --hard-links --times --block-size=2048 --recursive / --exclude --exclude /mnt --exclude /var/log/tomcat6"

If you check after the "--recursive /" there is two "--exclude" and the first one without a value. If we run this command there is no output from rsync before the ssh session outputs a "pipe is broken" message. The rsync continues to run on the ssh session. There is no output running the command locally either. 

With the emtpy "--exclude", and a new "--exclude" after the empty one, it seems like rsync interpits the two exclude folders as destination for syncronization. We also seem to get at loop when syncing the /mnt folder aswell, due to syncronization of itself into itself (this is not testet since this happend on a production server).

When we ran the command written futher up in this text, we got a copy of / (root) in both "/mnt" and "/var/log/tomcat6". In "/mnt" we also got many subfolders with their own copies of the root, all folder in root down to the "/mnt" folder. Seems to be looping.
Comment 1 Stian Ertvåg 2014-11-21 07:58:05 UTC
The "--exclude" without a value was of course a punshing error in our system, but we think this should trigger an error instead of syncing to the folder defined as excluded. The lack of output may occour because of the /mnt looping.
Comment 2 Wayne Davison 2014-11-27 18:35:11 UTC
Since the command-line you mentioned is completely valid, there's no error for rsync to complain about.  Your args specified "--exclude --exclude" (so that it won't transfer a file named "--exclude") and then specified "/mnt" as a source or destination arg (depending on where it appears in the list of args).

One thing you could possibly do to make the arg parsing stricter is to "export POSIXLY_CORRECT=1" in the environment.  That makes popt stop parsing options at the first non-option it finds, so something like "--exclude --exclude /mnt --del /src/ /dest/" would at least complain about the file "--del" not existing while it was copying /mnt and /src/ to /dest (though it doesn't stop the copying from happening).
Comment 3 Wayne Davison 2014-11-27 18:40:52 UTC
Let me also add that if the cause was a bash shell variable that ended up being empty, then you should note that it is a bash-ism to require parameters to be double-quoted in order for them to behave sanely (e.g. --exclude "$arg") whereas other shells (such as zsh) default to a saner behavior for something like "--exclude $arg".