Exercise 3: Confirming write_page() Never Calls os.fsync() — Possible Solution
====================================================================

THE INSPECTION
------------------------------
Course 1's own HeapFile.write_page() method, unchanged since
Chapter 4:

    def write_page(self, page_num, page):
        self.file.seek(page_num * PAGE_SIZE)
        self.file.write(bytes(page.data))
        self.file.flush()

Reading it line by line: seek() moves the file position, write()
hands the page's bytes to Python's own file object, and flush()
pushes Python's internal buffer out. There is no third call to
os.fsync(self.file.fileno()) anywhere in this method, anywhere else
in HeapFile, or anywhere else in the entire Course 1 codebase --
confirmed directly by inspection, not by running anything, since
this is a claim about what the code DOESN'T contain.

WHAT os.fsync() ACTUALLY DOES
------------------------------
Per Python's own documentation, os.fsync(fd) "forces write of file
[fd] to disk." The key word is disk: fsync() is a request to the
operating system to make sure every byte the OS is currently
holding for that file -- in its own page cache, in memory --
actually gets pushed out to the real, physical storage device
before the call returns.

WHY flush() ALONE DOESN'T GUARANTEE DURABILITY
------------------------------
There are genuinely two separate buffers sitting between a Python
program and a physical disk, not one:

1. Python's own internal buffer, inside the file object itself.
   flush() empties THIS one -- it hands whatever Python was holding
   onto the operating system.
2. The operating system's own page cache. Once the OS receives data
   from flush(), it is free to hold that data in memory for a while
   before actually committing it to the physical disk -- this is a
   deliberate performance optimization real operating systems make,
   since writing to physical disk is slow and batching writes
   together is much faster than committing every single one
   immediately.

flush() only guarantees data has crossed from buffer 1 into buffer
2. It says nothing at all about buffer 2's own state. If the
machine loses power, the kernel panics, or the process is killed at
the OS level (not just the Python level) at any point between
flush() returning and the OS actually deciding to commit that data
to physical disk, everything sitting in the OS's own page cache is
gone -- even though Python's own write_page() already returned
successfully, with no error raised anywhere, giving every appearance
that the write fully succeeded.

os.fsync() is the only one of the two calls that actually blocks
until buffer 2 is empty too -- until the OS confirms the data is on
the physical device, not just handed off to it.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains, precisely, why "the write succeeded with no error"
is not the same claim as "the write is durable" -- the exact
distinction Chapter 1's own closing note draws, and the exact gap
Chapter 2's write-ahead logging is built to close by calling
fsync() at the specific moments where a real durability guarantee
is actually required.