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
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
