Buffers and flushing

Where did my write go?

Here is a spooky and extremely common surprise: you write() to a file, and the data is not in the file yet.

Why? Asking the OS to move bytes to disk is expensive (unit 6 taught you that giving up the CPU and waiting on hardware costs real time). So Python does not send every little write() to the OS. It collects your writes in a buffer, a chunk of memory inside your process, and hands the whole batch over later: when the buffer fills, when you call flush(), or when the file is closed.

Batching turns thousands of tiny expensive trips into a few big ones. The price is a window of time where your program thinks it wrote, but the file has not changed.

When this bites in real life

• Crashes lose buffered data. If a program dies before flushing, the buffered writes never reach the file. This is why log lines sometimes vanish right before a crash, exactly the lines you needed.
• Another process reads too early. Program A writes a status file, program B reads it and sees nothing, like our demo.
• with open(...) is the fix for most cases: closing a file flushes it, and the with block guarantees the close even on exceptions. That is the habit you have been using all course.

One level deeper: flush() hands bytes to the OS, which keeps its own cache before the physical disk. Databases that absolutely cannot lose data call an extra OS-level force (os.fsync) at the cost of real slowness. Layers of buffers, all the way down.