JDUPES(1) | General Commands Manual | JDUPES(1) |
jdupes - finds and performs actions upon duplicate files
jdupes [ options ] DIRECTORIES ...
Searches the given path(s) for duplicate files. Such files are found by comparing file sizes, then partial and full file hashes, followed by a byte-by-byte comparison. The default behavior with no other "action options" specified (delete, summarize, link, dedupe, etc.) is to print sets of matching files.
jdupes -X filter[:value][size_suffix]
Some filters take no value or multiple values. Filters that can take a numeric option generally support the size multipliers K/M/G/T/P/E with or without an added iB or B. Multipliers are binary-style unless the -B suffix is used, which will use decimal multipliers. For example, 16k or 16kib = 16384; 16kb = 16000. Multipliers are case-insensitive.
Filters have cumulative effects: jdupes -X size+:99 -X size-:101 will cause only files of exactly 100 bytes in size to be included.
Extension matching is case-insensitive. Path substring matching is case-sensitive.
Supported filters are:
A set of arrows are used in hard linking to show what action was taken on each link candidate. These arrows are as follows:
Duplicate files are listed together in groups with each file displayed on a separate line. The groups are then separated from each other by blank lines.
Using -1 or --one-file-system prevents matches that cross filesystems, but a more relaxed form of this option may be added that allows cross-matching for all filesystems that each parameter is present on.
When using -d or --delete, care should be taken to insure against accidental data loss.
-Z or --soft-abort used to be --hardabort in jdupes prior to v1.5 and had the opposite behavior. Defaulting to taking action on abort is probably not what most users would expect. The decision to invert rather than reassign to a different option was made because this feature was still fairly new at the time of the change.
The -O or --param-order option allows the user greater control over what appears in the first position of a match set, specifically for keeping the -N option from deleting all but one file in a set in a seemingly random way. All directories specified on the command line will be used as the sorting order of result sets first, followed by the sorting algorithm set by the -o or --order option. This means that the order of all match pairs for a single directory specification will retain the old sorting behavior even if this option is specified.
When used together with options -s or --symlink, a user could accidentally preserve a symlink while deleting the file it points to.
The -Q or --quick option only reads each file once, hashes it, and performs comparisons based solely on the hashes. There is a small but significant risk of a hash collision which is the purpose of the failsafe byte-for-byte comparison that this option explicitly bypasses. Do not use it on ANY data set for which any amount of data loss is unacceptable. This option is not included in the help text for the program due to its risky nature. You have been warned!
The -T or --partial-only option produces results based on a hash of the first block of file data in each file, ignoring everything else in the file. Partial hash checks have always been an important exclusion step in the jdupes algorithm, usually hashing the first 4096 bytes of data and allowing files that are different at the start to be rejected early. In certain scenarios it may be a useful heuristic for a user to see that a set of files has the same size and the same starting data, even if the remaining data does not match; one example of this would be comparing files with data blocks that are damaged or missing such as an incomplete file transfer or checking a data recovery against known-good copies to see what damaged data can be deleted in favor of restoring the known-good copy. This option is meant to be used with informational actions and can result in EXTREME DATA LOSS if used with options that delete files, create hard links, or perform other destructive actions on data based on the matching output. Because of the potential for massive data destruction, this option MUST BE SPECIFIED TWICE to take effect and will error out if it is only specified once.
Using the -C or --chunk-size option to override I/O chunk size can increase performance on rotating storage media by reducing "head thrashing," reading larger amounts of data sequentially from each file. This tunable size can have bad side effects; the default size maximizes algorithmic performance without regard to the I/O characteristics of any given device and uses a modest amount of memory, but other values may greatly increase memory usage or incur a lot more system call overhead. Try several different values to see how they affect performance for your hardware and data set. This option does not affect match results in any way, so even if it slows down the file matching process it will not hurt anything.
The -y or --hash-db feature creates and maintains a text file with a list of file paths, hashes, and other metadata that enables jdupes to "remember" file data across runs. Specifying a period '.' as the database file name will use a name of "jdupes_hashdb.txt" instead; this alias makes it easy to use the hash database feature without typing a descriptive name each time. THIS FEATURE IS CURRENTLY UNDER DEVELOPMENT AND HAS MANY QUIRKS. USE IT AT YOUR OWN RISK. In particular, one of the biggest problems with this feature is that it stores every path exactly as specified on the command line; if any paths are passed into jdupes on a subsequent run with a different prefix then they will not be recognized and they will be treated as totally different files. For example, running jdupes -y . foo/ is not the same as jdupes -y . ./foo nor the same as (from a sibling directory) jdupes -y ../foo. You must run jdupes from the same working directory and with the same path specifications to take advantage of the hash database feature. When used correctly, a fully populated hash database can reduce subsequent runs with hundreds of thousands of files that normally take a very long time to run down to the directory scanning time plus a couple of seconds. If the directory data is already in the OS disk cache, this can make subsequent runs with over 100K files finish in under one second.
Send bug reports and feature requests to jody@jodybruchon.com, or for general information and help, visit www.jdupes.com
If you find this software useful, please consider financially supporting its development through the author's home page:
https://www.jodybruchon.com/
jdupes is created and maintained by Jody Bruchon <jody@jodybruchon.com> and was forked from fdupes 1.51 by Adrian Lopez <adrian2@caribe.net>
MIT License
Copyright (c) 2015-2023 Jody Lee Bruchon <jody@jodybruchon.com>
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.