Persist the file, then persist the name that publishes it

A successful fsync on a regular file requests persistence of its modified contents and associated file metadata through the documented storage boundary. Linux's interface explicitly distinguishes this from making the containing directory entry durable: that requires synchronization of the directory. The distinction matters most when a file was created, removed, or renamed. A durable inode and payload that cannot be reached by the expected post-crash name may fail the application's contract even though the bytes existed somewhere in the filesystem's recovery state.

Language-level flush normally drains a user-space buffer to the operating system; it does not replace fsync. The related fdatasync interface can omit metadata changes unnecessary for correct later data retrieval, but required size changes still matter. Check every write's byte count and every synchronization result. If persistence fails, the publisher must not report durable success just because earlier writes returned. An error can leave an uncertain mixture of progressed operations, so the recovery design should inspect generation identities and verified contents instead of assuming an error means nothing happened.

Assume a trusted, already durable parent directory on one supported local filesystem, a single coordinated publisher, and storage that honors the required persistence operations. Create a uniquely named temporary file in that same directory without accidentally opening an existing object. Write the full generation, set required attributes at the appropriate point, and fsync the temporary file successfully. Rename it over the public name, then fsync the parent directory successfully before acknowledging durable publication. The same-directory assumption keeps the naming update inside one directory and avoids cross-filesystem rename semantics.

Same-filesystem rename can provide atomic replacement of the destination name for concurrent lookups, but already open descriptors can continue reading the old inode. It does not atomically switch a reader's independently opened collection of several files. For a multi-file checkpoint, immutable generation directories or files plus a verified manifest can reduce the public switch to one reference, but the contents, hierarchy, and publication protocol still need their own persistence ordering. Cross-directory moves require reasoning about both changed directories, and network filesystems or unsupported directory fsync require their documented contracts rather than copying this local example blindly.

A crash before acknowledgment may leave an old public generation, a new one, or temporary debris within the filesystem's allowed persistence behavior. Recovery should validate the public generation's manifest and digest, use documented committed-state rules, and clean temporary artifacts only after determining which files are still referenced. The protocol's durable acknowledgment is the strong boundary; an interrupted earlier call does not promise a particular result. If an error follows rename, do not casually roll back by deleting the public name, because the rename may already be visible and could have become durable.

The queue lab illustrates acknowledgment pressure rather than executing this protocol. Interpret equal-sized publication jobs arriving at λ and completing their entire required durable sequence at μ. Press Reset, set both arrival to four and durable service to two, predict growth from the initial four jobs, then Play or Step. Before any comparison, Reset again and re-enter both desired rates: edits retain elapsed time and recalculate from four, rather than changing a live accumulated queue. Reducing synchronization steps in the real protocol would change its semantics. The animation has no files, directory descriptors, or syscall errors; test the ordered publication steps separately on disposable storage.