The question

What can go wrong when a threaded cache writes a response directly to its final filename?

Working model

The final name becomes visible as soon as the writer opens it. A second request can mistake “a writer has started” for “the object is complete” and return the partial bytes as a successful cache hit.

Write to a unique temporary file in the destination directory, validate the whole object, close the writer, and atomically replace the final path. Remove the temporary file on every failure. Same-directory publication keeps the rename on one filesystem.

Atomic publication solves visibility, not every race. Two misses may still download twice, and integrity checks such as expected length remain separate.

Provenance

Synthesized from Linux Fieldwork's mmdebstrap cache-proxy investigation at revision c79d34b65fb2cd8c54234f361f073248c53b513a.

Sketch a two-request timeline. Request A creates the final path and pauses after one chunk. Request B arrives.

Then replace the direct write with temporary → validate → close → atomic rename. Which states can B observe before and after the change? What extra mechanism would you need to prevent duplicate downloads, and why is that a different requirement?