DedupCommando compared with fdupes, jdupes, rmlint, rdfind, fclones, Czkawka, dupeGuru and duperemove

This page compares DedupCommando v0.9.2 , a beta duplicate file finder for Linux, with eight established ones, using each project's own documentation, release notes and package listings. The others are more widely packaged, run on more systems and have been around longer, and Czkawka and dupeGuru are full desktop apps. DedupCommando is narrower: a terminal tool for ZFS pools that wraps every change in a snapshot, a quarantine and a fresh check.

Who each tool is for

• fdupes — for choosing by hand what to delete. The classic C tool (copyright from 1999) checks size and MD5, then compares byte by byte, offers an ncurses deletion screen and a signature cache; its man page lists no link action.
• jdupes — for scripted clean-ups. Forked from fdupes 1.51 and now hosted on Codeberg, it hashes with xxHash, still compares byte by byte, and can delete, hardlink, symlink or, on Btrfs, XFS and APFS, clone (-B); it runs natively on Windows too. fdupes vs jdupes: fdupes for its deletion screen, jdupes for links or clones.
• rmlint — for reading a plan before anything changes. It finds duplicates and other "lint" such as broken symlinks, and writes a shell script to review and run, with handlers to remove, hardlink, symlink, reflink or clone; BLAKE2b by default, byte by byte on request, and an optional GUI, Shredder.
• rdfind — for a one-shot run with a clear rule for which copy stays. The C++ tool filters by size, first and last bytes and a checksum (SHA-1 by default), ranks the copies, then deletes the extras or swaps them for hardlinks or symlinks; it has a dry run.
• fclones — for large trees and shell pipelines. A Rust CLI built for speed: fclones group lists duplicates, and remove, link, move or dedupe act on that list, with --dry-run. It trusts hashes of 128 bits or more; there is no byte-by-byte comparison.
• Czkawka — for one desktop app covering duplicates, empty folders, similar images and videos, and music. Written in Rust, with the Krokiet GUI (the GTK app ends at 12.0) and a CLI, it matches by size, a partial hash and BLAKE3, and can delete, move to the trash, hardlink or symlink.
• dupeGuru — for a GUI on Linux, macOS or Windows with picture and music modes. Written mostly in Python with Qt, it sends duplicates to the trash by default or replaces them with symlinks or hardlinks; its latest release, 4.3.1, is from July 2022.
• duperemove — for sharing storage on btrfs and XFS without removing any file. It hashes extents and passes identical ranges to the kernel's FIDEDUPERANGE ioctl, which compares the bytes first; a hashfile makes repeat runs incremental.
• DedupCommando — for ZFS pools, including storage on Proxmox VE, where you want a safety net and a review step. A Rust TUI, it hashes with BLAKE3, lets you mark a keeper per group, then deletes to a quarantine, hardlinks or reflinks under a ZFS snapshot.

At a glance

"Not documented": the project's own docs don't describe it. Packages: official Debian, Ubuntu and Arch repositories, Homebrew, crates.io, Flathub and channels a project names itself (AUR not checked).

ZFS and reflinks

OpenZFS 2.2.0 added block cloning, which newer versions of cp use to make clones. The dedupe ioctl FIDEDUPERANGE, used by duperemove and rmlint's clone handler, was left returning an error on ZFS; an implementation reached the development branch on 20 August 2026 but has not shipped in a release (latest: 2.4.4). fclones' dedupe uses FICLONE, and jdupes names Btrfs, XFS and APFS for -B; none of these four mentions ZFS in its README or man page. DedupCommando's reflink needs OpenZFS 2.3+ with block_cloning and, like a hardlink, stays within one dataset.

Where the others are better

• Desktop GUIs and look-alike media. Czkawka and dupeGuru are point-and-click apps that also find similar images; Czkawka adds similar videos and music. DedupCommando is terminal-only and matches byte-identical files only (what it does not do).
• Published speed numbers. fclones came first in both runs of its README benchmark: 35 seconds for 1.46 million paths (316 GB) on an SSD, against two to eight minutes for Czkawka, rmlint, jdupes, fdupes, rdfind and dupeGuru; every tool was an older version. DedupCommando publishes no comparable benchmark.
• Packaging. fdupes, jdupes and rdfind are in Debian, Ubuntu, Arch and Homebrew; fclones and Czkawka are on crates.io, Czkawka also on Flathub. DedupCommando has only its own APT repository (Debian 13, Proxmox VE 9) and release tarballs for amd64 and arm64 (glibc ≥ 2.39); it is not yet on crates.io, AUR, Homebrew or in distribution repositories.
• Maturity. fdupes dates from 1999 and jdupes grew out of it; DedupCommando is a young beta, as the leading zero in its version says.
• Platforms. jdupes runs natively on Windows, and fclones, Czkawka and dupeGuru also run on Windows and macOS. DedupCommando is Linux-only.
• Unattended changes. jdupes, rdfind and fclones can link or remove from a script or a cron job. DedupCommando's headless mode only scans; applying needs the TUI, by design.
• Partial matches and other filesystems. duperemove shares identical extents, so partly identical files still save space. DedupCommando works on whole files, and outside ZFS it scans without a snapshot safety net (limitations).

Where DedupCommando is different

Others let you look first too: fdupes re-checks files before deleting, rmlint's script is meant to be reviewed, fclones and rdfind have dry runs. DedupCommando differs in what surrounds each change (safety model):

• A snapshot per dataset, before the batch. Every dataset the batch touches is snapshotted first; if one snapshot fails, nothing runs (snapshots).
• Quarantine instead of delete. "Delete" moves the file to .dedcom-quarantine/ on its dataset, with its owner, permissions and extended attributes; the space returns when you purge (quarantine).
• Re-validation before each action. Target and keeper are checked again for a symlink swap, size and content hash; a mismatch cancels that action (revalidation).
• Atomic publish. The original moves to quarantine and renameat2(RENAME_NOREPLACE) puts the prepared link in its place; if that fails, the original comes back (atomic publication).
• Reflink through ZFS block cloning. The duplicate becomes its own file that shares blocks with the keeper and keeps its owner, mode, ACL, extended attributes and timestamps (reflink; hardlink vs reflink).
• Dataset awareness. Snapshots and quarantine follow dataset boundaries, and a move across one is refused with an rsync hint instead of a silent copy-and-delete (cross-dataset refusal).
• Review in a TUI first. You mark a keeper and an action per group; F11 shows the batch by type, its first paths and the generated shell script, which you can save for your records (confirmation).
• Resumable scans. Walking and hashing are checkpointed, so a scan interrupted midway resumes (resume). Hash caches are common: all the others except rdfind document one.

Which one should you use

• Cleaning up photos on a desktop: a GUI tool, Czkawka (Krokiet) or dupeGuru, which also find similar, not just identical, pictures.
• Block-level savings on btrfs or XFS: duperemove; the kernel checks each range before sharing it. jdupes -B and rmlint's clone handler cover whole files there.
• A quick one-off on the command line: jdupes, fclones or rdfind; fdupes if you want to pick keepers in an interactive screen, fclones for very large trees.
• ZFS storage, including Proxmox VE hosts, with a safety net and a review step: DedupCommando, a jdupes or Czkawka alternative for that case. Scan with the Idle profile on a busy host, review in the TUI, and apply under a snapshot with quarantine. Read the safety model first, and see file-level deduplication on ZFS.

Facts checked on 2026-09-28; tell us if something changed.

Man pages used: fdupes, jdupes, rmlint, rdfind, duperemove.

DedupCommando is an independent project, not affiliated with the projects compared here or with Proxmox Server Solutions GmbH.