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

Hello

I've noticed today, that --delete-delay introduced in 3.0.2 is not
functionally equivalent of --delete-after (I was under impression it
should work this way).

Looking at following example:

/src
/src/testfile
/src/.rf

/dst
/dst/testfile

..rf consists of following lines:

S, .rf
H, *
P, testfile

rsync -aHx --delete-after --filter="dir-merge, .rf" /src/ /dst/

....will execute properly - which means that already existing testfile in
/dst will not be removed.

But if I execute:

rsync -aHx --delete-delay --filter="dir-merge, .rf" /src/ /dst/

....testfile will be removed, unless .rf (with above rules) already
exists on the receiving side.

Is this how it should be ? I was under impression, that --delete-delay
gave functionality of --delete-after, when the chosen algorithm was that
of --delete-during.

Cheers
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: [url]https://lists.samba.org/mailman/listinfo/rsync[/url]
Before posting, read: [url]http://www.catb.org/~esr/faqs/smart-questions.html[/url]

On Tue, Jun 10, 2008 at 04:41:42PM +0200, Michal Soltys wrote:[color=blue]
> rsync -aHx --delete-delay --filter="dir-merge, .rf" /src/ /dst/
> ...testfile will be removed, unless .rf (with above rules) already exists
> on the receiving side.[/color]

Yeah, that is how it currently works. The --delete-delay option delays
the deletions that are found as each directory begins its processing, so
it is like using --delete-during with the removals being delayed to the
end. I have considered make it do the delete scan at the end of each
dir's processing, but when I last looked at it there was a reason why I
didn't do that (which had to do with complications of getting the
per-dir rules set right for both the on-going copying, and a late delete
scan). I don't think this is likely to change any time soon, but it
would be nice to have a way of doing something like early per-dir filter
copying or something.

...wayne..
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: [url]https://lists.samba.org/mailman/listinfo/rsync[/url]
Before posting, read: [url]http://www.catb.org/~esr/faqs/smart-questions.html[/url]

Wayne Davison wrote:[color=blue]
> per-dir rules set right for both the on-going copying, and a late delete
> scan). I don't think this is likely to change any time soon, but it
> would be nice to have a way of doing something like early per-dir filter
> copying or something.
>
> ..wayne..
>[/color]

Oki, thanks for clarification.

Still, in that case - what's the benefit of using --delete-delay option ?
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: [url]https://lists.samba.org/mailman/listinfo/rsync[/url]
Before posting, read: [url]http://www.catb.org/~esr/faqs/smart-questions.html[/url]

On Tue, Jun 10, 2008 at 09:58:34PM +0200, Michal Soltys wrote:[color=blue]
> Still, in that case - what's the benefit of using --delete-delay option ?[/color]

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, its works the same as
--delete-after (if we disregard certain backup-file cases where the
suffix is not excluded), just more optimally.

...wayne..
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: [url]https://lists.samba.org/mailman/listinfo/rsync[/url]
Before posting, read: [url]http://www.catb.org/~esr/faqs/smart-questions.html[/url]

Wayne Davison wrote:[color=blue]
> On Tue, Jun 10, 2008 at 09:58:34PM +0200, Michal Soltys wrote:
>
> have per-dir filter files being updated, its works the same as
> --delete-after (if we disregard certain backup-file cases where the
> suffix is not excluded), just more optimally.
>[/color]

You mean - the difference will be in the moment where the non-excluded
files get deleted ? As long as per-driectory filters are the same on
sender and receiver, the final outcome will still be the same regardless
of a delete algorithm used ?

Anyway - would it be allright to submit a small manpage diff, to add
some details about difference between delete-delay and delete-after ?

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

On Sun, Jun 15, 2008 at 09:36:30AM +0200, Michal Soltys wrote:[color=blue]
> would it be allright to submit a small manpage diff, to add some
> details about difference between delete-delay and delete-after ?[/color]

Diffs are always welcomed. Please feel free.

...wayne..
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: [url]https://lists.samba.org/mailman/listinfo/rsync[/url]
Before posting, read: [url]http://www.catb.org/~esr/faqs/smart-questions.html[/url]

Wayne Davison wrote:[color=blue]
>
> Diffs are always welcomed. Please feel free.
>
> ..wayne..
>[/color]

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.


--- rsync.yo.org 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

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