"intelligent" rsync scripts?
c.shoemaker at cox.net
Thu Nov 10 20:19:07 GMT 2005
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
--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?
More information about the rsync