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

This is a discussion on delete-delay vs. delete-after in 3.0.2 (and possible bug) - Tools ; 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 ...

+ Reply to Thread
Results 1 to 7 of 7

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

  1. 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: https://lists.samba.org/mailman/listinfo/rsync
    Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


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

    On Tue, Jun 10, 2008 at 04:41:42PM +0200, Michal Soltys wrote:
    > 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.


    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: https://lists.samba.org/mailman/listinfo/rsync
    Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


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

    Wayne Davison wrote:
    > 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..
    >


    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: https://lists.samba.org/mailman/listinfo/rsync
    Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


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

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


    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: https://lists.samba.org/mailman/listinfo/rsync
    Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


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

    Wayne Davison wrote:
    > 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.
    >


    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: https://lists.samba.org/mailman/listinfo/rsync
    Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


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

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


    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: https://lists.samba.org/mailman/listinfo/rsync
    Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


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

    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.


    --- 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: https://lists.samba.org/mailman/listinfo/rsync
    Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

+ Reply to Thread