Filedup 1.0.7.0 - Identische Dateien finden

[bigg]

Kann gelöscht werden.

[bigg]

@Luckie:
Jupp, da hast du recht.


Update 2:

Um das Programm noch ein wenig zu beschleunigen, überprüfe ich die ersten > 2 KB
gleich großer Dateien. Sind dort Checksummen gleich, wird ein kompletter Scan durchgeführt und weiter gefiltert.

Grau markierte Dateien sind identisch/ doppelt.
Grün markierte Dateien haben einen identischen Kopf.
Blau markierte Dateien sind gleich groß.

[SubData]

Ich würde vorschlagen bei sehr großen Dateien die ersten 5 KB, die letzten 5 KB und 2 - 3 mal zwischendurch 5 KB zu scannen... Wenn die gleich seien sollten, dann kannste wirklich die ganze Datei scannen...

Edit: So ne kleine Idee hätte noch... Bau doch ne Funktion ein, die die ganze Festplatte scannt (Kann meinetwegen auch 3 Stunden dauern...)

[bigg]

Zitat:

Edit: So ne kleine Idee hätte noch... Bau doch ne Funktion ein, die die ganze Festplatte scannt (Kann meinetwegen auch 3 Stunden dauern...)

Das hatte ich eigentlich nicht vor :>

[Olli]

Zitat von SubData:

Bau doch ne Funktion ein, die die ganze Festplatte scannt (Kann meinetwegen auch 3 Stunden dauern...)

Alternativ DFHL. Mahlzeit

[bigg]

Zitat:

Alternativ DFHL. Mahlzeit

Benötigt aber NTFS.

[SubData]

Naja NTFS ist nicht das Problem, aber ich wollte eigentlich keine Hard Links haben, sondern die doppelten Dateien aufgelistet um diese dann ggf. löschen zu können :>

[Olli]

Zitat von SubData:

Naja NTFS ist nicht das Problem, aber ich wollte eigentlich keine Hard Links haben, sondern die doppelten Dateien aufgelistet um diese dann ggf. löschen zu können :>

DFHL kann beides ... Hardlinks gehen zwar nur auf NTFS, auflisten sollte aber beliebig gehen.

@bigg: Gut bemerkt.

[bigg]

Da bin ich noch am rum filtern, aber sowas wird es natürlich geben.

[negaH]

@Bigg:

Zitat:

Um das Programm noch ein wenig zu beschleunigen, überprüfe ich die ersten > 2 KB
gleich großer Dateien. Sind dort Checksummen gleich, wird ein kompletter Scan durchgeführt und weiter gefiltert.

Diesen Ansatz kannst du weiter ausbauen. D.J.Bernstein, ein genialer Mathematiker und Analyst, benutzt bei seinen vielen mathematischen Verfahren ein ähnliches Vergleichsverfahren.

Du vergleichst immer Stückchenweise beide Dateien solange sie gleich sind. Die Stückchen sind erst zb. 1024 Bytes groß, dann 1024*2 Bytes, dann 1024*4, 1024*8, 1024*16 usw. Bytes groß.

Wie man aber unschwer erkennen kann macht das ausschließlich nur dann Sinn wenn man viele Dateien in parallel und sehr schnell und sehr frühzeitig im Vergleich wissen möchte wieviele Dateien sich unterscheiden.
Vergleicht man aber immer sequientiell zwei dateien miteinander dann macht ein solch kurzer Vergleich absolut keinen Sinn, denn dann vergleicht man die beiden Dateien nur solange bis es einen Untrschied gibt oder eben falls sie gleich sind bis zum Ende der Dateien. Bei dieser Methode hat man den Vorteil das man die beiden Dateien nur einmalig öffnen und schließen muß, man hat also viel weniger Overhead pro Datei.

Für einen Filescanner sollte man sequientiell vorgehen und die beiden Dateien immer vollständig miteinander vergleichen bis sich der erste Unterschied findet. Dabei sollte man vom Ende zum Anfang hin die dateien binär vergleichen. Einfach weil zb. EXE/DLL's immer den gleichen Header besitzen aber meistens am Ende andere Resourcen enthalten. Oder weil WinWord Dokumente mit höherer Wahrscheinlichkeit den gleichen Kopf besitzen aber unterschiedlicher Footer. Oder weil eine ZIP Datei am Anfang die gleichen Dateien gezippt haben könnte, deren ursprüngliche Inhalte aber unterschiedliche waren und somit im Laufe der Komprimierung am Ende der ZIP Datei andere Prüfsummen rauskommen. Die Wahrscheinlichkeit das zwei Dateien sich am Ende unterscheiden ist also größer als das sie sich am Anfang unterscheiden. Programmiertechnisch ist der Vergleich von Hinten nach Vorne kein großer Aufwand, Performancetechnisch reduziert sich aber die Laufzeit auf Grund der unterschiedlichen Wahrscheinlichkeiten.

Gruß Hagen

[bigg]

moin hagen,

das ehrt mich jetzt aber .

Zitat von negah:

Einfach weil zb. EXE/DLL's immer den gleichen Header besitzen aber meistens am Ende andere Resourcen enthalten. Oder weil WinWord Dokumente mit höherer Wahrscheinlichkeit den gleichen Kopf besitzen aber unterschiedlicher Footer. Oder weil eine ZIP Datei am Anfang die gleichen Dateien gezippt haben könnte, deren ursprüngliche Inhalte aber unterschiedliche waren und somit im Laufe der Komprimierung am Ende der ZIP Datei andere Prüfsummen rauskommen. Die Wahrscheinlichkeit das zwei Dateien sich am Ende unterscheiden ist also größer als das sie sich am Anfang unterscheiden. Programmiertechnisch ist der Vergleich von Hinten nach Vorne kein großer Aufwand, Performancetechnisch reduziert sich aber die Laufzeit auf Grund der unterschiedlichen Wahrscheinlichkeiten.

Ich scanne mit absicht den Kopf, da ich so auch verwandte Dateien auffinden kann.
So könnte man auch den Dateityp ermitteln, ein sehr schoener nebeneffekt.

Aber da gebe ich dir recht, es ist wahrscheinlicher im hinteren Teil der Datei unterschiede zu entdecken.

Zitat:

Du vergleichst immer Stückchenweise beide Dateien solange sie gleich sind. Die Stückchen sind erst zb. 1024 Bytes groß, dann 1024*2 Bytes, dann 1024*4, 1024*8, 1024*16 usw. Bytes groß.

Ich könnte doch aber auch die Position in der Datei verschieben und dann meinen Puffer füllen.
So muesste ich seperat Speicher reservieren und das hatte ich eigentlich nicht vor.