sdupes - fast file duplicate detection
at this point in time, many existing file duplication detectors are slow or overengineered. sdupes implements a kind of minimal duplicate file finder that does just one thing.
usage: sdupes description read file paths from standard input and display excess duplicate files, each set sorted by creation time ascending. considers only regular files. files are duplicate if they have the same size, center portion and murmur3 hash options --help, -h display this help text --cluster, -c display all duplicate paths, two newlines between each set --null, -n for results: use the null byte as path delimiter, two null bytes between each set
note that given the requirements size/center-portion/hash there is a high probability that matching files are duplicate, but not absolute certainty. it is unlikely that files are found that are not duplicates but only a costly byte-by-byte comparison could give maximum confidence
- c 2011 standard library (for example glibc)
- posix 2008 features (linux, freebsd)
- 64 bit processor
- for the provided compile script: shell, gcc
- optional: sph-sc and clang-format to edit the sc code
this should build the file
temp/sdupes, which is the final executable and can be taken and copied anywhere, for example into
/usr/bin (as root), then you have sdupes as a command on the command-line.
find /home/myuser/directory-with-1000s-of-large-files | sdupes
lists excess duplicate files. the first file is always left out of each set except when --cluster is used. if nothing is found, nothing is displayed.
it can be used with xargs to remove the files
find | sdupes | xargs -n 1 -d \\n rm
- all input path names are loaded into memory. in my test, memory usage stayed under 1GB for a 31200 files music library
- an original, tiny hashtable and array implementation from sph-sc-lib is used
- currently written in c via sc, which just maps scheme-like expressions to c
- optionally compare the md5 sum for extra confidence. a nice md5 implementation can be found here
- optional byte-by-byte comparison. but that would be resource intensive because large files cant be kept in memory. for each comparison, each two relevant files have to be fully read again and again