instructions/FAQ.md
This document collects recurring questions and problems from the GitHub issue tracker. It is derived from hundreds of real user reports and is updated alongside the project.
Both share the same scanning engine (czkawka_core). The difference is the frontend:
Just use Krokiet - it is the recommended frontend for all platforms.
Czkawka and Krokiet do not make any network connections. The application has no telemetry, no update checks, and no analytics. If you observe network traffic in a sandboxed analysis, it is typically caused by the analysis environment itself.
If you want to confirm this yourself, look through Cargo.lock in the repository - there are no networking/HTTP/telemetry crates among the dependencies (no reqwest, hyper, curl, etc.), so the app has no code path that could reach the Internet.
The actively maintained download sources are:
The Flathub package (GTK GUI) still exists but is no longer maintained by the author and is frozen at v10.0 - it lags far behind. There is no Krokiet Flatpak.
Sites such as czkawka.net, czkawka.com, czawka.net and similar are not official and may be unsafe.
You can run instances of different tools simultaneously (each tool has its own cache file). However, you must not run two instances of the same tool at the same time - doing so can corrupt the cache for that tool.
The project is not uniformly MIT - it depends on the component, and for the Slint apps it depends on whether you mean the source or the finished binary:
LICENSE_MIT_CODE in each crate), but the apps as a whole are GPL-3.0-only. This is because they link the Slint UI framework under its free license, which is GPL-3.0; so the resulting combined work / binary must be distributed under GPL-3.0 (see LICENSE_GPL_APP). In other words: you may reuse their code under MIT, but a built Krokiet/Cedinia is GPL.The per-component LICENSE_* files in each crate directory hold the exact texts.
There are third-party Docker images by jlesage that wrap the GUI in a VNC/web UI accessible from a browser: jlesage/krokiet (Krokiet) and jlesage/czkawka (the GTK GUI).
Yes. Nightly builds compiled from the latest master branch commits are published at https://github.com/qarmin/czkawka/releases/tag/Nightly. They may contain unknown bugs but include the newest features and fixes before an official release.
Krokiet itself is a single self-contained binary - just download, run, and it works. You only need to install extra system libraries if you want optional functionality: ffmpeg for the Similar Videos tool, and libheif/libavif/libraw if you use a build with those image-format features. (The GTK GUI additionally needs GTK4 itself at runtime.)
There are ready-made scripts in the repo that install these dependencies for you (misc/install_scripts/):
install_linux.sh (run with sudo) - auto-detects apt / dnf / pacman / zypper and installs ffmpeg + gtk4 (base) and libheif/libraw/libavif/dav1d (optional).install_macos.sh - installs (and offers to set up Homebrew, then) ffmpeg libheif libraw libavif via brew.install_windows.bat - installs ffmpeg via winget; notes that libheif/libraw/libavif are only available through MSYS2 builds.Per platform:
Linux: download linux_krokiet_x86_64 (or _arm64), chmod +x it, and run. For HEIF/AVIF/RAW use a heif_raw_avif build and install the matching libs (or just run sudo misc/install_scripts/install_linux.sh). The GTK GUI needs GTK4 installed.
Windows: download a windows_krokiet_on_* build and run the .exe - no runtime to install for the core app. Install ffmpeg (e.g. winget install Gyan.FFmpeg or misc/install_scripts/install_windows.bat) only if you need Similar Videos.
macOS: download mac_krokiet_arm64 (Apple Silicon) or mac_krokiet_x86_64 (Intel), then:
chmod +x mac_krokiet_arm64
./mac_krokiet_arm64
If macOS says "cannot be opened because it is from an unidentified developer", right-click the file and choose "Open", then confirm. If it opens as text in TextEdit, the executable bit is not set - run chmod +x first. For optional codecs use a heif_avif build and brew install ffmpeg libheif libavif libraw (or run misc/install_scripts/install_macos.sh). The GTK GUI (mac_czkawka_gui_*) additionally needs brew install gtk4.
com.github.qarmin.czkawka): Was author-maintained but is no longer updated and is stuck at v10.0. It still works but lags far behind; hopefully a new maintainer takes it over. No Krokiet Flatpak exists.The Similar Videos tool requires ffmpeg to be installed separately and available in PATH. Krokiet and czkawka_cli do not bundle ffmpeg.
| OS | Installation |
|---|---|
| Linux | sudo apt install ffmpeg (Debian/Ubuntu), sudo pacman -S ffmpeg (Arch) |
| macOS | brew install ffmpeg |
| Windows | Install from ffmpeg.org and add the folder containing ffmpeg.exe to the system PATH. On Windows, you can also place ffmpeg.exe in the same folder as the Krokiet executable. |
After installation, restart Krokiet or the CLI. On Windows, a new terminal session (or system restart) may be required for the PATH change to take effect.
The release assets stack a few naming components, e.g. <os>_<app>[_<features>][_<backend>]_<arch>. Once you know the legend below, the same scheme applies to every platform, so there is nothing extra to learn per OS.
krokiet - primary graphical version of the application, fully supported and actively developed, includes new features and ongoing improvementsgtk_gui (czkawka_gui) - legacy GTK-based graphical version, maintenance mode only, receives critical fixes but no new featurescli (czkawka_cli) - command-line version of the appcedinia - experimental Android apparm / arm64, x86_64 - CPU architecture. Most Windows/Linux machines use x86_64, while on Mac the arm (Apple Silicon) version is becoming the most common choiceheif, raw, avif - additional image-format features that require extra libraries installed on the OS (libheif / libraw / libavif)skia_opengl, skia_vulkan, femtovg_wgpu, all_backends - alternative Krokiet rendering backends; different builds may fix some problems like blurry fonts or graphics crashes. all_backends bundles all of them (plus launcher scripts) in one packageapk / aab - Cedinia Android package formats - just use apk; aab is used only for testing purposeson_linux / on_windows - which host the .exe was cross-compiled onPick krokiet for your architecture with the default backend - it is built to be the most compatible everywhere. Only reach for a skia_opengl / skia_vulkan / femtovg_wgpu / all_backends build if the default one shows blurry text, fails to render, or crashes on your GPU. Choose a heif / raw / avif build only if you need those image formats (and install the matching system libraries). On Windows, if you are unsure between on_linux and on_windows, start with windows_krokiet_on_linux.
Try the software renderer by setting the environment variable before launching:
SLINT_BACKEND=software krokiet
On systems without a GPU (VMs, headless servers), this is often the only option.
The default linux_krokiet_* binary only ships the femtovg and software renderers. If you want to try Skia/OpenGL/Vulkan/wgpu backends too, download the linux_krokiet_all_backends_* build - it is packaged as a ZIP that contains the binary plus small bash launcher scripts, one per renderer, that just set the right SLINT_BACKEND and start the app. So instead of exporting the variable yourself you can simply run, for example, ./krokiet_winit_skia_opengl.sh, ./krokiet_winit_skia_vulkan.sh, ./krokiet_winit_software.sh, ./krokiet_femtovg_wgpu.sh, or ./krokiet_winit_femtovg.sh until one renders correctly.
Only one GTK build is shipped: windows_czkawka_gui_gtk_412.zip (GTK 4.12). The ZIP also contains czkawka_cli.exe and small .bat launchers that set GSK_RENDERER (cairo / opengl / vulkan) for the GTK GUI. If the GTK GUI renders a black window or fails to start with the default renderer, run those launchers instead of the .exe directly until one works (cairo is the safest software fallback). The GTK GUI is deprecated - prefer Krokiet, which needs no GTK at all.
Yes. Version 12.0 is the last released version of the Czkawka GTK frontend - no new GTK binaries will be provided, and no new features are planned. (Any Docker or distro packages built on top of it are third-party, not maintained by the project author.)
All new features and active development happen in Krokiet. Users should migrate to Krokiet.
The GTK frontend has persistent platform issues on Windows and macOS that cannot be fully fixed due to the nature of the GTK4 Windows/macOS port. These include:
Krokiet avoids all of these by using the Slint framework, which has a pure-Rust rendering pipeline and no dependency on GTK.
Windows 10 is the minimum supported version. The Rust standard library has dropped support for older Windows versions, so running on Windows 7 or Windows XP is not supported and is very unlikely to work with any current release. There are no plans to support systems that have themselves been out of support for years. Windows 10 will likely keep working until Rust itself drops it, which is probably ~10 years away.
For the GTK GUI: create or edit %LocalAppData%\gtk-4.0\gtk.css (Windows) or ~/.config/gtk-4.0/gtk.css (Linux) with:
* {
font-size: 22px;
}
Adjust the value as needed. Alternatively, use Krokiet, which supports a manual scale factor in Settings.
This is usually a GPU driver or rendering backend issue. Try, in order:
all_backends build and start it through its per-backend launcher scripts (or set SLINT_BACKEND yourself) until one renders correctly.SLINT_BACKEND=software krokiet (Linux/macOS), or set SLINT_BACKEND=software in Windows system environment variables and restart. On machines without a GPU (VMs, headless servers) this is often the only option.| Platform | Config | Cache |
|---|---|---|
| Linux | ~/.config/krokiet/ | ~/.cache/czkawka/ |
| macOS | ~/Library/Application Support/pl.Qarmin.Krokiet/ | ~/Library/Caches/pl.Qarmin.Czkawka/ |
| Windows | %APPDATA%\Qarmin\Krokiet\config\ | %LOCALAPPDATA%\Qarmin\Czkawka\cache\ |
| Flatpak | ~/.var/app/com.github.qarmin.czkawka/config/czkawka/ | ~/.var/app/com.github.qarmin.czkawka/cache/czkawka/ |
The cache is shared between all frontends (CLI, Krokiet, GTK). Both Krokiet and the GTK GUI read and write the same cache files in ~/.cache/czkawka/.
The Krokiet config files are:
config_general.json - window size, language, dark/light theme, current preset, etc.config_preset_N.json (N = 0-10) - per-preset scan directories and tool settings. There are 11 slots: 10 user presets plus a reserved one ("CLI Folders").config_custom_select_state.json - saved state for the custom-select dialog.The cache stores only metadata (hashes, timestamps, sizes) - not file contents. A typical large scan (150 TB of files) may produce a cache a few hundred MB in size at most, not terabytes.
It removes cache entries for files that no longer exist on disk. This keeps the cache lean and avoids stale entries being used in future scans. Click it periodically if you have deleted many files since your last scan, and you want to increase the speed of loading/saving the cache.
If you suspect cache corruption (e.g., scan results look wrong, or the app crashes when loading cache), you can delete the cache files in ~/.cache/czkawka/. The next scan will rebuild the cache from scratch, which will be slower but may fix your issues.
The duplicate finder uses a two-stage hashing pipeline:
Both stages have separate cache files. This is why you see two cache files for the duplicate tool. The prehash cache is much cheaper to build; the full hash cache is the authoritative deduplication signal.
The cache is stored as a binary .bin file by default. When the .bin file is absent, the application falls back to loading a .json file if one exists. To enable JSON cache saving, turn on "Save also as JSON" in the GUI settings. You can then edit the JSON and remove the .bin file to force the app to load the JSON version.
Changing directory paths in the JSON cache directly is possible in principle, but the entries also contain file sizes and modification timestamps, so any path change must remain consistent with the actual filesystem state. Stale entries are simply ignored on the next scan.
The most common reason is the minimum file size setting. In the Krokiet GUI the default minimum is 16 KB (16 384 bytes), so smaller files are ignored. (The CLI uses per-tool defaults, and for dup that default is lower - 8 192 bytes.) To scan smaller files:
1.--minimal-file-size 1 to the command.A large share of users scan whole drives looking for duplicates, and at that scale tiny files (a few bytes to a few KB - config snippets, empty placeholders, license headers, icons) are very often identical by pure coincidence without being meaningful duplicates. Surfacing thousands of such matches mostly just buries the larger duplicates the user actually came to find and makes the results harder to review. The 16 KB floor keeps the focus on duplicates worth acting on. If you specifically want the small ones, lower the minimum size as shown above.
In the GUI this should not happen by default: the default Excluded Items already cover the trash on every platform - *:\$RECYCLE.BIN\* (and other Windows system dirs) on Windows, and */Trash/* + */.Trash-*/* on Linux/macOS. So out of the box, scanning even a whole drive root (C:\ or /) skips the Recycle Bin / Trash.
If trash files still show up in the GUI, your Excluded Items field was probably cleared or edited and lost those defaults. Restore them (or reset excluded items to the default) - for example add back:
*:\$RECYCLE.BIN\**/Trash/*, */.Trash-*/*In the CLI these defaults are not applied automatically - you must add the exclusions yourself with -E / --excluded-items. To make this easy there are two macros that expand to the same patterns the GUI uses:
$TRASH - just the OS trash / recycle bin (*/Trash/*,*/.Trash-*/* on Linux/macOS, *:\$RECYCLE.BIN\* on Windows).DEFAULT - the full set of default GUI exclusions (trash plus .git, node_modules, caches, Windows system dirs, etc.).# Skip the trash while scanning a whole drive:
czkawka_cli dup -d / -E '$TRASH'
# Or apply the complete GUI default exclusion set:
czkawka_cli dup -d / -E DEFAULT
(Quote $TRASH in shells like bash/zsh so it is not treated as a variable.)
No. The number shown for "Analyzed full hash of X/Y files" reflects only the files that reached the full-hash stage, not the total number of files scanned. Files that differ in size or prehash never need a full hash, so Y can be much smaller than the total file count. This is expected and correct behavior.
The progress bar is already size-based, so a very large last file legitimately takes a while - but the more common reason it looks frozen is that per-file work (decoding, hashing, verifying a file) is run as one indivisible task. The app can only stop between tasks, not in the middle of one, so while a single huge or slow-to-decode file is being processed there is nothing to interrupt - and Rust cannot forcibly abort it either, because the work runs in-process as a normal function call, not as a separate external process (usually) that could simply be killed. So a single pathological file can make the whole scan appear stuck and unresponsive to Stop until it finishes.
For some tools this has been improved by splitting large tasks into smaller, individually-interruptible chunks so Stop reacts quickly - this already applies to e.g. duplicate finding and similar-video search. Other tools may still block until the current file is done.
hide_hard_links option is on in both Krokiet and the CLI), so multiple names sharing one inode are counted once rather than flagged as duplicates of each other. Turn that option off (CLI -L / --allow-hard-links) if you want hard links treated as separate files.Check these settings:
0 means only effectively identical hashes are matched. The Krokiet GUI default is 10. The allowed range scales with hash size (up to about 40 at hash size 64), so raise it to catch looser near-duplicates. (The CLI's default is lower - 5 - so if you scan via CLI you may need to raise -s.)Supported in all builds: JPEG, PNG, BMP, TIFF, WebP, TGA, plus the less common FF (Farbfeld), QOI, EXR, and JXL. (These are the extensions the Similar Images tool actually enumerates.)
Formats requiring optional features:
heif feature (requires the libheif system library on Linux/macOS).libavif feature - compile with --features libavif or use a binary variant whose name includes avif.rawler library, but it does not cover every format and not always fully. The optional libraw feature adds the libraw backend - the industry-standard library - which supports a larger set of RAW formats more completely. So RAW works without any special build; use a libraw build only if your camera's format is missing or mis-decoded.Yes. The Similar Images tool compares pixel content regardless of the file format. A JPEG and a WebP that contain the same visual content will be grouped together, as long as both formats are supported by the build you are using.
Yes - and there is currently no built-in option to exclude greyscale matches. All perceptual hash algorithms (Mean, Gradient, Double Gradient, Blockhash) ignore color and work on luminance, so a greyscale conversion of an image will appear highly similar to the original. If you want to avoid greyscale false positives, you must filter results manually or with a post-processing script.
Yes - via the Geometric invariance setting (CLI --geometric-invariance). It has three modes:
off (default) - compare images as-is.mirror-flip - also match mirrored/flipped variants.mirror-flip-rotate90 - also match 90/180/270-degree rotations.These modes make matching more expensive, which is why they are off by default. EXIF orientation is always applied before hashing regardless of this setting.
Lower the Max difference (similarity threshold). The default setting 10 can match visually distinct images if they share large uniform areas (e.g., black borders, white backgrounds). Try 4 or 5 for stricter matching. Also try increasing the hash size (e.g. 32 or 64): a larger hash captures more detail, so unrelated images are less likely to collide - at the cost of being slightly stricter about re-encoded/resized copies.
The settings control the perceptual hashing step in Similar Images:
Mean, Gradient, VertGradient, DoubleGradient, Median, and Blockhash. Mean (the Krokiet GUI default) is the fastest and most permissive. Gradient / VertGradient / DoubleGradient are more sensitive to structural differences. Median is more robust against brightness/color shifts. Blockhash is a different approach that can find different near-duplicates.Practical guidance: for finding re-encoded/resized copies of the same image, start with Mean hash + size 16 and a "max difference" of 8-10. For stricter matching (fewer false positives), use Gradient/Double Gradient with size 32 and lower the max difference to 4-5.
Ensure you are using a build that includes the heif feature. The plain linux_krokiet_all_backends_x86_64 binary does not include HEIF/AVIF support. Use a heif_raw_avif variant (e.g. linux_krokiet_heif_raw_avif_x86_64) or compile with the appropriate feature flags:
cargo run --bin krokiet --features "winit_femtovg,winit_software,heif,libavif,libraw"
Similar Videos works by sampling frames from the video and computing visual perceptual hashes, then comparing those hash sequences across short temporal "windows". The matching engine is provided by the project's own similario_core crate. ffmpeg/ffprobe must be installed for frame extraction.
The Krokiet GUI exposes visual presets (Custom, Near-identical, Similar, Movies) that set sensible values; the underlying parameters (also exposed individually in the CLI) are:
0-20; GUI default 15, CLI -t default 10). Lower = stricter.--skip-forward-amount, default 15 s): how many seconds to seek into the video before sampling begins, to skip intros/black openers (0-300; 0 = no skip).-A, default 10 s): how long a span of the video is sampled to build the signature.1-20): how many temporal windows are sampled. More windows = more accurate but slower.0.0-1.0): the fraction of windows that must agree to call two videos "same content".There is also an optional audio fingerprint comparison (off by default, resource-intensive) with its own similarity/duration parameters. Note: there is no setting that simply skips both the start and end of every video, nor a single "minimum video duration" toggle - very short videos are skipped because they cannot fill the sampled windows.
Similar Videos compares videos by sampling frames and computing visual hashes. False positives (unrelated videos grouped) are common when:
If instead the scan finds nothing (real duplicates are missed), the cause is usually that the sampled span does not capture enough of the video. Several settings feed into this, so check them together:
The algorithm is fundamentally heuristic and works best for finding re-encoded copies of the same source material, not for finding videos that happen to have a few similar-looking scenes.
Yes, the video hash cache is stored in ~/.cache/czkawka/ and is reused on subsequent scans. Each video is processed once; subsequent scans load the pre-computed hash from cache.
Note that the cache is keyed by the video processing parameters (the settings that affect how each video is sampled and hashed - scan duration, window count, skip forward amount, etc.). Changing any of these makes the app use a different cache file, because the computed hashes would otherwise differ. So after changing a processing parameter you have to rescan, and that scan re-processes the videos from scratch. Parameters that only affect how the already-computed hashes are grouped into the similar-videos list (e.g. max difference / min matching windows) do not invalidate the cache.
A reference folder is a directory added to the scan but protected from deletion or modification. Files in reference folders appear in the results only for comparison - they show which "keep" candidate they matched against. Files outside reference folders can be selected and deleted normally.
Typical use case: add your main, well-organized collection folder (e.g. your curated photo or music library) as a reference, add a downloads folder as a regular included path, then scan. Only files in the downloads folder will be selectable for deletion; the files in your main collection are always preserved.
Use Reference Folders. Add the folder you want to protect as a reference folder (check the "Reference" checkbox next to it in the directory list). After the scan, only files outside the reference folder appear as selectable. Use "Select All" and then delete - this will only delete the non-reference copies.
No. When a reference folder is set, only groups that contain at least one file from the reference folder are shown. Groups that are entirely within non-reference directories are hidden. This is intentional: the reference folder marks "originals", so a group is only meaningful when at least one original is present.
Use the -r / --reference-directories flag. To specify multiple reference directories, repeat the flag:
czkawka_cli dup -d /path/to/search -r /path/to/ref1 -r /path/to/ref2 -D AEO
Using comma- or semicolon-separated values in a single -r flag does not work. Each reference directory must be a separate -r flag.
Common causes:
-y/--move-to-trash opting into trash). On network shares (SMB, NFS) the move-to-trash path can fail because the remote filesystem has no usable trash location. Fix: use the permanent Delete button (or omit -y in the CLI) instead of moving to trash.On the same filesystem, Krokiet performs a rename (which is instant). If the source and destination are on different filesystems (e.g., moving from one drive to another), a full copy-then-delete is performed, which is expected to be slow. This is not a bug.
This is a known behavior of the Flatpak sandbox. Files moved to trash inside a Flatpak container go to ~/.Trash-<uid>/ rather than ~/.local/share/Trash/. This cannot be configured and is a limitation of the Flatpak sandbox, not of Czkawka itself.
Hardlink replaces selected duplicate files with hard links pointing to one retained copy. After hardlinking, all files share the same inode - they appear as separate filenames but consume disk space only once. Note: hardlinking across different filesystems or partitions is not possible. Such a pair is not silently skipped - the operation fails for it and an error is reported (e.g. "Failed to hardlink ...: Invalid cross-device link"); the original file is left untouched, so nothing is lost.
No. Each group is processed independently. Within group A, the unselected file becomes the "original" and selected files become hard links to it. Within group B the same happens independently. Files from different groups are never linked together.
The "Select Custom" dialog selects files based on a text pattern matched against the file name, path, or a regex. Common mistakes:
* as a wildcard.Or set the folder you want to keep as a Reference Folder - reference folder files are never selected by any automatic selection mode.
No. The automatic selection modes ("Select All Except Oldest", "Select All Except Newest", etc.) always leave at least one file in each group unselected. The plain "Select All" button selects every checked row, but each group's header row (the first entry) is always left unselected by the automatic modes. If you manually check every row yourself, you can select all files in a group - but even then, the delete operation will warn you before proceeding.
When using the CLI with -D AEN / -D AEO etc., the delete mode is described by its name: "All Except Newest" always keeps exactly one file per group.
Yes. In the "Regex Path + Name" field, enter a regex that matches the extension. For example, to select all .mp3 files:
.*mp3
Or for .flac files:
.*\.flac$
On Windows, use a plain path prefix without a trailing backslash or wildcard. For example, enter C:\Users\username\Desktop (not C:\Users\username\Desktop\*). The filter matches any file whose path contains the entered string as a substring.
In Krokiet: select the files in the results list and use the Rename button (or right-click > Rename). The suggested new extension is shown in the "Extra" column (current_ext -> correct_ext).
In the CLI: pass -F / --fix-extensions to bad-ext and the matched files are renamed automatically to use the detected correct extension:
czkawka_cli bad-ext -d /path/to/scan -F
In the GTK GUI: renaming from the GUI is not supported. Export results and rename manually.
The extension detection uses file magic bytes (the infer crate). Many file formats share the same leading bytes, so there is no unambiguous way to pick a single "correct" extension from the content alone. Examples:
.zip, .docx, .xlsx, .pptx, .jar, .apk, .epub) all start with the same ZIP signature..doc, .xls, .ppt) are compound binary files that share the same OLE container header.In those cases the tool can only report the family it detects, not which specific extension is "right". Some less common formats may also simply be missing from the library's database. You can exclude specific extensions from the scan if needed.
Use the Excluded Items field (not Excluded Directories). Add a wildcard pattern that matches the directory name anywhere in the path. Examples:
@eadir: */@ea*.Spotlight-V100, .fseventsd, etc.: */.Spotlight*, */.fseventsd*.): use Excluded Directories to add the specific paths.The excluded items patterns use * as a wildcard and match against the full path of each file/directory.
On Windows, UNC paths like \\server\share\ may not be shown in the file picker dialog. Use the "Manual add" text input in the directories panel to type or paste the UNC path directly.
If that still gives you trouble, it is worth mapping the share to a drive letter (e.g. net use Z: \\server\share or Explorer > "Map network drive"), then scan the resulting Z:\ path instead - a regular drive letter behaves more predictably than a raw UNC path.
C:\System Volume Information - Access is deniedThis is expected. System directories and volumes reserved by Windows are inaccessible to normal user processes. Czkawka logs access errors but continues scanning the rest of the directory tree. These errors are harmless.
Not currently. Drag and drop to add directories is not implemented, because Slint (the UI framework Krokiet uses) does not yet expose drag-and-drop support. Once Slint adds it, it can be implemented in Krokiet. For now, use the "Add" button or type/paste the path directly in the text field.
I used to publish a Snap but I no longer maintain it - I dropped Snap builds in v9.0, so the last Snap is stuck at v8.0 and it has known permission issues for external drives and NFS mounts. Use the pre-built binary from the GitHub releases page instead (recommended).
Yes - I no longer maintain the Flathub package (GTK GUI, com.github.qarmin.czkawka); it is frozen at v10.0, so it is many versions behind. It may be adopted by a new maintainer in the future. For the latest version, use the pre-built binary from the GitHub releases page.
Scanning speed on HDDs is limited by seek time. The application collects file metadata and sorts files by inode number before reading, which improves sequential read patterns. However, with very large directories, performance will still be significantly slower than on an SSD.
Tips:
In Krokiet itself this should not happen - the results list is virtualized and Krokiet can render millions of entries without any problem. The one place that can genuinely slow down is the bottom text/output panel: when it accumulates a very large amount of text, rendering that text gets slow. That is a Slint text-rendering bug, not a problem with the result list. As a workaround, collapse or hide the bottom panel.
Yes. Different stages stress different resources: some steps are heavily CPU-bound (the perceptual-hashing / decoding work, parallelized across all cores, which makes CPU usage spike), while others are mostly disk-bound (reading file contents). This is normal. If you want to keep CPU usage down, you can limit the number of threads (CLI -T <N> / --thread-number, or the thread setting in the GUI).
Repeat the -d / --directories flag for each directory. Do not separate paths with spaces or commas within a single flag:
# Correct:
czkawka_cli dup -d /path/to/dir1 -d /path/to/dir2
# Wrong (will fail):
czkawka_cli dup -d /path/to/dir1 /path/to/dir2
Use the -D flag with a delete strategy. Example - keep the oldest copy, delete all others:
czkawka_cli dup -d /path -D AEO
Available strategies: AEN (all except newest), AEO (all except oldest), ON (only newest), OO (only oldest), AEB (all except biggest), AES (all except smallest), OB (only biggest), OS (only smallest), HARD (replace with hard links).
Add --dry-run to preview what would be deleted without actually deleting anything.
--allowed-extensions seems to exclude extensions instead of including themThis was a bug in older versions (the filter logic was inverted). It is fixed in recent releases. Update to the latest version.
Use the -f / --file-results flag for a plain text output, or -C for compact JSON, or -p for pretty-printed JSON:
czkawka_cli dup -d /path -f results.txt # plain text
czkawka_cli dup -d /path -C results.json # compact JSON
czkawka_cli dup -d /path -p results_pretty.json # pretty JSON
The CLI does not show a real-time progress bar (no spinner/percentage in current releases). It prints the high-level stage transitions as the scan proceeds, but there is no live per-file progress counter.
Use --do-not-print-results (-N) to suppress the results listing, and --do-not-print-messages (-M) to suppress informational messages and warnings. Both can be combined.
Use -T <N> / --thread-number <N>. Setting 0 (the default) uses all available CPU threads.
Use -P <ext> / --excluded-extensions <ext> to exclude specific extensions. Use -x <ext> / --allowed-extensions <ext> to scan only specific extensions. The --allowed-extensions flag also accepts macros: IMAGE, VIDEO, MUSIC, TEXT.
Use -E <pattern> / --excluded-items <pattern> with wildcards (e.g. -E '*/temp*'). Unlike the GUI, the CLI does not apply any default exclusions automatically. Two macros expand to the same patterns the GUI uses by default:
$TRASH - the OS trash / recycle bin only (*/Trash/*,*/.Trash-*/* on Linux/macOS, *:\$RECYCLE.BIN\* on Windows).DEFAULT - the full default GUI exclusion set (trash plus .git, node_modules, caches, Windows system dirs, etc.).czkawka_cli dup -d / -E '$TRASH' # skip the trash/recycle bin
czkawka_cli dup -d / -E DEFAULT # apply all GUI default exclusions
Quote $TRASH so your shell does not expand it as a variable.
Yes. Add --dry-run to preview what would be deleted without actually deleting anything. Note that dry-run output currently goes to the console only and is not written to the result file.
This is a well-documented false positive affecting Rust binaries compiled with Link-Time Optimization (LTO). The binary is built from open source code via a public CI (GitHub Actions), and the SHA256 checksums match the CI artifacts.
To verify:
To resolve the Defender block: allow the file in Windows Defender by clicking "More info > Run anyway", or add an exclusion for the binary in Defender settings.
If your antivirus continues to flag it, report the file as a false positive to your antivirus vendor.
This is normal. Czkawka tries to scan all directories under the included path. Some system directories (.ssh, /proc, /sys, /dev) are not readable by normal users. These errors are logged and the scan continues. To suppress them, add those directories to the excluded paths.
If you genuinely need to scan such a location, first check your own permissions on it (ownership and mode), and only as a last resort run the application as administrator / root - though scanning a whole system as root is rarely what you actually want, and it lets the tool act on files a normal user could not.
Usually means the trash is on a different filesystem from the file (e.g., the file is on a network share or a secondary drive that does not have a .Trash-<uid> directory). Solutions:
This message comes from the symphonia decoding library, which checks the bitstream strictly: it reports that the MP3 header contains a main_data_begin value pointing outside the bitstream. symphonia is quite pedantic and flags such issues even when they are harmless - many MP3 files carry this "error" because of encoder quirks, and most media players (and likely your own player) decode and play them just fine. The file is still playable; you can ignore this result or keep the file.
These files are created automatically by the operating system / FUSE-based filesystems - this is not something Czkawka or Krokiet does. When a file that is still open in another application is "deleted", FUSE renames it to a hidden .fuse_hidden... name and only truly removes it once the last handle is closed. They are not duplicates in the usual sense. You can exclude them by adding */.fuse_hidden* to the excluded items list.
Yes. Set the following environment variables before launching the application:
CZKAWKA_CACHE_PATH - path where cache files are storedCZKAWKA_CONFIG_PATH - path where config files are storedThese variables are read by czkawka_core, so they apply to all frontends (CLI, GTK GUI, and Krokiet).
Example (Windows):
set CZKAWKA_CACHE_PATH=D:\czkawka\cache
set CZKAWKA_CONFIG_PATH=D:\czkawka\config
krokiet.exe
Example (Linux/macOS):
CZKAWKA_CACHE_PATH=/opt/czkawka/cache CZKAWKA_CONFIG_PATH=/opt/czkawka/config krokiet
Hardlinking system files can cause instability because changes to one hard-linked file affect all names pointing to the same inode. To undo hard links, you need to copy each file to break the link:
On Windows (PowerShell):
# For each affected file:
Copy-Item "C:\path\to\file.dll" "C:\path\to\file.dll.bak"
Remove-Item "C:\path\to\file.dll"
Rename-Item "C:\path\to\file.dll.bak" "file.dll"
On Linux/macOS:
# cp --remove-destination creates a new independent copy
cp --remove-destination original.so original.so
To prevent this in the future: always add system directories (C:\Windows, /usr, /lib, etc.) to the Excluded Directories list before scanning.
Yes. When "Ignore same inode" (or "Hide hardlinks") is enabled, files that share the same inode number are treated as a single logical file and only one representative is shown in results. This prevents already-hardlinked files from being flagged as duplicates.
By default, Czkawka does not follow symbolic links. A symlink is treated as its own filesystem entry; the scan does not traverse into the symlink target. This prevents accidental deletion of original files when a symlink points to them.
If you want to scan the contents of a symlinked directory, add the target path directly as an included directory instead of the symlink.
When you use the "Symlink" action, Czkawka replaces the selected (duplicate) files with symlinks pointing to the first unselected file in the group. The original (unselected) file is kept intact. The selected files are replaced in-place; their directory entry becomes a symlink.
On Windows, creating symlinks requires elevated privileges or Developer Mode to be enabled.
No. Czkawka reads files through the standard filesystem API. MTP (Media Transfer Protocol, used by Android phones) is not a real filesystem and is not accessible via normal file paths on Windows or Linux. To scan phone contents, either:
jmtpfs on Linux).Not officially. czkawka_core is platform-independent and can be compiled for Android, but there is no official Android app. Community members have successfully run Krokiet inside Termux (using termux-x11 or SSH X forwarding) on arm64 devices, but this is unsupported and requires manual compilation. See discussion #1073 for community notes.
You can export results to files using the "Save" button in the GUI or the -f / -C / -p flags in the CLI. These files can be reviewed externally. However, you cannot load them back into the GUI to resume where you left off - the application must re-run the scan to display results interactively.
Yes. Use -C <filename> for compact JSON or -p <filename> for pretty-printed JSON in the CLI. In the GUI, enable "Save also as JSON" in settings and use the Save button. The JSON format contains file paths, sizes, modification dates, and hashes (for duplicate files).
Czkawka uses hashes only (size + prehash + full hash pipeline) - no byte-by-byte comparison. This is reliable: candidates are first grouped by exact file size, and only files of the same size are ever compared by hash, so the hash space each comparison draws from is tiny. A collision would require two different files of the identical size to also produce the same full hash, which in practice never happens with the default Blake3 (a cryptographic hash). A byte-by-byte pass would only confirm what the hashes already establish, while being much slower, so it is intentionally not done.
The default hash algorithm is Blake3 (very fast, cryptographically strong). The other two options are CRC32 (a fast checksum, not cryptographic) and XXH3 (xxHash, very fast, not cryptographic). There is no SHA-256/SHA-512 option. For deduplication any of the three is fine in practice; Blake3 is the recommended default because it combines high speed with cryptographic-grade collision resistance.
Two files with different names but identical content (same size and same hash) are reported as duplicates. The filename is not part of the duplicate comparison when using the "Hash" check method. If you want to find duplicates by name only, use the "Name" check method instead.