This bug was previously reported on the rsync mailing list, https://lists.samba.org/archive/rsync/2018-April/031626.html . This version of the report has a slightly more detailed repro, and was produced on Linux.

The bug manifests if an xattr filter rule is being used; however the repro does not require actual xattrs to be present, so the bug can be reproduced even if the file system being used does not support xattrs.

Prerequisites for the repros:
- ssh service running on localhost
- mkdir /tmp/{a,b}
- touch /tmp/a/1 /tmp/b/{1,2}


Repro #1, sender is local:
$ rsync --filter='-x! user.*' -avvvHX --delete /tmp/a/. localhost:/tmp/b
Result:
- output: [Receiver] add_rule(-! user.*)
- output: [generator] protecting file 2 because of pattern user.*
- output: [generator] protecting file 1 because of pattern user.*
- expected: /tmp/b/2 is deleted, actual: not deleted

Repro #2, sender is remote:
$ rsync --filter='-x! user.*' -avvvHX --delete localhost:/tmp/b/. /tmp/a
Result:
- output: [sender] add_rule(-! user.*)
- output: [sender] hiding file 2 because of pattern user.*
- output: [sender] hiding file 1 because of pattern user.*
- output: deleting 1
- expected: /tmp/a/1 is not deleted, actual: is deleted
- expected: /tmp/a/2 is created, actual: not created

The results are consistent with the theory that the xattr filter rule is mangled during transfer, resulting in an incorrect (-! user.*) filter rule on the remote side, that matches all remote files.

In the more general case, the bug causes rather destructive behavior: if the sender is remote (like in repro #2), all local files are deleted.


Enviroment: Arch Linux, Kernel 4.15.13, package https://www.archlinux.org/packages/extra/x86_64/rsync/

rsync  version 3.1.3  protocol version 31
Capabilities:
   64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
   socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
   append, ACLs, xattrs, iconv, symtimes, prealloc