<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Crash Consistency on Nalar</title>
    <link>https://nalar.dev/tags/crash-consistency/</link>
    <description>Recent content in Crash Consistency on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 15 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/crash-consistency/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Atomic Rename Separates Visibility From Crash Durability</title>
      <link>https://nalar.dev/atomic-rename-separates-visibility-from-crash-durability/</link>
      <pubDate>Tue, 15 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/atomic-rename-separates-visibility-from-crash-durability/</guid>
      <description>&lt;p&gt;A successful &lt;code&gt;rename()&lt;/code&gt; can replace an existing pathname without exposing an interval in which that destination name is absent. That visibility property makes rename a common publication boundary for configuration files, checkpoints, manifests, and other file-backed state. It does not, by itself, establish that the replacement survives an abrupt loss of power.&lt;/p&gt;&#xA;&lt;p&gt;The distinction is between namespace atomicity and persistence. Atomic replacement constrains what concurrent observers can see while the system is running. Crash durability concerns which writes and metadata changes are guaranteed to remain after volatile state disappears. Treating those properties as equivalent creates a gap precisely at the failure boundary that atomic replacement is often intended to protect.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
