Bug 823088

Description of problem:
  If rsync is given a list of files containing differing relative directory
  prefixes, it will loose track of the source files.

Version-Release number of selected component (if applicable):
  rsync-3.0.8-2.fc16.x86_64

How reproducible:
  Try to rsync files locally from more than one local directory.
  rsync gets lost after it processes the first different source directory.

Steps to Reproduce:
1. Setup:
  % mkdir /tmp/test
  % cd /tmp/test
  % mkdir -p c/d dest
  % touch a.c b.c c/d/e.c f.c

2. Run rsync:
  % rsync -av --update a.c b.c c/d/e.c f.c dest/
  sending incremental file list
  a.c
  b.c
  e.c
  f.c


3. Run another rsync:
  % rm -f dest/*
  % rsync -av --update ./a.c ./b.c ./c/d/e.c ./f.c dest/
  sending incremental file list
  rsync: link_stat "/tmp/tvb-test/f.c" failed: No such file or directory (2)
  file has vanished: "/tmp/tvb-test/a.c"
  file has vanished: "/tmp/tvb-test/b.c"
  e.c

  sent 125 bytes  received 69 bytes  388.00 bytes/sec
  total size is 0  speedup is 0.00
  rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1052) [sender=3.0.8]

  The files have NOT vanished.  It is just that rsync has lost track of
  where they were.
  
Actual results:
  The directory only contains e.c.

Expected results:
  The directory "dest" should contain a.c, b.c, e.c, and f.c.


Additional info:
  If "f.c" is not prefaced with "./" then the rsync works.
  If None of the files are prefaced with "./" the rsync works.
  If the list is ./a.c ./b.c ./f.c ./c/d/e.c the rsync works
  if it is already up-to-date but fails if not.