The tool could only act on duplicates non-interactively or through a
line-oriented per-group prompt. Add a full-screen terminal UI (--tui) for
browsing and resolving them visually.
The UI is a two-pane master/detail view: a list of duplicate groups and,
for the selected group, its files with per-file deletion marks. Files can
be marked individually or in bulk by a keep-strategy (newest/oldest/first/
last/shortest/shallowest, reused from the resolver) applied to the current
group or to all groups at once. A footer tracks how many files are marked
and how much space would be reclaimed. Deletion is gated behind an explicit
confirmation, a group always keeps at least one file, and the highlighted
file can be opened in the system default application.
The design keeps the interaction logic pure and independently testable: an
App model translates an abstract key event into an outcome, so navigation,
marking, strategy application, and post-deletion model updates are all unit
tested without a terminal. Rendering (ratatui) and the destructive file I/O
live in the event loop, which restores the terminal on both normal exit and
panic so a crash never leaves it broken. --tui is mutually exclusive with
--keep and --interactive.
Content hashing is the pipeline's expensive stage; every run re-read and
re-hashed all size-collision candidates from scratch. Persist those hashes
so an unchanged file is skipped on subsequent runs.
Add a path-keyed cache mapping absolute_path -> (size, mtime, strict, hash,
last_seen), stored in a compact hand-rolled little-endian binary format with
a magic+version header. A candidate reuses its stored hash only when size,
mtime, and hash-mode all match; otherwise it is re-hashed and the entry is
refreshed. On save, entries unseen for 30 days are pruned so the file cannot
grow without bound. The hashing stage splits into hash_candidates (parallel,
cache-consulting) and group_hashed (grouping) so lookups stay inside the
parallel pass while cache mutation stays single-threaded after it.
The cache is strictly a performance hint: a missing, corrupt, version-
mismatched, or unwritable cache degrades to a correct full-hash run and
never fails or changes the result. Caching is on by default at the platform
cache directory; --no-cache disables it and --cache-file overrides the path.
The gxhash seed becomes a fixed constant so stored hashes are reproducible
across runs, which is what makes cache hits possible; rand is consequently
no longer a production dependency (now dev-only), and dirs is added for the
platform cache directory.
The deduplication core was a three-stage streaming producer/consumer
(scan -> group-by-size -> group-by-hash) orchestrated by a Server struct
that ran the stages concurrently on a threadpool. Coordination relied on
AtomicBool flags polled in busy-wait loops, an Arc<Mutex<Vec>> hand-off
queue, DashMap stores, and a per-file Arc<Mutex<FileState>>. Every stage
had to receive its own hand-cloned Arcs with ad-hoc names, and the
busy-wait branches burned a core spinning while waiting for the producer.
Replace it with a staged batch pipeline over owned collections:
pipeline::run(&Params) drives scan -> group_by_size -> group_by_hash in
sequence, with rayon supplying parallelism. With no shared mutable state
between stages, all the Arc plumbing, the AtomicBool coordination, the
Mutex queue, the per-file lock, server.rs, and the threadpool/dashmap
dependencies are gone. FileInfo becomes plain data and each stage is a
pure, independently testable function.
Behavior is preserved except for three authorized deviations: progress
spinners render sequentially rather than concurrently under -p; the
interactive empty-result message prints once instead of twice; and the
interactive "Duplicate Set X of Y" total now counts the confirmed
duplicate groups shown instead of the internal candidate-hash store size.
This lands as the foundation for the cache, CLI, and TUI work that follows.
