[Bug 13901] Empty quotes adds cwd to SRC directories

[samba-bugs at samba.org]

https://bugzilla.samba.org/show_bug.cgi?id=13901

--- Comment #1 from Dave Gordon <dg32768 at zoho.eu> ---
It probably wouldn't be difficult to spot the case you've identified and change
the behaviour; I suspect you'd just need to change this code around line 2134
of flist.c, in send_file_list() to handle the case of (!len) separately (e.g.
error, or ignore):

                len = strlen(fbuf);
                if (relative_paths) {
                        /* We clean up fbuf below. */
                        name_type = NORMAL_NAME;
>>>>            } else if (!len || fbuf[len - 1] == '/') {
                        if (len == 2 && fbuf[0] == '.') {
                                /* Turn "./" into just "." rather than "./." */
                                fbuf[--len] = '\0';
                        } else {
                                if (len + 1 >= MAXPATHLEN)
                                        overflow_exit("send_file_list");
                                fbuf[len++] = '.';
                                fbuf[len] = '\0';
                        }
                        name_type = DOTDIR_NAME;
                } else if (len > 1 && fbuf[len-1] == '.' && fbuf[len-2] == '.'

BUT there are other parts of the code that have already processed the arglist
and in some cases rewritten it, and argpath parsing is already pretty
complicated, because of handling lots of different cases (local or remote
source(s), local or remote target, different syntaxes (rsync://host[/path],
[host:]path, host::module[/path]), etc).

In particular, an empty pathname part when accessing a daemon-defined module
will already have been rewritten as ".", and since this is a useful (and
probably widely-used) case, you wouldn't want to change that. In which case,
you would have to accept an inconsistency between daemon (module) access, where
empty does (and should) mean "." and non-daemon mode, where you want it
rejected.

As a simple workaround, consider using the shell syntax "${VAR?}" which will
cause a shell error exit if the variable is unset -- which will make the
problem obvious and reasonably easy to debug.

$ rsync -aSHAXuvn "${VAR?}" ~/bin/ /tmp/
bash: VAR: parameter null or not set

Or ${VAR:+"$VAR"}"${VAR:-mydefault}" which will insert VAR if set, or the
default of your choice in the event that VAR is somehow unset. Depending on
what outcome you want, you could set it to a flag that rsync doesn't recognise,
and then rsync will complain about the command line:

$ rsync -aSHAXuvn ${VAR:+"$VAR"}"${VAR:---VAR-unset}" ~/bin/ /tmp/
rsync: --VAR-unset: unknown option
rsync error: syntax or usage error (code 1) at main.c(1572) [client=3.1.1]

If the chosen default is a path that doesn't exist you'll get a nonfatal error
from rsync, but any other files you intended to copy will still get copied.

rsync -aSHAXuvn ${VAR:+"$VAR"}"${VAR:-./nosuchfile}" ~/bin/ /tmp/
sending incremental file list
rsync: link_stat "./nosuchfile" failed: No such file or directory (2)
./
[...]

sent 2,587 bytes  received 873 bytes  6,920.00 bytes/sec
total size is 791,762  speedup is 228.83 (DRY RUN)
rsync error: some files/attrs were not transferred (see previous errors) (code
23) at main.c(1183) [sender=3.1.1]

Hope this helps,
Dave

-- 
You are receiving this mail because:
You are the QA Contact for the bug.