Is the overlapped structure updated when using ReadFile?
I am learning something on win32 programming. I read in the reference manual (here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365467%28v=vs.85%29.aspx ) that
If lpOverlapped is not NULL, the read operation starts at the offset specified in the OVERLAPPED structure, and ReadFile is not returned until the read operation is complete. The system updates the OVERLAPPED offset until ReadFile returns.
However, if I call ReadFile(hmyFile, &myrecord, sizeof(record_t), &n, &ov);
, I see that the value ov.offset
remains the same. How so? Where am I confused about what the reference manual says?
Read more:
File handler opens as hmyFile = CreateFile(argv[1], GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
I am not usingFILE_FLAG_OVERLAPPED
source to share
As pointed out in the comments, this is a bug in the documentation. The actual behavior is that the file pointer is updated as if lpOverlapped is NULL and the handle is synchronous. Older versions of the documentation get this right. The following is the 2000 version of the Platform SDK documentation:
The ReadFile function reads data from a file starting at the position indicated by the file pointer. Upon completion of the read operation, the file pointer is governed by the number of bytes actually read, unless the file descriptor is created with an overlapping attribute. [...]
If hFile does not open with FILE_FLAG_OVERLAPPED, and lpOverlapped is not NULL, the read operation starts at the offset specified in the OVERLAPPED structure . ReadFile is not returned until the read operation is complete.
source to share