rsync - Apr 2018 - bug: xattr filter rule treated as file filter rule on the remote side

Summary: an xattr filter rule (e.g. --filter='-x! user.*’, which is
suggested by the documentation) is treated as a file filter rule on the remote
side.

Repro #1, sender is local:
host1$ rsync --filter=‘-x! user.*' -avvvHX --delete /tmp/test/. host2:test
...
[Receiver] add_rule(-! user.*)

Repro #2, sender is remote:
host1$ rsync --filter=‘-x! user.*' -avvvHX --delete host2:test/. /tmp/test
...
[sender] add_rule(-! user.*)

One possible and quite dangerous symptom of this is that the incorrect (-!
user.*) rule matches (almost) all remote files, therefore in repro #1, no remote
files are deleted, and in repro #2, nothing is transferred and all local files
are deleted.


Environment: macOS 10.13.4, homebrew,
https://github.com/Homebrew/homebrew-core/blob/master/Formula/rsync.rb
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, no prealloc, file-flags

On Sat 28 Apr 2018, Andras Nagy via rsync wrote:
> Summary: an xattr filter rule (e.g. --filter='-x! user.*’, which is
suggested by the documentation) is treated as a file filter rule on the remote
side.
I think that you're missing the point that filter rules affect the list
of files to be transferred. This implies that it always applies to the
*sending* side, as that is the side that builds the list to be sent.

It does not matter if the sending side is local or remote, so using that
in the description of the problem is wrong.


Paul

> On Apr 29, 2018, at 8:45 AM, Paul Slootman via rsync <rsync at
lists.samba.org> wrote:
> I think that you're missing the point that filter rules affect the list
> of files to be transferred. This implies that it always applies to the
> *sending* side, as that is the side that builds the list to be sent.
> 
> It does not matter if the sending side is local or remote, so using that
> in the description of the problem is wrong.
I understand from the docs (attached below) that by default, filter rules apply
to both sides.



An s is used to indicate that the rule applies to the  sending  side.
When  a  rule  affects the sending side, it prevents files from being
transferred.  The default is for a rule to affect both  sides  unless
--delete-excluded  was  specified, in which case default rules become
sender-side only.  See also the hide (H) and show  (S)  rules,  which
are an alternate way to specify sending-side includes/excludes.

An r is used to indicate that the rule applies to the receiving side.
When a rule affects the receiving side, it prevents files from  being
deleted.  See the s modifier for more info.  See also the protect (P)
and  risk  (R)  rules,  which  are  an  alternate  way   to   specify
receiver-side includes/excludes.

On Wed, May 16, 2018 at 10:03 AM Andras Nagy wrote:
> Summary: an xattr filter rule (e.g. --filter='-x! user.*?, which is
> suggested by the documentation) is treated as a file filter rule on the
> remote side.
>
This got fixed in git a long time ago, but I (sadly) haven't yet made a new
release that includes it. It will be in 3.2.0.

The issue was that the filter-sending code was not modified to include the
'x' qualifier when writing out these rules.

..wayne..
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20200613/99ff134f/attachment.htm>