Renaming of a file is an atomic operation, and this is one guarantee that makes so many database implementations simpler. Here’s one practical example, let’s dig deeper…
When we perform a write to a database, we can’t just overwrite a file directly when updating data. If the power goes out mid-write, we would have a corrupted file with half-old, half-new data mixed. That’s a nightmare.
So most databases use a smart two-file strategy to stay safe. Here’s how…
When new data needs to be written, it goes into a temporary file first. This could be a write-ahead log entry or a new database page snapshot. The old file stays untouched, containing our last known good state.
Once the new data is completely written to the temp file, the system calls fsync() to guarantee it’s actually on disk (not just sitting in a buffer somewhere). Then comes the atomic operation rename(temp -> real_file).
This rename operation is atomic at the filesystem level. It’s all-or-nothing. After a crash, we get exactly one of two states: either our old file is still there intact, or our new file has cleanly replaced it. We never end up with partial writes or corrupted data.
Without this atomic rename guarantee, things would get incredibly messy. We would need complex recovery protocols, versioning systems, checksums everywhere, and even then, we would have edge cases where data corruption slips through.
The reliability of most databases is on this one simple filesystem guarantee. Pretty elegant if you ask me :)