--delete-during acts like --delete-before

[Wayne Davison]

On Fri, Sep 10, 2010 at 11:29 AM, Craig Bell <Craig.Bell at standard.com>wrote:

> That's interesting!  I tried this, --del does indeed behave strictly
> "infix" when both paths are local.
>

No, there's no difference in how the deletions occur, but there is a
difference in how the output makes it to the screen between a pull (where
both the generator and the receiver output) and a push (where only the
sender outputs).  A local transfer is done as a push, thus the difference
you saw between that and a remote pull you had done.

That doesn't change how the deletions happen, though.  The generator goes
through its list of files, visiting each directory, and telling the sender
what files need to be transferred.  Before processing a directory for
transfers, it processes the directory for deletions.  What you are seeing is
just that the generator has time to delete files far ahead of a set of
new-file transfers (since it doesn't have any work to do for those transfers
other than sending a "send this file" message to the sender).

So, in the case where the sender is outputting all the messages to the user,
the generator's messages on what deletions have (already) happened get
serialized into the transfer flow since the sender has to finish all the
data-sending for the file requests before it can read the incoming messages
(and output them) about what deletions the generator performed.

This pipe-lining isn't something that will change because it would slow
things down to force the generator to stop and wait for the receiver to
finish a set of transfers before looking for more work to do.  Your
work-around to send each directory separately seems like the best way for
you to go given your strictures.  It wouldn't be hard to tweak the code to
make the incremental scan only send one directory at a time to the receiving
side, but that is not something that I am going to fiddle with.

..wayne..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20100918/49dd96ed/attachment.html>