rsync - Oct 2008 - --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

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

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

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