# Testing crash recovery features in a CI environment

DevFeed: [Testing crash recovery features in a CI environment](<https://devfeed.tech/articles/testing-crash-recovery-features-in-a-ci-environment-27120.md>)

Original publisher: [Read original article](<https://andrea.corbellini.name/2025/09/09/testing-crash-recovery-features-in-ci/>)

Author: andreacorbellini

Published: 2025-09-09T00:05:00Z

Content type: article

Language: en

Sources: [Andrea Corbellini](<https://devfeed.tech/sources/andrea-corbellini.md>)

Topics: [Filesystems](<https://devfeed.tech/topics/filesystems.md>), [btrfs](<https://devfeed.tech/topics/btrfs.md>), [Linux](<https://devfeed.tech/topics/linux.md>), [Rust](<https://devfeed.tech/topics/rust.md>)

Tags: [atomic](<https://devfeed.tech/tags/atomic.md>), [btrfs](<https://devfeed.tech/tags/btrfs.md>), [filesystem](<https://devfeed.tech/tags/filesystem.md>), [information-technology](<https://devfeed.tech/tags/information-technology.md>), [linux](<https://devfeed.tech/tags/linux.md>), [rust](<https://devfeed.tech/tags/rust.md>)

## AI overview

A technical article describes atomic file updates in a Rust crate, using temporary files, synchronization, and atomic renaming to ensure a file contains either its old or new contents after a crash. It also discusses Linux anonymous temporary files and their limitations, including filesystem support and btrfs.

## Source excerpt

About two years ago I wrote a Rust crate to fulfill this promise: If a crash occurs while updating a file, the file either contains the old contents, or the new contents, nothing in between. This crate essentially solves the following problem: when you update a file, generally you open it, truncate it, write to it block-by-block, and eventually close it. The problem with ...