rsync - Oct 2008 - Question regarding --delete-during/after and backup file cases

A good while ago I asked about difference between --delete-during/delay 
and --delete-after, when per-directory files are updated (all is 
perfectly clear for me here), but during the discussion there was a hint 
made by Wayne, that the outcome can differ in more situations:

" It is useful for things such as --delay-updates --delete-delay (to 
have all updates happen more rapidly at the end), and the option avoids 
an extra dir-scan delete pass in such a case.  And for folks that don't 
have per-dir filter files being updated, it works the same as 
--delete-after (if we disregard certain backup-file cases where the 
suffix is not excluded), just more optimally. "

If I understand it correctly - those "backup-file cases" mean -b
option
and - accidental or deliberate - override of the protect rule added 
implicitly by rsync (as explained in the man page). But if this rule is 
overriden (effectivly allowing deletion of backuped files), then 
assuming no per-dir rules are changed, the outcome will be the same 
regardless if we use --delete-during + --delete-delay or --delete-after.

So there must be something I missed or misunderstood. Could someone 
provide me a simple example of such backup-file case ?

On Wed, 2008-10-22 at 14:38 +0200, Michal Soltys wrote:
> A good while ago I asked about difference between --delete-during/delay 
> and --delete-after, when per-directory files are updated (all is 
> perfectly clear for me here), but during the discussion there was a hint 
> made by Wayne, that the outcome can differ in more situations:
> 
> " It is useful for things such as --delay-updates --delete-delay (to 
> have all updates happen more rapidly at the end), and the option avoids 
> an extra dir-scan delete pass in such a case.  And for folks that don't
> have per-dir filter files being updated, it works the same as 
> --delete-after (if we disregard certain backup-file cases where the 
> suffix is not excluded), just more optimally. "
(It would have made my life easier if you had replied directly to that
message so I didn't have to search for it.)
> If I understand it correctly - those "backup-file cases" mean -b
option
> and - accidental or deliberate - override of the protect rule added 
> implicitly by rsync (as explained in the man page). But if this rule is 
> overriden (effectivly allowing deletion of backuped files), then 
> assuming no per-dir rules are changed, the outcome will be the same 
> regardless if we use --delete-during + --delete-delay or --delete-after.
I found one case where the outcome differs.  If the protect filter is
overridden and a destination file is backed up before being *updated*,
then --delete-after will delete the backup file but --delete-delay won't
(because it checks for deletions before the backup file is created in
the first place).  E.g., with this sequence of commands:

mkdir src dest
touch dest/foo
echo NEWDATA >src/foo
rsync -r --delete-WHEN --filter='R *' -b src/ dest/

dest/foo~ will exist at the end if WHEN is "delay" but not if WHEN is
"after".

I can't think of any other such cases when no per-dir rules are changed,
but that doesn't mean there aren't any: an rsync run is a complex
process with numerous steps that can interact in unexpected ways.

Matt