delete-delay vs. delete-after in 3.0.2 (and possible bug)

Michal Soltys soltys at
Wed Jun 18 20:44:34 GMT 2008

Wayne Davison wrote:
> Diffs are always welcomed.  Please feel free.
> ..wayne..

Allright, tiny update to the rsync.yo file.

I haven't included information about backup/suffix case you mentioned, 
as I'm not sure about the details yet.

-------------- next part --------------
---	2008-05-17 18:45:28.000000000 +0200
+++ rsync.yo	2008-06-18 22:38:48.000000000 +0200
@@ -1170,6 +1170,13 @@
 using bf(--delete-after) (which it cannot do if bf(--recursive) is doing an
 incremental scan).
+bf(--delete-delay) is particulary useful with bf(--delay-updates) option, as
+it avoids an extra dir-scan delete pass in such case.
+Note, that bf(--delete-delay) is not equivalent to bf(--delete-after), when
+per-directory rules on the receiving and sending side are different - in such
+case, deletions are computed using old rules.
 dit(bf(--delete-after)) Request that the file-deletions on the receiving
 side be done after the transfer has completed.  This is useful if you
 are sending new per-directory merge files as a part of the transfer and

More information about the rsync mailing list