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

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

Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options:
Before posting, read: