Reading and writing are less symmetric than you (probably) think

Reading and writing appear to be mirror-image operations, but buffering makes their errors behave differently. A read must obtain data before returning it to the program: buffered libraries may request several kilobytes, and the kernel and storage layers fill their buffers before the requested bytes are delivered. If the file is too short or a device or network error occurs, the failure is generally reported during that read. A buffered write, by contrast, may simply copy data into a user-space buffer and report success without making any system call. The actual write - and any errors it encounters - may come later, when the buffer fills or is flushed, repositioned, or closed. Checking only the original write call therefore does not establish that the data was written.

Even a successful system call usually means only that data reached the kernel’s buffer cache, not permanent storage. Programs that need reliable writes must check errors from flushing and closing, and use fsync (or Windows’ FlushFileBuffers) to request that file data reach storage before closing. Errors can still arise late, especially with network filesystems; device or controller caches can also complicate durability. Furthermore, syncing a file may not persist the directory entry that makes it accessible: some systems require syncing the containing directory too. The practical lesson is that reads are comparatively transparent, while durable writes require explicit error checks and a clear understanding of what each layer’s success actually guarantees.