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
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