EVALUATION
The transferTo uses sendfile(2) where possible. The issue on Linux is that this only works with 32-bit offsets and we expect sendfile(2) to fail with -1/EINVAL when the offset isn't supported. It seems this changed in the 2.6 kernel so that -1/EOVERFLOW is returned when the offset is Integer.MAX_VALUE. Here's the output from strace when sendfile is exercised with offsets around Integer.MAX_VALUE:
:
[pid 29541] sendfile(6, 4, [2147483645], 1) = 1
[pid 29541] sendfile(6, 4, [2147483646], 1) = 1
[pid 29541] sendfile(6, 4, [2147483647], 1) = -1 EOVERFLOW (Value too large for defined data type)
[pid 29541] sendfile(6, 4, [2147483648], 1) = -1 EINVAL (Invalid argument)
[pid 29541] sendfile(6, 4, [2147483649], 1) = -1 EINVAL (Invalid argument)
[pid 29541] sendfile(6, 4, [2147483650], 1) = -1 EINVAL (Invalid argument)
:
The sendfile(2) man page does not document that EOVERFLOW is a possible error but in any case it looks like we now need to handle this error too.
|