DuoBolt vs Czkawka — Speed, Safety and Restoring Files
Czkawka is a popular open-source duplicate finder, and on speed it is the closest competitor DuoBolt has. How far apart they land depends on what is limiting the scan: wide where per-file work decides it, a few percent on an external disk, and nothing measurable over a network.
All tests ran on an Apple M2 Max, macOS 27.0, on 20 September 2026, with each tool’s own cache cleared before every run, a 1 KB minimum file size and exact duplicates only. Czkawka 12.0.2, the czkawka_gui GTK build — the one brew install czkawka produces. Lower times are better.
Storage
DuoBolt
Czkawka
DuoBolt advantage
Internal SSD — 394 GiB, 1.69M files
38s
1m3s
1.66× faster
USB-C SSD — 797 GB
5m17s
5m39s
1.07× faster
NAS over SMB — 1.09 TiB
10s
11s
Tie
Key takeaway: the gap tracks what is limiting the scan rather than how large the dataset is. Across 1.69 million small files, where the cost is per-file work, DuoBolt finishes in well under half the time. On an external SSD the bus sets a ceiling both tools run into and the difference falls to 7%. Over SMB the two land inside the measurement’s resolution of each other. Of the four tools measured against DuoBolt, Czkawka is the closest on every tier.
The project now directs new users to Krokiet, a separate Slint front end sharing the same czkawka_core. The GTK build was measured because it is what Homebrew installs today. The full method covers all five tools.
DuoBolt gives you a visual interface to review and preview before anything moves, five ways out — Trash, delete, archive, copy and, for duplicates on a Mac, replace with a clone — and a history that restores from a surviving copy afterwards.
You scan millions of small files
Where per-file work decides the result rather than raw throughput, DuoBolt
finishes first: 38s against 1m3s across a source tree of 1.69 million files.
You want a removal to be undoable
DuoBolt never removes anything without a confirmation screen, and Operations History can restore what it moved from a surviving copy.
Both tools hash with BLAKE3 by default, and both prehash before committing to a full read, so the gap in the table above is not down to the algorithm. What DuoBolt does with it:
Per-root parallelism — all CPU cores stay busy across multiple scan roots at once, rather than one root after another
Streaming I/O — chunked reads overlap disk access with hashing, so a core is not waiting on a slow or network drive
Two-stage prehash — first and last 128 KiB, dropped to a 4 KiB head-only read on network volumes, where every extra round trip costs more than the bytes do
We have not read Czkawka’s source to say which of these it does differently. The timings are ours and the methodology is published; the explanation above is about our engine, not a claim about theirs.