Repository navigation
inaccurate block size in socket._sendfile_use_sendfile #112341
Description
Bug report
Bug description:
socket._sendfile_use_sendfile(self, file, offset=0, count=None) intent to use the file size reamains from current position as block size, to a underlying sendfile syscall, when count is not specified.
But as the codes below shows, it will always use the whole file size as block size even if offset is non zero, so the blocksize is larger than actuall file bytes remains from offset:
Line 363 in 89ddea4
On modern platforms, if someone specified the count which is larger than the actual file size, sendfile will accept it, and only sending the remaining data and returns the bytes which have been sent.
So the bug (if it is a bug) have no effect for now, and it's so minor, but I think we should fix it however. And if we want using TransmitFile as a sendfile implenentation on Windows, the inaccurate block size will leads to an error, which is mentioned in #102898 (comment), and the fix will be a must have.
CPython versions tested on:
3.8, 3.9, 3.10, 3.11, 3.12, 3.13, CPython main branch
Operating systems tested on:
macOS
Activity
serhiy-storchaka commentedon Jan 15, 2024
I do not think that there is a bug.
Note that
os.sendfile()can send less than the specified amount of bytes. So it is used in loop unless it returns 0. Butblocksizeis not changed in the loop ifcountis false (which means "send to the end of the file"), so the second and the following calls ofsendfile()are with the amount of bytes that exceed the number of bytes that left. If there is an issue with this, it requires more complex solution. But I think that it works correctly.It seems that if
countis false,socket.sendfile()can send a file whose size is increased between calls ofos.sendfile(). It may be a feature.aisk commentedon Jan 15, 2024
I got the point, in the second iteration of the loop in
socket.sendfilewill also call theos.sendfilewith the blocksize at the position out the fsize.I don't know if the increase size between loop is a feature. But if we fix it by caculate the blocksize in every iteration, Since current platforms CPython support, their
sendfilesyscall accepts the larger blocksize, so treat it as a bug and introduce some complexity is pointless.Thanks for the review and point this out!