Created attachment 6816 [details] Patch to fix invalid flist flag error when using different rsync clients XMIT_IO_ERROR_ENDLIST should only be used when protocol 30+ is used. When the remote rsync isn't capable of doing protocols 30+, other recent versions will use protocol 28 or protocol 29 by default. This will produce an "Invalid flist flag: 1004" error. This bug was introduced by commit 92e89a2. I have attached a patch against the git master that resolves the issue.
Sadly, the patch doesn't fix the issue, it hides the fact that illegal flags are being received. Can you figure out why the invalid flag bits are being sent by the older rsync?
Note also that the patch breaks the code so that it can never match that flag combination when it actually should.
Created attachment 6819 [details] Ignore some bogus file-list flags for older protocols Here's a kluge that will ignore this error for older protocols. I'd rather figure out what makes an older version send and invalid flag, but I may apply this for the 3.0.9 release if we can't figure out what's up. To be clear, the XMIT_IO_ERROR_ENDLIST flag (0x1000 aka (1<<12)) is a new flag for protocol 30, so no old version of rsync should ever send it. A more modern rsync will only use it either in combination with XMIT_EXTENDED_FLAGS (0x04) by itself (0x1004), or in combination with XMIT_HLINKED|XMIT_EXTENDED_FLAGS, where it is interpreted as as XMIT_HLINK_FIRST (but XMIT_HLINK_FIRST is only ever sent for protocol >= 30). Having looked at some older code versions (2.6.9, 2.6.3, and 3.0.0), I don't see any way that that 0x1000 bit could get set in send_file_entry() without (in 3.0.0) using protocol 30, so it makes me think that there might be a hacked rsync out there that is using incompatible XMIT_* bits.
No response; fix should handle it.