假設我有1Mb文件，文件指針位於文件的開頭。我稱之爲同步ReadFile：通過同步ReadFile讀取的字節數
ReadFile(Handle, Buffer, 1024, Result, nil);
該調用成功，沒有發生錯誤。 Result值（讀取的字節數）是否可能小於1024（要讀取的字節數）？
我認爲這是不可能的磁盤文件，我不確定其他資源可以通過ReadFile訪問。我應該在編寫可以使用不同資源的通用代碼時考慮上述情況嗎？
爲了避免哲學推測我可以重新配製的問題如下：
同步ReadFile的沒有錯誤被執行，並且字節數讀小於數目的閱讀。我可以確定已達到EOF嗎？
在你給定的場景中，對於磁盤文件來說，看起來似乎不可能接收到比請求的字節數少的字節數。
但是，編寫通用可以使用不同資源的代碼，在位置+字節數小於要傳輸的總字節數的情況下，您不應該總是接受所請求的字節數。
例如READFILE可以返回0字節的成功調用讀時調用WriteFile的0字節寫命名管道的另一端...
或套接字或其他網絡元素。 – 2010-07-27 14:22:36
同意。 ReadFile（）明確返回實際讀取的字節數。如果需要，檢查該值並再次調用ReadFile（）會更可靠，然後假定輸出計數總是與請求的計數相匹配。 – 2010-07-27 21:09:30
是否有任何對文檔的引用，指出當文件包含不少於最初請求的字節數時，ReadFile不會讀取文件的較小塊並返回該塊的大小？ – 2015-06-26 13:29:42
MSDN似乎是說只有以下w.r.t.當ReadFile的一個文件返回小於請求的字節數（即，不是一個套接字，管道等）：當一個同步讀取操作到達文件的結尾https://msdn.microsoft.com/en-us/library/windows/desktop/aa365467(v=vs.85).aspx
，ReadFile的返回TRUE和套* lpNumberOfBytesRead爲零。
我找不到任何證明或反對，即當文件包含不少於最初請求的字節數時，ReadFile不會讀取文件的較小塊並返回該塊的大小。因此，我正在編寫檢查ReadFile返回多少個字節的代碼，並且只要返回的字節總數小於請求的字節數，就再次調用ReadFile（在循環中），除非ReadFile返回0字節，這意味着EOF根據MSDN。
的實際含義：
如何保證文件大於緩衝區當你打電話給ReadFile的時候，你正在嘗試閱讀？這是一個理論問題嗎？因爲我無法在現實世界中保證它。我會寫我的代碼來說明它返回的時間少於1024，並且有適當的錯誤處理（EOF）。 – 2010-07-27 11:20:45
@LarsTruijens，實際上是一個文件（不是管道等）：1）調用GetFileSizeEx並分配一個由該函數報告的大小的緩衝區2）調用ReadFile請求一次讀取整個緩衝區3）程序員是否可以依賴ReadFile不會讀取報告讀取字節數的較小塊。 – 2015-06-26 13:26:21