rsync 3.2.7 client fails "rejecting unrequested file-list name" talking to rsync 3.2.7 (and ealier) server. about rsync

[carenas]

This is driven by python, and the file list sent to stdin is from (python) '\0'.join(file_list)

assuming this line comes from vbr.py, wouldn't the generated list of files to transfer be incomplete and missing the trailing NUL?, does using '\0'.join(file_list)+'\0' instead make a difference?

[JoshLitt]

@carenas I will try adding a trailing null. Looking at the file I used for the test I mentioned of putting that file list in a null-separated file and running command, I see that actually did have a trailing null (can't recall, but I think I generated it with sed replacing newlines with null, and it had a trailing newline.)

[JoshLitt]

Well, that was it. But whether or not it fails as it did may have to do with internal buffer mgmt boundaries. If I put the above file list in a null-separated list with a terminating null, it works. Without the terminating null, it fails. Changing the vbr.py script as you suggested ensures it too works. Yet if I use a list of 2 filenames, it works regardless of the terminating null.
I checked the rsync code to see where this sensitivity might be, and it wasn't obvious.

However, now that I understand this is often used in combination with find ... -print0, it makes sense to have a trailing null. The null isn't a field delimiter as much as terminator, though the man page uses both words for this in different places. That said, one could also expect that this case (no final NULL) should work. For example, xargs -0 seems to have no issue with this.