This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(227.2, 71%, 32%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EN%3C/text%3E%3C/svg%3E)
Is it possible for WriteFile() to perform a partial write? Let's say we want to write 100 bytes to a file and only 50 bytes can be written (for example, the disk is full). Would WriteFile() return success and *lpNumberOfBytesWritten would be 50? Would WriteFile() return error and *lpNumberOfBytesWritten would be 50?
When using asynchronous I/O (opening the file with FILE_FLAG_OVERLAPPED and passing a pointer to an overlapped struct in WriteFile()): can the data be partially written to disk (for example, 50 bytes can be immediately written to the file but not the remainder 50 bytes)? would WriteFile() return success and *lpNumberOfBytesWritten would be 50? would WriteFile() return error (ERROR_IO_PENDING) and *lpNumberOfBytesWritten would be 50?
Thanks
Whether using synchronous or asynchronous I/O if a call to WriteFile is unable to write the number of bytes specified because the disk is full then the write fails, 0 bytes are reported as written, and the last error code is set to 112 (There is not enough space on the disk).
Thank you very much for your answer.
When using asynchronous I/O, are partial writes possible (for example, the driver is not fast enough)?
Asked another way, when WriteFile() returns TRUE, do I have to check the number of bytes written (*lpNumberOfBytesWritten) or is it not needed because *lpNumberOfBytesWritten == nNumberOfBytesToWrite? When WriteFile() returns FALSE, do I have to check the number of bytes written or is it always 0?
The documentation for WriteFile makes some points that you should note. For asynchronous operation the documentation of the lpNumberOfBytesWritten parameter states "Use NULL for this parameter if this is an asynchronous operation to avoid potentially erroneous results." Also, it says "The lpNumberOfBytesWritten parameter should be set to NULL. To get the number of bytes written, use the GetOverlappedResult function. If the hFile parameter is associated with an I/O completion port, you can also get the number of bytes written by calling the GetQueuedCompletionStatus function." When the lpNumberOfBytesWritten parameter is non-NULL for synchronous operations the documentation also points out that "WriteFile sets this value to zero before doing any work or error checking."
When WriteFile returns TRUE it means that the operation has succeeded. The documentation does not gurarantee that the number of bytes written will always be equal to the amount requested. However, in the context of a successful file I/O operation, in my experience this has been the case.
When WriteFile is used for asynchronous operations a return of FALSE indicates that GetLastError() should be called to determine if the I/O operation is pending or if an error has occurred.
I believe my earlier response has already addressed your questions about partial writes, and the reported number of bytes written when an I/O operation has failed.
I have also read that I should use NULL for lpNumberOfBytesWritten when performing asynchronous I/O operations.
My file is associated with an I/O completion port (CreateThreadpoolIo() / StartThreadpoolIo()). I am using SetFileCompletionNotificationModes() with the flag FILE_SKIP_COMPLETION_PORT_ON_SUCCESS. If the operation can complete immediately, the completion callback doesn't have to be called, I just have to cancel the I/O operation (CancelThreadpoolIo()) right afterwards.
In your first response you said what happened when the disk is full, that's why I wanted to know if this behavior "either everything can be written at once or nothing" is always expected.
"All or nothing" is what I would expect for file I/O. As a test I had one process open a file with shared access and lock 256 bytes in the file beginning at byte offset 256. Then I had a second process try to write 512 bytes to the file from the beginning of the file (i.e., offset 0). For both synchronous and asynchronous I/O WriteFile failed and 0 was reported as written to the file.
Thank you very much for your answer. That's exactly what I wanted to know.
However, the usefulness of lpNumberOfBytesWritten for disks seems still perpetually unclear.
You can say that again!
This is what was confusing me. The manual WriteFile says:
The WriteFile function returns when one of the following conditions occur:
So I thought that, when WriteFile() returns TRUE, checking whether *lpNumberOfBytesWritten == nNumberOfBytesToWrite shouldn't be really needed, but I was not 100% sure, so I still had WriteFile() inside a while loop, just in case *lpNumberOfBytesWritten < nNumberOfBytesToWrite.
Thank you again to both of you!
The WriteFile documentation indicates that the HANDLE used with WriteFile can be for "...a file, file stream, physical disk, volume, console buffer, tape drive, socket, communications resource, mailslot, or pipe". It's no wonder that one size fits all documentation can be ambiguous and confusing.
You are right, WriteFile has a really broad use.