Bug 5645 - Optimization-only basis dirs that don't affect itemization
Summary: Optimization-only basis dirs that don't affect itemization
Status: NEW
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.0
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
Depends on:
Reported: 2008-07-29 14:07 UTC by Matt McCutchen
Modified: 2009-01-26 13:50 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Matt McCutchen 2008-07-29 14:07:29 UTC
Currently, when rsync uses a basis file from a --*-dest basis dir, rsync itemizes as if the basis file were actually present in the destination.  However, a --copy-dest or --link-dest dir (but not a --compare-dest dir) may be intended purely as an optimization that does not affect the resulting contents of the destination (ignoring hard links).  I would like a means to specify such a basis dir without affecting itemization except to change some "<" or ">" in the first column to "c" or "h".

This means could take the form of a separate flag --no-itemize-alt-basis or, for more flexibility, non-itemizing variants of --copy-dest and --link-dest.  These variants could be named --basis-dir and --link-basis-dir to suggest that they lack the semantic association with the destination that the --*-dest options have.
Comment 1 Matt McCutchen 2008-07-29 14:09:51 UTC
I previously requested this enhancement at:

Wayne on why the --*-dest options affect itemization but --fuzzy doesn't:
Comment 2 Matt McCutchen 2008-10-04 15:45:45 UTC
To clarify, I propose splitting --copy-dest=DIR and --link-dest=DIR into two variants, one that means purely "use DIR as an optimization" and another that means purely "regard DIR as the previous version of the destination".  The first variant could be named --{,link-}basis-dir and the second could keep the name --{copy,link}-dest, or the second could adopt a new name for backward compatibility.

The first variant would have no effect on rsync's itemization (except to change "<" or ">" to "c" or "h" when appropriate) or on the resulting destination contents (except for hard links outside the destination).

The second variant would give essentially the same result as copying DIR to the destination with "cp -a" ("-l" in the case of --link-dest) and then running rsync, except that --link-dest would avoid tweaking attributes in DIR regardless of --no-tweak-hlinked (see bug 4561).  In particular, it would itemize deletions with respect to DIR when --delete is on (as in bug 5263) and would copy/hard-link extraneous files from DIR to the destination when --delete is off.  The proposal of this last bit of behavior on the list inspired me to make this clarification: