"intelligent" rsync scripts?

[Chris Shoemaker]

On Thu, Nov 10, 2005 at 11:30:49AM -0800, Wayne Davison wrote:
> On Thu, Nov 10, 2005 at 10:32:50AM -0500, Chris Shoemaker wrote:
> > If the original file changes, then so will the hard link.
> 
> No -- an rsync update creates a temporary file, and that file gets
> renamed into place, breaking any hard-link that this new code creates.
> (The only exception to this update method is when --inplace is enabled,
> and I made this conflict with the new --detect-rename option.)

Ah, ok.  Perfect.

> > If --detect-renames hardlinks the deleted files it doesn't matter that
> > the orginals are deleted before transfer; hard drive space is not
> > reduced.
> 
> True, but only for correlated files.  Any extraneous files will still be
> deleted before the transfer.  This shouldn't be any worse in disk-space
> use than the alternative of not allowing a delete-before pass.

I see now.  That's a good reason to allow --delete-before.

> > Oh, because the match-search for non-missing files is not delayed in
> > the --delete-during scan, right?
> 
> Exactly.  My text might not have made it clear that this non-missing
> handling will always work for files in a single directory (such as
> log-dir rotations) as well as files found in the already-scanned dirs
> prior to getting to the current directory.

That's what I understood, and it's the only thing thing that doesn't
feel quite right.  Right now, I see the rename-with-replace detection
as gravy, since I only envisioned straight rename-with-no-replace at
first.  But, users are greedy, and they may come to depend on
rename-with-replace.  It's a little hard to explain that it will only
work if the new filepath is lexicographically earlier than the
old filepath.  Also, see below.

> > So, will this be in 2.6.7?
> 
> It has a good chance of making it.  It still needs some cleanup and
> testing, some of which I've just done:  e.g. I've added support for
> checksum matching (instead of mod-time matching) when --checksum is
> enabled.  The aforementioned patch has been updated with the latest
> changes.

--checksum support is good, but I think it raises the user's
expectations even higher about how rsync will perform.  It's even
*harder* to explain that even with the (more expensive) file
checksums, rsync won't use the correct basis for the
rename-with-replace case 50% of the time, on average.

Is it possible to delay the basis search even for non-missing files if
they're not exact matches?

-chris