non-recursive remote listing breakage in 3.0.0pre1
hashproduct+rsync at gmail.com
Sun Oct 7 17:16:09 GMT 2007
On 10/7/07, Wayne Davison <wayned at samba.org> 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