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

[Michal Soltys]

Matt McCutchen wrote:
> 
> (It would have made my life easier if you had replied directly to that
> message so I didn't have to search for it.)
> 

Ahh yes - it was an old thread back from June - I kinda did, but the 
question was a bit weird & different and the thread ended.

Either way, sorry.

>> 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
> 

I could swear I tested such (basic) scenario - I must have had backup 
files sitting already in dest/ dir, or I didn't update source file. Oh 
well :o

Big thanks for the example - that tiny detail kept bugging me all the time.

Michal