THE FOLD / RESPAWN / SECOND WIND / THE ATOMIC RENAME
THE ATOMIC RENAME
an atomic NAME - the file was never the thing protected
1 WHAT IT IS · WHAT IT DOES · FACT OR FICTION
Most filesystems give you exactly one atomic operation on a name:
LIT verified live, every crash point enumerated. Opening the target and overwriting it has 4 crash points and leaves a valid file at 2 of them — 50.0%. The moment after truncate is the worst: the new data has not arrived and the old data is already gone. Write-temp, fsync-temp, rename has 4 crash points and leaves a valid file at all 4 — 100.0%. The target is never partial, because it is never written.
rename. Everything else about saving a file safely is arranged around borrowing it.LIT verified live, every crash point enumerated. Opening the target and overwriting it has 4 crash points and leaves a valid file at 2 of them — 50.0%. The moment after truncate is the worst: the new data has not arrived and the old data is already gone. Write-temp, fsync-temp, rename has 4 crash points and leaves a valid file at all 4 — 100.0%. The target is never partial, because it is never written.
2 HOW IT WAS WEAVED · AI + HUMAN
This is the write-temp-and-rename dance every editor, package manager and config writer performs, and the reason
AVAN (AI) enumerated the states instead of describing the pattern, because the interesting number is not 100% — it is the 50%. The naive version is not merely riskier; it has a window where the old file is already destroyed and the new one does not exist, and that window is opened deliberately by a truncate the programmer wrote.
rename is specified as atomic in POSIX.AVAN (AI) enumerated the states instead of describing the pattern, because the interesting number is not 100% — it is the 50%. The naive version is not merely riskier; it has a window where the old file is already destroyed and the new one does not exist, and that window is opened deliberately by a truncate the programmer wrote.
3 ONE DIMENSION
Two ways to save, every crash point.
4 TWO DIMENSIONS · INTERACTIVE
Pull the plug at each step.
5 THREE DIMENSIONS + AVAN’S INVERSE
The green forward object: a name moved, not a file.
AVAN’s addition (the inverse-companion): the forward reading is that rename gives you atomic saves. The inverse is that it gives you an atomic NAME, and the file was never the thing being protected. The bytes are written non-atomically, exactly as before; what happens in one indivisible step is a directory entry changing which object it points at. Read backwards, the whole pattern works by never doing anything dangerous to the thing you care about — you build the replacement somewhere nobody is looking, and then move a label.
LIT opening the target and overwriting it has 4 crash points and leaves a valid file at 2 of them, 50.0%, with the worst being the moment after truncate when the new data has not arrived and the old data is already gone, while write-temp then fsync-temp then rename has 4 crash points and leaves a valid file at all 4, 100.0%, because the target is never partial - it is never written
FIG This is the write-temp-and-rename dance every editor, package manager and config writer performs, and the reason rename is specified as atomic in POSIX. AVAN enumerated the states instead of describing the pattern, because the interesting number is not the 100% - it is the 50%. The naive version has a window where the old file is already destroyed and the new one does not exist, opened deliberately by a truncate the programmer wrote.
FIG This is the write-temp-and-rename dance every editor, package manager and config writer performs, and the reason rename is specified as atomic in POSIX. AVAN enumerated the states instead of describing the pattern, because the interesting number is not the 100% - it is the 50%. The naive version has a window where the old file is already destroyed and the new one does not exist, opened deliberately by a truncate the programmer wrote.
◆ sealed .dlw.fold → folded to ROOT_0 · a sphere of SECOND WIND · David Lee Wise (ROOT0), with AVAN