Programme zum Finden von Duplikatsdateien

[Wackelkarton]

Hallo,

welches Programm verwendet ihr zum Finden von Duplikatsdateien unter Linux? Und warum habt ihr Euch für das Programm entschieden oder welche Vor- und Nachteile sehr ihr?
Es interessieren mich v.a. FOSS-Produkte.

 

[K-551]

Anti-Twin

 

[Wackelkarton]

Ich meinte für Linux

 

[dernettehans]

Windows:

SearchMyFiles

Linux:

sudo apt-get install fdupes

fdupes -r /pfad/zum/verzeichnis

 

[K-551]

Ich meinte für Linux

sorry, übersehen

 

[AlphaKaninchen]

Ich nutze sha265sum, diff und co also die Linux Standard Tools.

 

[ququ]

Czkawka

https://github.com/qarmin/czkawka

 

[Krik]

Ich nutze Czkawka (polnisch für Schluckauf), da es nicht nur Duplikate sondern auch ähnliche Bilder und Videos finden kann. Gibt es mindestens als Flathub und eventuell auch per Paketmanager für deine Distro.
Auf der Github-Seite sind auch ein paar Alternativen verlinkt.

Edit: D'oh, da war einer schneller.

 

[HeavensBlade]

Beyond compare für Windows

 

[Powl_0]

Beyond compare für Windows

Ich meinte für Linux

Unterforum: Linux

 

[JumpingCat]

Hatten wir nicht vor ein paar Tagen fast genau die gleiche Frage mit den gleichen Antworten? 😁

 

[Yaakoss]

Ich nutze gerne für sowas rmlint

 

[foofoobar]

Hier ein Einzeiler mit Hashberechnung auf mehreren Threads: (Um seine HW auch mal auszulasten :-)

find . -type f -print0 | xargs -P 50 -n 20 -0 sha256sum | awk '{ if (list[$1]) { print list[$1]; print $0 } else { list[$1] = $0 } }' | sort -u | awk ' { if (last != $1) { print "------" } last = $1; print }' | less

Tuneables:
-P von xargs gibt an wieviele maximal Hashjobs gleichzeitig laufen
-n von xargs wieviele Files maximal pro Hashjob gerechnet werden

 

[andy_m4]

Hier ein Einzeiler mit Hashberechnung auf mehreren Threads: (Um seine HW auch mal auszulasten :-)

Naja. Parallelität gut und schön. Aber wenn man das schon aus Performancegründen macht, wirft man sha256sum natürlich nur beim Vergleich mehrerer gleich großer Dateien an.

 

[Evil E-Lex]

Ich würde einen Schritt weitergehen und sagen aus Performancegrünen nutzt man sha256sum am besten gar nicht. Viel zu langsam. Eine zeitgemäße Alternative ist BLAKE3. Wenn es nur um Dateien geht, die man selbst jederzeit unter Kontrolle hat, kann man auch problemlos das klassische MD5 verwenden, da die bestehenden Probleme hier nicht ins Gewicht fallen.

 

[foofoobar]

Naja. Parallelität gut und schön. Aber wenn man das schon aus Performancegründen macht, wirft man sha256sum natürlich nur beim Vergleich mehrerer gleich großer Dateien an.

War ne schnelle Fingerübung, allerdings sieht das für mein $HOME so aus:

$ find . -type f -printf '%s %p\n' | sort -n -k1 | awk ' { if (last == $1) { print llast; print } last = $1; llast = $0 }' | sort -u | wc -l
374050
$ find . -type f -printf '%s %p\n' | wc -l
395510
$ python3 -c "print(374050.0/395510)"
0.9457409420747895
$

Die Ersparnis für viele kleine Files ist so lala, da die Wahrscheinlichkeit von gleich großen Files ist bei kleinen Files einfach größer.
Und damit man den xargs mit "-0" nutzen kann (wegen Spaces in Filenamen) wird es noch wurstiger:

find . -type f -printf '%s %p\n' | sort -n -k1 | awk ' { if (last == $1) { print llast; print } last = $1; llast = $0 }' | sort -u | awk 'BEGIN {ORS="\0"} { gsub ("^[0-9]* ", ""); print }' | less

Oft ist es einfach schneller sich auf der Cmdline schnell was selber zu bauen als nach vermeintlich passenden fertigen Tools zu suchen, die dann aber irgendwas anders machen als man es gerade braucht, selbst wenn das Q&D Zeug was man in die Cmdline getippt nicht optimal optimiert ist.

Für die klassischen privaten Sicherheitskopien einer DVD-Sammlung ist die Größenverteilung typischerweise anders.
Mal wieder ein klassischer Fall von "It depends" :-)

Ergänzung (21. Oktober 2024)

Ich würde einen Schritt weitergehen und sagen aus Performancegrünen nutzt man sha256sum am besten gar nicht. Viel zu langsam. Eine zeitgemäße Alternative ist BLAKE3. Wenn es nur um Dateien geht, die man selbst jederzeit unter Kontrolle hat, kann man auch problemlos das klassische MD5 verwenden, da die bestehenden Probleme hier nicht ins Gewicht fallen.

