--link-dest behavior - Tools

This is a discussion on --link-dest behavior - Tools ; Greetings All, I've been thinking about the current behavior of the --link-dest=DIR option. In the absence of --delete, ALL members of DIR should be linked to the destination (aside from those that are changed). If not, there should at least ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: --link-dest behavior

  1. --link-dest behavior

    Greetings All,

    I've been thinking about the current behavior of the --link-dest=DIR
    option. In the absence of --delete, ALL members of DIR should be linked
    to the destination (aside from those that are changed). If not, there
    should at least be a --no-link-dest-delete option. (This latter option
    might be better to avoid disrupting the behavior of current rsync commands)

    My rational: This would benefit a snapshot-style backup system, where
    the user wants to accumulate files without deleting them from the
    destination. With this behavior the user would not need to search
    through scores of snapshots to find a file that is no longer in the source.


    -Matt
    --
    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: --link-dest behavior

    On Fri, 2008-10-03 at 01:14 -0400, Matthew Monaco wrote:
    > I've been thinking about the current behavior of the --link-dest=DIR
    > option. In the absence of --delete, ALL members of DIR should be linked
    > to the destination (aside from those that are changed). If not, there
    > should at least be a --no-link-dest-delete option. (This latter option
    > might be better to avoid disrupting the behavior of current rsync commands)


    Interesting suggestion. Currently, the meaning of --link-dest=DIR is
    somewhere between "use DIR as an optimization" and "regard DIR as the
    previous version of the destination", and it is not ideally suited for
    either use case. I have proposed splitting it into --link-basis-dir and
    --link-dest variants for the two meanings:

    https://bugzilla.samba.org/show_bug.cgi?id=5645

    The new --link-dest would itemize deletions with respect to the basis
    dir when --delete is on, even though nothing is actually being deleted,
    as separately proposed here:

    https://bugzilla.samba.org/show_bug.cgi?id=5263

    And, now that you mention it, I guess the new --link-dest should also
    hard-link in files from the basis dir that have no counterpart in the
    source when --delete is off.

    A currently possible way to get the same result as my hypothetical new
    --link-dest is to "cp -al" the basis dir to the destination first and
    then rsync to the destination.

    Matt

    --
    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: --link-dest behavior

    In the event that --link-dest=DIR is the option taking on the new
    behavior (and thus is affected by --delete), I think that the lines
    given by --itemize-changes should not indicate the creation of "old"
    directories. (or there should be yet another option to suppress these.)

    In the meantime - is there a way to itemize only a particular type of
    change? For example: files only, no dirs, or files with permission
    updates only, etc?

    Matt

    PS

    The 'cp -al' method is what I'm currently doing as a workaround, but it
    adds a few extra lines to my script because I need to check if the
    destination connected to via ssh and then run the cp command over SSH
    (which is a different cp command than it normally would be because the
    ssh commands are relative to the users home directory...)



    Matt McCutchen wrote:
    > On Fri, 2008-10-03 at 01:14 -0400, Matthew Monaco wrote:
    >> I've been thinking about the current behavior of the --link-dest=DIR
    >> option. In the absence of --delete, ALL members of DIR should be linked
    >> to the destination (aside from those that are changed). If not, there
    >> should at least be a --no-link-dest-delete option. (This latter option
    >> might be better to avoid disrupting the behavior of current rsync commands)

    >
    > Interesting suggestion. Currently, the meaning of --link-dest=DIR is
    > somewhere between "use DIR as an optimization" and "regard DIR as the
    > previous version of the destination", and it is not ideally suited for
    > either use case. I have proposed splitting it into --link-basis-dir and
    > --link-dest variants for the two meanings:
    >
    > https://bugzilla.samba.org/show_bug.cgi?id=5645
    >
    > The new --link-dest would itemize deletions with respect to the basis
    > dir when --delete is on, even though nothing is actually being deleted,
    > as separately proposed here:
    >
    > https://bugzilla.samba.org/show_bug.cgi?id=5263
    >
    > And, now that you mention it, I guess the new --link-dest should also
    > hard-link in files from the basis dir that have no counterpart in the
    > source when --delete is off.
    >
    > A currently possible way to get the same result as my hypothetical new
    > --link-dest is to "cp -al" the basis dir to the destination first and
    > then rsync to the destination.
    >
    > Matt
    >
    >

    --
    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: --link-dest behavior

    On Sat, 2008-10-04 at 17:26 -0400, Matthew Monaco wrote:
    > In the event that --link-dest=DIR is the option taking on the new
    > behavior (and thus is affected by --delete), I think that the lines
    > given by --itemize-changes should not indicate the creation of "old"
    > directories.


    I agree.

    > In the meantime - is there a way to itemize only a particular type of
    > change? For example: files only, no dirs, or files with permission
    > updates only, etc?


    No, but you can run the itemize output through "grep" to select files
    with the desired type and/or changes.

    > The 'cp -al' method is what I'm currently doing as a workaround, but it
    > adds a few extra lines to my script because I need to check if the
    > destination connected to via ssh and then run the cp command over SSH
    > (which is a different cp command than it normally would be because the
    > ssh commands are relative to the users home directory...)


    Note (if you haven't already) that you can do the "cp" in the
    --rsync-path rather than in a separate ssh session.

    Matt

    --
    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: --link-dest behavior

    On Sat, 2008-10-04 at 18:41 -0400, Matthew Monaco wrote:
    > > Note (if you haven't already) that you can do the "cp" in the
    > > --rsync-path rather than in a separate ssh session.

    >
    > Thanks for the tip, Matt, but this does not appear to be working for me.
    >
    > I've tried rsyncing to various places with
    > --rsync-path="touch ME; rsync"
    > --rsync-path="touch ME && rsync"
    > --rsync-path="rsync; touch ME"
    > --rsync-path="rsync && touch ME"
    >
    > ME is never anywhere to be found.


    ME should be in the home directory of the account that you're ssh-ing
    into. It isn't?

    Matt

    --
    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. switch for hardlink behavior on destination


    Is there a way to control how rsync handles hardlinks on the destination?

    For example: I have two directories on a remote system which each have
    the same hardlink called TestFile.txt

    I use only one folder as the destination and TestFile.txt needs to be
    updated.

    Can I choose to preserve the hardlink or break it and create a new
    TestFile.txt in the destination?

    Matt
    --
    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: switch for hardlink behavior on destination

    On Sun, 2008-10-26 at 01:36 -0400, Matthew Monaco wrote:
    > Is there a way to control how rsync handles hardlinks on the destination?
    >
    > For example: I have two directories on a remote system which each have
    > the same hardlink called TestFile.txt
    >
    > I use only one folder as the destination and TestFile.txt needs to be
    > updated.
    >
    > Can I choose to preserve the hardlink or break it and create a new
    > TestFile.txt in the destination?


    The default behavior is to break the hard link if the file's data
    changed but leave it if only attributes changed. To always break the
    hard link, you would need to either copy to a new destination with
    --link-dest or use the --no-tweak-hlinked option implemented by my patch
    (see https://bugzilla.samba.org/show_bug.cgi?id=4561 ; unfortunately,
    not updated recently). To always leave the hard link intact, use
    --inplace.

    Matt

    --
    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