non-recursive remote listing breakage in 3.0.0pre1

Matt McCutchen hashproduct+rsync at
Sun Oct 7 17:16:09 GMT 2007

On 10/7/07, Wayne Davison <wayned at> wrote:
> Actually, you were right.  Turned out I just needed to limit the check
> to when inc_recurse was active, as that is the only time that the
> --no-implied-dirs code needs to include implied directories in the
> recursion sequence, and thus the only time they need to be ignored (the
> inc_recurse mode can't have non-implied dirs w/o FLAG_XFER_DIR, since
> we know that --recursive is active).

I see.  So FLAG_XFER_DIR does mean that a directory's contents are
being transferred.  When inc_recurse is off, implied dirs aren't in
the file list; when inc_recurse is on, recurse is on, so the only dirs
in the file list whose contents aren't being transferred are implied
dirs.  Thus, a dir is implied if and only if it lacks FLAG_XFER_DIR
*and* inc_recurse is off.

That is ridiculously clever.  I suppose it works for now, but it will
break if incremental file-list building is extended to non-recursive
scenarios (e.g., --files-from); I would feel better if rsync used two
separate flags FLAG_XFER_DIR and FLAG_IMPLIED_DIR.  If you don't want
to do that, you could still make it clearer how the single flag works
by introducing a macro F_IMPLIED_DIR:

#define F_IMPLIED_DIR(f) (inc_recurse && !((f)->flags & FLAG_XFER_DIR))

> The latest CVS code has fixes for the incomplete listing bug(s), the
> case where too many dirs were getting marked with FLAG_XFER_DIR when
> --recursive wasn't set (which could cause the dir's contents to be
> deleted erroneously), and for the incomplete detecting of certain dot
> dirs when --relative was set (as noted in your last report).

I verified that everything is fixed.


More information about the rsync mailing list