Seitdem sha* als Hardware auf modernen CPUs implementiert ist, mache ich mir darum keinen Kopf mehr.

$ time openssl md5 bar
MD5(bar)= 0ca3e7767bf996a808f07c05c8e2e1af

real    0m1,058s
user    0m0,971s
sys    0m0,087s
$ time openssl blake2s256 bar
BLAKE2S-256(bar)= 3abe42a0e09f03e05c607c7527235f1487eb48b2128a822e79cf105d79c99a40

real    0m1,434s
user    0m1,331s
sys    0m0,103s
$ time openssl sha256 bar
SHA2-256(bar)= b33523da041125ffd537336fdb172a838538f8939809ccb86d2937b7e29d713b

real    0m0,523s
user    0m0,455s
sys    0m0,068s
$ time md5sum bar
0ca3e7767bf996a808f07c05c8e2e1af  bar

real    0m1,029s
user    0m0,967s
sys    0m0,061s
$ time sha256sum bar
b33523da041125ffd537336fdb172a838538f8939809ccb86d2937b7e29d713b  bar

real    0m0,491s
user    0m0,435s
sys    0m0,055s
$

Mein openssl hat kein blake mit "3". Was nimmt man dafür?
Oder zeig mal Ergebnisse von deinem Hobel.

 

[foofoobar]

nix

 

[Evil E-Lex]

Seitdem sha* als Hardware auf modernen CPUs implementiert ist, mache ich mir darum keinen Kopf mehr.

Dann hash mal große Dateien und die wirst den Unterschied sehr deutlich feststellen.
Hier:

❯ time md5sum 10GiBFile
85b226b5337784ef3ce2e3ae2d05abe5  10GiBFile
md5sum 10GiBFile  11,45s user 2,46s system 99% cpu 14,045 total
❯ time sha256sum 10GiBFile
bedce0d2f14a3409c4fa9e08522b7440066dff1bc4590af481ac705cf976197a  10GiBFile
sha256sum 10GiBFile  17,70s user 2,26s system 99% cpu 20,056 total
❯ time b3sum 10GiBFile
de8e1cc7b966a8b5917682015a62baf41b82bc864f577b7eedc193c31cb11725  10GiBFile
b3sum 10GiBFile  5,32s user 16,99s system 224% cpu 9,912 total

Mein openssl hat kein blake mit "3". Was nimmt man dafür?

Die Referenzimplementierung: https://github.com/BLAKE3-team/BLAKE3
Bei Arch ist es das Paket b3sum.

 

[foofoobar]

❯ time md5sum 10GiBFile
85b226b5337784ef3ce2e3ae2d05abe5  10GiBFile
md5sum 10GiBFile  11,45s user 2,46s system 99% cpu 14,045 total
❯ time sha256sum 10GiBFile
bedce0d2f14a3409c4fa9e08522b7440066dff1bc4590af481ac705cf976197a  10GiBFile
sha256sum 10GiBFile  17,70s user 2,26s system 99% cpu 20,056 total
❯ time b3sum 10GiBFile
de8e1cc7b966a8b5917682015a62baf41b82bc864f577b7eedc193c31cb11725  10GiBFile
b3sum 10GiBFile  5,32s user 16,99s system 224% cpu 9,912 total

Das ist eine Kiste mit oder ohne sha* in HW? (Just4shure)
Warum wird da überall soviel System-Zeit verbraucht?
Und wo kommt >100% cpu time bei b3sum her?

Die Referenzimplementierung: https://github.com/BLAKE3-team/BLAKE3
Bei Arch ist es das Paket b3sum.

Schau ich mir nachher mal an.
Aber wenn ich das in Relation zu den Zeiten von md5 setze kommt man wohl bei den Zeiten von b3sum vergleichbar mit sha* mit HW dafür raus?

 

[Evil E-Lex]

Das ist eine Kiste mit oder ohne sha* in HW? (Just4shure)

Ich denke mit. Ist ein Core i7-10700.

Warum wird da überall soviel System-Zeit verbraucht?
Und wo kommt >100% cpu time bei b3sum her?

Keine Ahnung. Mich interessiert nur "was hinten rauskommt".

Das BLAKE3-Paper schreibt in der Einleitung folgendes:

We present BLAKE3, an evolution of the BLAKE2 cryptographic hash that is both faster
and also more consistently fast across different platforms and input sizes. BLAKE3
supports an unbounded degree of parallelism, using a tree structure that scales up
to any number of SIMD lanes and CPU cores. On Intel Cascade Lake-SP, peak
single-threaded throughput is 4× that of BLAKE2b, 8× that of SHA- 512, and 12×
that of SHA - 256, and it can scale further using multiple threads. BLAKE3 is also
efficient on smaller architectures: throughput on a 32-bit ARM1176 core is 1.3× that
of SHA- 256 and 3× that of BLAKE2b and SHA-512.

Fairerweise muss ich aber anmerken, dass es bei BLAKE3 sehr auf die Implementierung ankommt. Die Entwickler von TeraCopy haben das Kunststück fertiggebracht, BLAKE3 deutlich langsamer als MD5 zu machen, aber immer noch deutlich schneller als SHA256.