From a18008b9ab1dfe45b92165485cfb8c99f2fa5c4a Mon Sep 17 00:00:00 2001 From: Thomas Munro Date: Wed, 4 Dec 2019 15:20:27 +1300 Subject: [PATCH] Document the EOF behaviour for synchronous handles with an OVERLAPPED struct The documentation doesn't seem to cover the EOF behaviour when a synchronous file handle is accessed with an OVERLAPPED struct. That is a useful thing to do, in order to provide an offset, to simulate the POSIX function pread() (ie to avoid having a separate lseek() syscall). See also Raymond Chen's blog[1]. [1] https://devblogs.microsoft.com/oldnewthing/20150121-00/?p=44863 --- sdk-api-src/content/fileapi/nf-fileapi-readfile.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/sdk-api-src/content/fileapi/nf-fileapi-readfile.md b/sdk-api-src/content/fileapi/nf-fileapi-readfile.md index e8699192cdbb..a909b5a4a4e9 100644 --- a/sdk-api-src/content/fileapi/nf-fileapi-readfile.md +++ b/sdk-api-src/content/fileapi/nf-fileapi-readfile.md @@ -302,9 +302,13 @@ Considerations for working with synchronous file handles: ReadFile does not return until the read operation is complete. The system updates the OVERLAPPED offset before ReadFile returns. -
  • When a synchronous read operation reaches the end of a file, +
  • If lpOverlapped is NULL, then when a synchronous read operation reaches the end of a file, ReadFile returns TRUE and sets *lpNumberOfBytesRead to zero.
    • +
  • If lpOverlapped is not NULL, then when a synchronous read operation reaches the end of a file, + ReadFile returns FALSE and + GetLastError returns + ERROR_HANDLE_EOF.
    • For more information, see CreateFile and Synchronous and Asynchronous I/O.