## rsync 3.0.6 whitespace bug.  
## reported by Steve Newcomb, srn@coolheads.com
## 2009-09-06.

## I haven't figured out any way to work around this problem:
## Apparently rsync can't handle whitespace in the source directory
## path, nor in the --backup-dir= value.  The --files-from argument
## doesn't help.  (It would help if I could put an absolute path in
## the --files-from file, maybe, but that still wouldn't fix all the
## issues, apparently.)

## first the preliminaries:
root@prilicla:/usr/local/ch-tools# /usr/local/bin/rsync --version
rsync  version 3.0.6  protocol version 30
Copyright (C) 1996-2009 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
    64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, no ACLs, xattrs, iconv, symtimes

rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
are welcome to redistribute it under certain conditions.  See the GNU
General Public Licence for details.


root@prilicla:/usr/local/ch-tools# ssh xylene 'ls /nobackup/prilicla-backup/*Wind*'
/nobackup/prilicla-backup/prilicla-_,.,_home_,.,_vtn_,.,_vmware_,.,_Windows
## The above directory is wrongly named.  The name is truncated; it
## was supposed to be "...Windows XP Professional...".  The
## wrongly-named directory was created by the last rsync run due to
## the bug I'm demonstrating for you here.

## So let's get rid of it and demonstrate the problem again...
root@prilicla:/usr/local/ch-tools# ssh xylene 'rm -rf /nobackup/prilicla-backup/*Wind*'

## Verify that it's really gone...
root@prilicla:/usr/local/ch-tools# ssh xylene 'ls /nobackup/prilicla-backup/*Wind*'
ls: cannot access /nobackup/prilicla-backup/*Wind*: No such file or directory

## So here's the rsync command that demonstrates the bug:
root@prilicla:/usr/local/ch-tools# /usr/local/bin/rsync \
-a -z -H -v -v --delete-during --delete-excluded --force --backup \
--backup-dir=/nobackup/prilicla-backup/prilicla-_,.,_home_,.,_vtn_,.,_vmware_,.,_Windows_XP_Professional_,.,_Windows_XP_Professional-flat.vmdk-previous \
--files-from=/tmp/zzz \
--no-dirs --recursive --suffix=-20090906-204639 \
'/home/vtn/vmware/Windows XP Professional' \
'xylene:/nobackup/prilicla-backup/prilicla-_,.,_home_,.,_vtn_,.,_vmware_,.,_Windows XP Professional_,.,_Windows XP Professional-flat.vmdk'

## here's the output from rsync:
backup_dir is /nobackup/prilicla-backup/prilicla-_,.,_home_,.,_vtn_,.,_vmware_,.,_Windows_XP_Professional_,.,_Windows_XP_Professional-flat.vmdk-previous/
## That's correct, but only because I replaced the spaces in the --backup-dir= value.
## If I don't replace the spaces, this path is truncated, too.

opening connection using: ssh xylene rsync --server -vvblHogDtprRze.iLs --backup-dir /nobackup/prilicla-backup/prilicla-_,.,_home_,.,_vtn_,.,_vmware_,.,_Windows_XP_Professional_,.,_Windows_XP_Professional-flat.vmdk-previous --suffix=-20090906-204639 --delete-during --delete-excluded --force . "/nobackup/prilicla-backup/prilicla-_,.,_home_,.,_vtn_,.,_vmware_,.,_Windows XP Professional_,.,_Windows XP Professional-flat.vmdk" 

backup_dir is /nobackup/prilicla-backup/prilicla-_,.,_home_,.,_vtn_,.,_vmware_,.,_Windows_XP_Professional_,.,_Windows_XP_Professional-flat.vmdk-previous/
## Not sure why this information is repeated.

sending incremental file list
delta-transmission enabled
Windows XP Professional-flat.vmdk
total: matches=0  hash_hits=0  false_alarms=0 data=450

sent 410 bytes  received 31 bytes  882.00 bytes/sec
total size is 450  speedup is 1.02


## but now let's see what happened:
root@prilicla:/usr/local/ch-tools# ssh xylene 'ls /nobackup/prilicla-backup/*Wind*'
/nobackup/prilicla-backup/prilicla-_,.,_home_,.,_vtn_,.,_vmware_,.,_Windows

## see, it made the copy in the wrong directory -- I mean, the name of the directory
## in which it dumped the file is incorrect.

## And the file in the directory (not shown here) is misnamed, too, in
## the same way: the name is truncated at the first space.  I suspect
## that this file was overwritten several times, because several files
## in this directory have names that are identical if they are
## truncated at the first space.