On 03/25/2009 05:17 PM, Stefan Fritsch wrote: > I don't deny this and it is certainly not optimal, but it works as > documented. I have poked upstream about it but I don't expect that it > changes in the near future. OK, fair enough. Is there anything in an upstream bugtracker? Should we link these up? Perhaps one of these upstream bugs is relevant: https://issues.apache.org/bugzilla/show_bug.cgi?id=45986 https://issues.apache.org/bugzilla/show_bug.cgi?id=45292 > Apache needs to be portable. Maybe sendfile's error reporting does not > work reliable on other plattforms. hrm, yeah, this is certainly possible. And hard to work around :( > dkg wrote: >> Interestingly, when i tried experimenting with this by doing sendfile >> from a CIFS-mounted file through a local UNIX-domain socket [0], >> sendfile(2) returned EOVERFLOW, but the entire file transferred cleanly, >> even for a ~5MB file. > > This would show that it is not so easy to determine where to continue > when something went wrong. Interestingly, EOVERFLOW is not a valid error > code for sendfile according to my version of sendfile(2) :-/ Well, in this case, nothing went wrong (since the whole file was transferred across the socket). When i get a chance, i'll try to modify my code to do this over a network socket instead of a UNIX socket, and listen to it from socat on another machine to see if i can get the whole file that way. It seems not unlikely that the different socket domains (AF_UNIX and AF_INET) would have different code paths in the kernel. --dkg
Attachment:
signature.asc
Description: OpenPGP digital signature