weird interaction between --delete-delay and --partial-dir when transfer is interrupted

[Shivkumar Venkatasubrahmanyam]

Hi,

I'm not sure if this is a bug, but after reading the manual, this does 
not seem like expected behavior.  I'm using the following rsync command 
to approximate an atomic update (I can't use --link-dest as hard links 
in hfsplus filesystems are fubar under linux as of 2.6.27):

rsync -a --delete-excluded --backup --backup-dir=../bar.archive 
--backup-suffix=.2008-12-15-0115 --delete-delay --delay-updates 
--partial-dir=.rsync-partial --verbose --human-readable 
--log-file=/bar.rsync-log host:/foo/ /bar

If a transfer is interrupted, .rsync-partial/ directories are left over 
in the backup directory, as expected. The next rsync run exits with 
non-zero exit status even though all files are transferred (verified 
this using md5sum). A third rsync run transfers nothing (going by the 
log file) but exits with success.  I'm guessing this is because: (1) 
--delete-excluded causes the .rsync-partial/ directories to be marked 
for deletion during file list generation time of the second rsync run 
(there are no .rsync-partial/ directories in host:/foo/), (2) successful 
transfer of all files during the second run results in rsync removing 
the .rsync-partial/ directories as they become empty, and (3) 
--delete-delay which I understand is necessary to allow rsync to use the 
files in .rsync-partial/ to speed up the second transfer, fails to find 
the .rsync-partial/ directories at the end of the transfer and 
complains.  The third transfer sees no .rsync-partial/ directories in 
/bar and so returns success.

I would like the second run to return success if all files are 
transferred.  Is there some option I'm supposed to use (e.g. --filter) 
or is this a bug?

Shiv