kio_sftp: Use proper boundary when queueing requests.
This fixes an off-by-one error when deciding whether the sftp_get code path needs to make another request or not. This appears to be involved in a data corruption bug (bug 312320) where file sizes that are a multiple of the request buffer size (60*1024) end up getting an extra full buffer of gibberish appended. E.g. a 61440-size file gets downloaded to a 122880-sized file. The bug report and proposed fix were both provided by Peter Klotz. I do not yet understand at this point why this off-by-one error would cause the extra packet to be appended, but I can confirm that the fix works. It's at least easy enough to prove that a valid offset will not be == to the file size (compare with the test on line 1151, for instance), and I can confirm the fix seems to work. It still doesn't make sense to me that the bug would be here though; reading from an sftp channel that's already at EOF just returns 0 bytes, and our code appears to handle that condition properly. In fact, the check that is being corrected happens only *after* unconditionally queueing up a first request packet, so you'd think the second EOF response wouldn't even be an issue. Yet here we are. BUG:312320 FIXED-IN:4.10
parent
c0363703
Please register or sign in to comment