<div dir="ltr"><div dir="ltr"><span class="gmail-im" style="color:rgb(80,0,80)"><div dir="ltr">On Thu, Sep 17, 2020 at 5:32 AM Matt McCutchen wrote:<br></div></span><div class="gmail_quote"><span class="gmail-im" style="color:rgb(80,0,80)"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">For the "not transfer" part, I can use --ignore-existing, but I don't see a direct way to be warned only about source files that differ from<br>existing destination files.<br></blockquote><div><br></div></span><div>Indeed, the 2-step approach that you mentioned is all that the released <span class="gmail-il">rsync</span> supports.  I've just checked-in a change that adds the `--info=skip2` option that will add a suffix to the "exists" message that indicates the existence-skipped file's status: "type change", or "sum change" (requires `-c`), "file change" (based on quick check), "attr change", or "uptodate".</div><span class="gmail-im" style="color:rgb(80,0,80)"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">My reading of the code also suggests that if the sender is malicious, --ignore-existing will not stop the receiver from processing a transfer of an existing destination file initiated by the sender</blockquote><div><br></div></span><div>Undoubtedly true, since the only thing the option does is limit what files the generator will request. At some point it will be good to double-check that the receiver doesn't get a file that the generator didn't request, but the current nature of the round-robin pipe through the sender makes that difficult without some new kind of direct generator-to-receiver flow of information.  I have an idea of how I'd like to improve <span class="gmail-il">rsync</span>'s receiver-side process setup in the future, but it's not easy to tweak in the current version. </div><font color="#888888"><div> </div><div>..wayne.. </div></font></div></div></div>