Syncing moved files

Matt McCutchen hashproduct+rsync at
Sat Sep 23 01:18:29 GMT 2006

On 9/22/06, Wayne Davison <wayned at> wrote:
> On Fri, Sep 22, 2006 at 07:17:02PM -0400, Matt McCutchen wrote:
> > I suppose you want the receiver to skip the transfer entirely and just
> > move the file if --checksum is on and the checksums match.
> That doesn't really save you time (over leaving --checksum off) since
> you have to read the entire file (and every file too!) to compute the
> checksums.

True, but the user might need --checksum for a reason other than
performance (e.g. not hitting destination mtimes of files whose source
mtime changed but whose data didn't), and rsync should make the best
of that situation.

> > --fuzzy and --detect-renamed are very similar; they just consider
> > different sets of potential basis files.  Perhaps their
> > implementations should be merged.
> While they have a little overlap in functionality (since fuzzy can find
> a renamed file in the same dir), the main purpose of --fuzzy (as I see
> it, at least) is an attempt to use an older version of a file to speed
> up the transfer of a newer version.  For instance, if someone uses the
> --rsyncable gzip on their tar files in a release dir, when they release
> a new version of a source tar, --fuzzy would try to use the previous
> version (in the same dir) as a source of matching data for the new
> version.  This name matching is the slowest part of the current
> algorithm (for large directories), and is the main reason why the two
> algorithms should probably not be merged.

I'm not proposing that fuzzy name matching be done on deleted files; I
know what you think about /that/!  What I was getting at is that
--detect-renamed only considers files that pass the quick check with
the source file and --fuzzy takes such files immediately in preference
to name matching.


More information about the rsync mailing list