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 <> wrote:
> On Thu, Feb 13, 2014 at 2:51 PM, Karsten Blees <> 
> 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
More majordomo info at

Reply via email to