To elaborate a little bit more, you can verify with a sample program that ReadFile with OVERLAPPED does in fact modify the HANDLE's file position. The documentation doesn't actually state one way or another. My original attempt at a patch didn't have the ReOpenFile, and we experienced regular read corruption. We scratched our heads over it for a bit, and then hypothesized that someone must be mixing read styles, which led to this ReOpenFile workaround, which incidentally also solved the corruption problems. We wrote a similar sample program to verify that when using ReOpenHandle, and changing the file pointer of the duplicated handle, that the file pointer of the original handle is not modified. We did not actually try to identify the source of the mixed read styles, but it seems like the only possible explanation. On Thu, Feb 13, 2014 at 2:53 PM, Stefan Zager <szager@xxxxxxxxxx> wrote: > On Thu, Feb 13, 2014 at 2:51 PM, Karsten Blees <karsten.blees@xxxxxxxxx> wrote: >> Am 13.02.2014 19:38, schrieb Zachary Turner: >> >>> The only reason ReOpenFile is necessary at >>> all is because some code somewhere is mixing read-styles against the same >>> fd. >>> >> >> I don't understand...ReadFile with OVERLAPPED parameter doesn't modify the HANDLE's file position, so you should be able to mix read()/pread() however you like (as long as read() is only called from one thread). > > That is, apparently, a bald-faced lie in the ReadFile API doc. First > implementation didn't use ReOpenFile, and it crashed all over the > place. ReOpenFile fixed it. > > Stefan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html