Brck

I’ve just released Brck, a simple bit rot checker for legacy file systems. It records and compares the modification times and cryptographic hash sums of regular files. When a file’s hash changed but it’s modification time did not, then Brck reports the file as corrupted so you have a chance to restore the file from backup. You do have backups, right? 😉

You can find the source code here. What follows is an excerpt from the README.

Installation

Brck is available on crates.io. You can install it using Rust’s package manager Cargo.

$ cargo install brck

Usage

Without any options, Brck will record all regular files in current working directory recursively and write those records to a gzipped .brck file.

$ brck

When you run the same command again, Brck will compare the recorded files against the current file system and report any corrupted files.

$ brck
corrupted: ./test_file
Error: Found 1 denied difference

Brck is quiet by default. Increase the verbosity using -v or request a summary using -s. Alternatively, enable the JSON output using -J and perform your own post-processing, e.g., using jq:

$ brck -vvJ | jq -sr 'group_by(.type)[] | [.[0].type, length] | @tsv' 2>/dev/null
added   4
corrupted       1
unchanged       1219

See the built-in help for all supported options:

$ brck --help

Features

• Parallel sequential processing: Brck processes files in parallel, yet outputs and records files in-order

• One-pass: Brck reads your files only once

• Constant memory: Brck’s memory footprint is independent of the number of processed files

• Relative paths: Brck records relative paths such that you can move the containing directory around

• Quiet by default: Without any options, Brck prints denied differences to standard output, and errors to standard error; nothing else

• Human readable or machine readable, newline-delimited JSON output, at your option

• Graceful shutdown on the first interrupt signal, forceful immediate shutdown on the second

• Pledged and unveiled on OpenBSD

Limitations

• Brck doesn’t follow symlinks.

• Brck doesn’t track hardlinks. Performance will be suboptimal in the presence of large hardlinked files because Brck hashes each copy individually.

• Brck doesn’t track reflinks. Modern copy-on-write file systems are out of scope because they should check file content integrity themselves, like OpenZFS and Btrfs do.

• Brck may leak file meta data because its .brck file may have different permissions than the listed files.

• Brck doesn’t respect platform-specific temporary directories such as TMPDIR on UNIX. Instead, it creates its temporary files in the current working directory, next to the .brck file. This way, Brck can update the files atomically on POSIX-conform systems.

• Brck may fail to remove its temporary files, e.g., in the event of a segfault.

See also

• Definition of bit rot in the Jargon File (archive)

• A similar Python program named Bitrot

• A similar Rust program named Legdur

• A blog post on Things UNIX can do atomically