non-recursive remote listing breakage in 3.0.0pre1
hashproduct+rsync at gmail.com
Sat Oct 6 21:50:41 GMT 2007
On 10/6/07, Erik Jan Tromp <betageek at sympatico.ca> wrote:
> It would appear something snuck in that breaks non-recursive remote
> listings when talking to a non-3.0.0pre1 version of rsync. The symptom
> itself is simple enough to see; rather than displaying member
> directories/regular files/symlinks/etc as one would expect, only
> non-directories (with the exception of '.') are listed.
I can reproduce this. Pulling from an older version of rsync with
--dirs is similarly broken:
$ mkdir src src/D dest
$ rsync-2.6.9 --rsync-path=rsync-2.6.9 -ni --dirs localhost:`pwd`/src/ dest/
$ rsync --rsync-path=rsync-2.6.9 -ni --dirs localhost:`pwd`/src/ dest/
The underlying problem is that FLAG_XFER_DIR is being used
inconsistently to mean two different things: "I'm not an implied dir"
and "delete in me". recv_file_entry is using the "delete in me"
meaning, and D shouldn't be deleted in because its contents were not
sent, so recv_file_entry doesn't set FLAG_XFER_DIR on D.
recv_generator wants to skip implied dirs unless unless --relative is
given without --no-implied-dirs, so it sees that D lacks FLAG_XFER_DIR
and skips it.
There's a flip side to this. An rsync 3.0.0 sender *does* set
FLAG_XFER_DIR on dirs like D, so if deletion is enabled, the generator
incorrectly deletes all their contents!
More information about the rsync