Question regarding --delete-during/after and backup file cases

[Matt McCutchen]

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