Bug 8411 - invalid flist flag when using protocol 28 or 29
invalid flist flag when using protocol 28 or 29
Status: RESOLVED FIXED
Product: rsync
Classification: Unclassified
Component: core
3.0.7
All All
: P5 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-27 01:20 UTC by unobe
Modified: 2013-06-02 22:22 UTC (History)
0 users

See Also:


Attachments
Patch to fix invalid flist flag error when using different rsync clients (519 bytes, patch)
2011-08-27 01:20 UTC, unobe
no flags Details
Ignore some bogus file-list flags for older protocols (441 bytes, patch)
2011-08-27 21:47 UTC, Wayne Davison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description unobe 2011-08-27 01:20:24 UTC
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.
Comment 1 Wayne Davison 2011-08-27 19:14:03 UTC
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?
Comment 2 Wayne Davison 2011-08-27 19:31:06 UTC
Note also that the patch breaks the code so that it can never match that flag combination when it actually should.
Comment 3 Wayne Davison 2011-08-27 21:47:24 UTC
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.
Comment 4 Wayne Davison 2013-06-02 22:22:25 UTC
No response; fix should handle it.