Spaces in directory names break lsyncd at run-time about lsyncd HOT 10 CLOSED

This bug is still open in version 1.33.

Think of the following test case:
We want to sync the local folder syncme to myserver.org.

The local directory layout is as follows:
/syncme/my spaced dir/some file.txt
/syncme/my spaced dir/some other file.txt

And this is how the server receives it:
/syncme/my spaced dir/              ## an empty folder
/syncme/my/some file.txt            ## our two files will actually be stored 
under this broken up name
/syncme/my/some other file.txt

The bug does not occur on initial sync.

The following happens while monitoring /syncme with lsyncd:
$ cd /syncme
/syncme $ mkdir "my spaced dir"                      ## this will start rsync 
and will
                                                                      ## create "some spaced dir" folder on the destination
/syncmde $ touch "my spaced dir/some file.txt" ## this starts rsync again but 
now the file
                                                                      ## will be safed to "my/some file.txt"

First I thought that the bug is triggered by wrong escaping but since the 
application uses execv for calling rsync there should be no problem.
By calling above like commands the bug is always reproduceable.

Sorry, it works for me.
Maybe this a rsync bug? I'm using 2.6.9

I just ran into this issue as well.

I think the problem is that rsync sends command lines to the remote host. In 
particular, the command

 rsync -av '/abc/def ghj/kl mn/' 'host:/abc/def ghj/kl mn/'

does not work (and this is what lsyncd issues). The remote path must be 
explicitly escaped, e.g. as

 rsync -av '/abc/def ghj/kl mn/' 'host:"/abc/def ghj/kl mn/"'

(cf. http://www.samba.org/rsync/FAQ.html#9)

One way to work around this is to pass the option "--protect-args" to rsync.

After adding <option text="--protect-args"/> to the <callopts> section of my 
lsyncd.conf.xml, directories with spaces appear to be synced just fine. Should 
this option be on by default?

it sounds useful, strange enough my rsync does not know this option.
You know at which rsync version this was introduced or removed?
Neither is it included in my rsyncs manpage.

# rsync --protect-args 44 55
rsync: --protect-args: unknown option
rsync error: syntax or usage error (code 1) at main.c(1318) [client=2.6.9]

It looks like this option was added with version 3.0.0.
(http://www.samba.org/ftp/rsync/src/rsync-3.0.0-NEWS)
Sorry, I didn't realize this option was new.

I'm thinking of how to solve this issue most elegantly. I could per default 
probe for rsyncs version, or just add -s (protect-args) per default, and deal 
with people complaining it doesnt work with < 3.0. I guess turning it on per 
default is a useful think, plus a probe and warning if rsync is < 3.0

I suppose the best solution would be to escape file names in lsyncd, so that it 
will also work with all versions of rsync ;-). 

I guess that it would be enough to turn any path of the form 
"hostname:pathname" into "hostname:'pathname'". But I'm not sure how to do this 
reliably, since it would require some parsing of source and target paths. One 
could perhaps use rsync's function parse_hostspec from option.c to do the 
parsing (if licensing allows). But this looks a little fragile as well, as one 
should want to keep in sync with rsync then.

Anyway, I'm happy with protect-args for now.

I'll add -s (protect-args) as default value.

Its better than mangling around with pathnames to get rsync in a behavior I 
think it should have been using as default from get go. Seems the only one 
using a production system old enough to have rsync 2.x is me ;-)

Generally most times I try to not tinker lsyncd too much to the special needs 
of rsync, but be a generall binary calling on event happening daemon.

Version 1.38 now has -s in the default arguments. I suppose this is now thus 
fixed.