samba-bugs at samba.org
2014-Nov-21 07:46 UTC
[Bug 10951] New: Emtpy parameter triggers unwanted behavior, but no error message
https://bugzilla.samba.org/show_bug.cgi?id=10951
Bug ID: 10951
Summary: Emtpy parameter triggers unwanted behavior, but no
error message
Product: rsync
Version: 3.1.0
Hardware: x64
OS: Linux
Status: NEW
Severity: major
Priority: P5
Component: core
Assignee: wayned at samba.org
Reporter: stian at wis.no
QA Contact: rsync-qa at samba.org
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.
--
You are receiving this mail because:
You are the QA Contact for the bug.
samba-bugs at samba.org
2014-Nov-21 07:58 UTC
[Bug 10951] Emtpy parameter triggers unwanted behavior, but no error message
https://bugzilla.samba.org/show_bug.cgi?id=10951 --- Comment #1 from Stian Ertv?g <stian at wis.no> --- 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. -- You are receiving this mail because: You are the QA Contact for the bug.
Joe
2014-Nov-21 08:44 UTC
[Bug 10951] New: Emtpy parameter triggers unwanted behavior, but no error message
I didn't want to put this in Bugzilla. Hopefully the OP will see it on
this list.
I'm not sure if you have the same problem I had, but it sure looks like it:
I ran into something very similar to this around a year ago. My script
was building the rsync command and when I didn't want a dry run, the
first parameter became "". That ended up (erroneously) adding the
current directory to my sources to back up.
I posted on this list and was told essentially (much more politely) -
"It's not a bug, it's a feature."
But, a very kind and very knowledgeable soul (01/24/2013 05:58 PM,
Volker Kuhlmann) showed me how to avoid it - and make my bash code a lot
better at the same time!
Here are the essential snips of how to avoid problems like this:
...
RSYNC_OPTIONS=(
${DRY_RUN}
-avushi
${DELETE}
${EXCLUDES}
--stats
--progress
)
...
eval rsync "${RSYNC_OPTIONS[@]}" ...
When you do it like this - using a bash array with eval - (changing all
the values to match your requirements), all the null strings just go away!
It makes it easy to cleanly and clearly build a complex argument list
piece by piece in your script with as much logic as needed to make sure
that things are built correctly.
The final command is built in only one place, so any changes to
parameters which are relatively constant only have to be done in that
one place, not in many similar command invocations where a common change
might be missed in one or more instances.
It also makes the code way easier to read and maintain. I am using this
technique in other applications as well.
Joe
On 11/21/2014 02:46 AM, samba-bugs at samba.org wrote:> https://bugzilla.samba.org/show_bug.cgi?id=10951
>
> Bug ID: 10951
> Summary: Emtpy parameter triggers unwanted behavior, but no
> error message
> Product: rsync
> Version: 3.1.0
> Hardware: x64
> OS: Linux
> Status: NEW
> Severity: major
> Priority: P5
> Component: core
> Assignee: wayned at samba.org
> Reporter: stian at wis.no
> QA Contact: rsync-qa at samba.org
>
> 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.
>
samba-bugs at samba.org
2014-Nov-27 18:35 UTC
[Bug 10951] Emtpy parameter triggers unwanted behavior, but no error message
https://bugzilla.samba.org/show_bug.cgi?id=10951
Wayne Davison <wayned at samba.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Wayne Davison <wayned at samba.org> ---
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).
--
You are receiving this mail because:
You are the QA Contact for the bug.
samba-bugs at samba.org
2014-Nov-27 18:40 UTC
[Bug 10951] Emtpy parameter triggers unwanted behavior, but no error message
https://bugzilla.samba.org/show_bug.cgi?id=10951 --- Comment #3 from Wayne Davison <wayned at samba.org> --- 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". -- You are receiving this mail because: You are the QA Contact for the bug.