Filedup 1.0.7.0 - Identische Dateien finden

[bigg]

Kann gelöscht werden.

[dizzy]

Exakt was, wo ich kurz davor war es selbst zu basteln :). Wird umgehend getestet!

\\edit:
Hm, hab ihm grad mal nen Ordner mit gut 15.000 Files vorgesetzt. Nach ein paar Minuten rödeln auf der Platte war zwar das Rödeln vorbei, aber es hatte noch 100% CPU-Last und hat noch nichts dargestellt :mrgreen:. Das blieb auch mehrere Minuten so, so dass ich's dann erstmal abgeschossen hab.
Der MD5-Algo hat noch gut Optimierungspotential. Dort sind ein ganzer Haufen Funktionsaufrufe an Funktionen mit nur 1 Zeile Code, mit ganzen 7 Parametern direkt hintereinander drin. Wenn man die alle von Hand "inlined" (mühselig - ich weiss), spart man sich eine ganze Menge an Calls und Stackoperationen. Mal sehen ob sich das Teil noch etwas aufbohren lässt.
Dass Hängen nach der Rödelei hängt vermutlich mit dem Füllen des Grids zusammen. Besser wäre es hier imho nur die Files einzutragen, die auch wirklich mehrfach vorhanden sind. (Wenn das nicht eh schon so ist.)
Mist... ich wollte grad in's Bett, und nun muss ich DOCH wieder ein wenig basteln *zwanghaftbin* :D.

Aber großes Danke für den Anstoß! Ich habs immer wieder vor mir her geschoben da mal dran zugehen. Mit einer soliden Basis machts sich doch leichter.

\\edit2:
Es ist schier entsetzlich da von Hand Inlining zu betreiben. Das ist mal eine Konzentrationsaufgabe... Was gäbe ich hierbei für Makros wie unter C++ :D
...Ich glaub ich schreib da mal nen Programm zu...

[bigg]

Hi Dizzy,

erstmal danke für deinen Test. An dem Programm habe ich gestern etwa 1 Stunde gesessen. :)
Wenn du Lust hast, könnten wir dieses Tool ja gemeinsam weiter entwickeln, ohne jeglichen Stress versteht sich.

[bigg]

Update 0 *gg*

Man, man ich finde den Aufbau richtig toll. :lol:
So ich kümmere mich jetzt mal um eine Progressbar.

[Dust Signs]

2x Kritik ;)

1.) Programm versucht zu Beginn, auf Laufwerk A: zuzugreifen -> Fehler von XP (nervend!)
2.) Programm hängt sich bei meinem Laufwerk Y: auf, obwohl da nur ein einziges File im Root ist :?

Ansonsten nicht schlecht :thumb:

Dust Signs

[toms]

Hallo,

Scheint noch ein Bug zu haben, siehe Anlage

[Dust Signs]

Zitat:

Zitat von toms

Hallo,

Scheint noch ein Bug zu haben, siehe Anlage

Wenn sie alle 0 Bytes haben... sind sie ja gleich ;) wie willst du "nix" mit "nix" vergleichen :P

Dust Signs

[bigg]

Zitat:

Wenn sie alle 0 Bytes haben... sind sie ja gleich Wink wie willst du "nix" mit "nix" vergleichen Razz

Da haste recht. :mrgreen:
Toms versucht es immer wieder.

Die anderen Sachen schau ich mir später an.

[Luckie]

Guckt mal hier: http://www.delphipraxis.net/internal...t=doublekiller

[bigg]

Zitat:

Zitat von Luckie

Guckt mal hier: http://www.delphipraxis.net/internal...t=doublekiller

Ich kenne das Projekt/ Programm nicht, ich weis aber auch nicht was du mir damit sagen möchtest?


@Dust:
Wie groß ist die Datei auf Laufwerk Y?
Da die Checksumme der Datei berechnet werden muss, dauert es bei großen Dateien auch recht lang.

[Luckie]

Nun ja, das Programm hat doch den gleichen Zweck wie deins.

[Dust Signs]

Laufwerk Y hat in etwa die Größe meines Laufwerk F - also so um die 100 GB. Seh grade, dass im Root ein CD-Image liegt. Vielleicht die Dateigröße prüfen und nicht gleich scannen ;)

Dust Signs

[bigg]

Zitat:

Nun ja, das Programm hat doch den gleichen Zweck wie deins.

Das Programm konnte ich nicht finden, lediglich einen Anhang von Hagen und Hansa.


@Dust: Jupp. Kommt noch.

[Daniel G]

Is' jetz nichts großartiges, aber...

Könntest du vielleicht die Farbe auswählbar machen, mit der doppelte Dateien gekennzeichnet werden? Also, nicht das ich etwas gegen pink hätte aber irgendwie gefällt mir die Farbe nicht...

[bigg]

Zitat:

Zitat von Daniel G

Is' jetz nichts großartiges, aber...

Könntest du vielleicht die Farbe auswählbar machen, mit der doppelte Dateien gekennzeichnet werden? Also, nicht das ich etwas gegen pink hätte aber irgendwie gefällt mir die Farbe nicht...

Das könnte schwierig werden, welche Farbe möchtest du denn? Baby-Blau :mrgreen:
Ja klar. :zwinker:

[jensw_2000]

Scheint noch eine Bug zu haben ..
Gleiche Dateien werden nicht erkannt ...

Kontockeck[1].dll ist eine Kopie von Kontockeck.dll

EDIT-----------------------------------------------

Oh nein, Sorry :oops:

Das eine Kompilat war 2 Minuten älter ... :wall:

[Daniel G]

Zitat:

Zitat von bigg

Zitat:

Zitat von Daniel G

Is' jetz nichts großartiges, aber...

Könntest du vielleicht die Farbe auswählbar machen, mit der doppelte Dateien gekennzeichnet werden? Also, nicht das ich etwas gegen pink hätte aber irgendwie gefällt mir die Farbe nicht...

Das könnte schwierig werden, welche Farbe möchtest du denn? Baby-Blau :mrgreen:

Hast du das da? :stupid:

//Edit: :wall: Das Ding is' doch Open-Source.. Hätt' ich doch sogar selbst machen können....

[bigg]

Zitat:

/Edit: ouch! Das Ding is' doch Open-Source.. Hätt' ich doch sogar selbst machen können....

Zu spät, schon drin. :stupid:

[KLS]

Mal als Tipp:

Warum scannst du alle Dateien mit dem MD5 Verfahren? (das dauert recht lange)
Du brauchst doch nur gleich große Dateien scannen, der rest ist ja eh unterschiedlich.

[Luckie]

Ähm, dein letztes Post bezieht sich wohl weniger auf die Vorstellung deines Programmes oder? Deswegen mach bitte einen entsprechenden Thread im Forum auf. Das gehört nicht hier her.

[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:

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:

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. :stupid:

[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 :mrgreen:.

Zitat:

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.

[negaH]

Mein Vorschlag sollte dir eigentlich nur bewusst machen das ein "Stückchenhafter" Vergleich zweier Dateien in deinem Szenario nur überflüssige Rechenleistung kosten wird.

Die Methodik von D.J.Bernstein lohnt sich nur wenn bei jedem größer werdenden Vergleich die Komplexität eben nicht linear proportional ansteigt, sondern zb. expotentiell oder qudratisch, oder man mehrere Berechnungen über viele Daten in parallel durchführen kann. Beides trifft aber auf dein Problem nicht zu, und ergo ist es am besten beim binären Vergleich der Dateien die Dateien bis zum Ende hin in einem Rutsch zu vergleichen.


Du machst es doch nun so:

1.) vergleiche Dateigrößen, wenn ungleich Exit
2.) vergleiche beide Hash Prüfsummen, wenn ungleich Exit
3.) vergleiche die ersten 2048 Bytes, wenn ungleich Exit
4.) vergleiche die restlichen X Bytes bis zum Ende der Datei

Schritt 3.) ist absolut überflüssig und macht nur Sinn wenn entweder

a) zwischen Schritt 3.) und 4.) noch andere Dateien in parallel verglichen werden
b) die Komplexität des Vergleichsalgorithmus nicht linear proportional mit jedem zu vergleichenden Byte steigen würde. Sprich zb. bei jedem Byte verdoppelt sich die Laufzeit des Vergleichsalgos., die Komplexität würde also quadratisch mit jedem zu vergleichenden Byte ansteigen.

Gruß Hagen

[bigg]

moin hagen,

Zitat:

Mein Vorschlag sollte dir eigentlich nur bewusst machen das ein "Stückchenhafter" Vergleich zweier Dateien in deinem Szenario nur überflüssige Rechenleistung kosten wird.

Was könnte daran Rechenleistung kosten?

Zitat:

3.) vergleiche die ersten 2048 Bytes, wenn ungleich Exit

Exit muss man in allen Punkten gestrichen werden,
da alle Anweisungen in jedem Fall ausgeführt werden.

Zitat:

ergo ist es am besten beim binären Vergleich der Dateien die Dateien bis zum Ende hin in einem Rutsch zu vergleichen.

Ja, aber in welchen Fällen sind Dateien wirklich nahezu identisch?
Alle Dateien komplett zu berechnen, würde in vielen Fällen einfach zuviel Zeit kosten.

Optimal ist es noch nicht, aber doch schnell genung, um sich sich mal eben einen Überblick zu verschaffen, welche Dateien eventuell gleich sind. (Das ich bei kleineren Dateien doppelt rechne, weis ich)

[negaH]

Zitat:

Was könnte daran Rechenleistung kosten?

Nochmal. Ich gehe davon aus das Step 3.) und 4.) separate Funktionen sind. Beide Funktionen müssen also die Dateien öffnen, Daten einlesen, diese vergleichen und Dateien wieder schließen.

Falls nun Step 4.) immer ausgeführt wird wenn Step 3.) sagt das die ersten 2048 Bytes gleich sind dann würde man also 1 mal zuviel Dateien öffen, Daten einlesen, Daten vergleichen und Dateien wieder schließen. Denn exakt diese ersten 2048 Bytes würden auch beim Step 4.) sowieso eingelesen und verglichen.

Es würde also ausreichen Step 3.) zu eliminieren und gleich im Step 4.) Bufferweise mit 2048 Bytes Größe die Dateien zu vergleichen. Sollte beim ersten 2048 Bytes Buffer keine Übereinstimmung existieren so würde auch Step 4.) die identische Laufzeit zu Step 3.) haben. Sollte aber diese 2048 Bytes gleich sein so würde man mit Step 3.) zusammen also die Dateien doppelt Öffnen, vergleichen,und Schließen.

Die Gesamtperformance mit dem Step 3.) ist also schlechter als ohne diesen und real an zusätzlicher Information bringen tut er nichts da Step 4.) diesen eh funktionell ersetzen wird.

Wie oben angesprochen gibt es nur Ausnahme-Gründe warum man Step 3.) tatsächlich durchführen sollte. Entweder der Bytevergleich der Dateien ist von der Komplexität nicht linear, was aber nicht der Fall hier ist. Oder aber zwischen dem Step 3.) und 4.) gibt es noch andere Schritte, wie zb. eine Progressbar die in Multithreaded Vergleichen eine Anzeige der möglicherweise gleichen Dateien updaten möchte, also quasi Parallele Abarbeitung der Dateivergleiche. Abver auch das machst du nicht, ergo: Step 3.) bringt rein garnichts ausser das er Zeit kostet.

Gruß Hagen

[bigg]

moin hagen,

exakt, Punkt 3 würde in diesem Fall nichts bringen, wenn man Punkt 4.
dahin gehend optimiert, so wie du es angesprochen hast. Im schlechtesten
Fall würden die Funktionen einmal zuviel aufgerufen, so wie sie momentan vorliegen.


Nun müsste sich nur noch jemand bereit erklären, das ganze umzusetzen,
huhu dizzy wo bist du?

[yankee]

schönes Programm, aber ich hätte es gerne rekursiv :-)

[bigg]

Zitat:

Zitat von yankee

schönes Programm, aber ich hätte es gerne rekursiv :-)

Ich habe es jetzt "halbwegs" brauchbar rekursiv umgesetzt. Würd mich freuen, wenn du mal drüber scannst.
btw: Der Scannvorgang kann auch noch nicht abgebrochen werden. Programm mit Source im ersten Beitrag...

[yankee]

cool...
Noch ein paar Vorschlaege:
1. Ini statt Registry. zumindets ich kann das nicht haben, wenn jedes Programm da Werte in die Registry schreibt. Die wird schliesslich die ganze Zeit im Speicher gehalten. Wo kommen wir da denn hin, wenn das jedes Programm macht...? :-D
Also ich habe mal eben ungetestet deine Speicher und Ladefunktionen auf ini umgeschreiben:

Delphi-Quellcode:

uses IniFiles;

procedure TMainForm.SaveSettings;
var ini: TIniFile;
    WsState: Integer;
begin
  ini :=TIniFile.Create(ExtractFilePath(Application.ExeName)+'conf.ini');
  try
      WsState := GetWindowState;
      if WsState = 1 then Self.WindowState := wsNormal;
      ini.WriteInteger('windowpos','Width', Self.Width);
      ini.WriteInteger('windowpos','Height', Self.Height);
      ini.WriteInteger('windowpos','Left', Self.Left);
      ini.WriteInteger('windowpos','Top', Self.Top);
      ini.WriteInteger('windowpos','State', WsState);
  end;
  finally
      ini.Free;
  end;
end;

procedure TMainForm.LoadSettings;
var ini: TIniFile;
    WsState: Integer;
begin
  ini :=TIniFile.Create(ExtractFilePath(Application.ExeName)+'conf.ini');
  try
      Self.Width :=ini.ReadInteger('windowpos','Width', Self.Width);
      Self.Height :=ini.ReadInteger('windowpos','Height', Self.Height);
      Self.Left :=ini.ReadInteger('windowpos','Left', Self.Left);
      Self.Left :=ini.ReadInteger('windowpos','Top', Self.Top);
      SetWindowState(ini.ReadInteger('windowpos','State', GetWindowState()));
  end;
  finally
      ini.Free;
  end;
end;

2. Dann vielleicht noch eine automatische Loeschfunktion fuer die doppelten Dateien.
Mir faellt es ein bisschen schwer deinen qt zu editieren, da ich diese ganzen Designpakte oder was das ist nicht habe...
Was fuer den Anfang schon gut ist, waere, wenn man in deiner Tabelle eine Datei einfach markieren kann und dann auf der Tastatur Entfernen druecken kann um die ausgewaehlte Datei von der HDD zu schmeißen. Automatisch loeschen waere aber besser...

3. Eine Legende fuer die Farben. Ein kleines Fenster im Hilfemenue oder so reicht ja...

Das mal so fuer "jetzt schnell" *gg*

[himitsu]

Win98 SE:
Die Oberfläche sieht sch*** aus (die Memüleiste)

und funktionieren tut das Programm och nicht, obwohl es fest beheupte es würde es.

Es meint es würde arbeiten.

Zitat:

• Suche Dateien...
• Gefundene Dateien: 0
• Fertig!

Dafür braucht es knapp 10 Sekunden und dabei greift es nachweislich nicht auf den Datenträger zu.

- ein USB-Stick (das Lämpchen blinkt nicht)
- USB 1.1 und über 60 MB ... das dauert niemals nur 10 Sekunden
- es sind mit Sicherheit Dateien doppelt
- und keine Fehlermeldung, oder so

[bigg]

Hi himitsu,

was funktioniert nicht?
Die Dateisuche auf einem USB-Stick unter Windows 98 Second Edition?
Ich habe die First Edition, da könnte ich heut mal nen bissl frickeln.

Ich habe auch einen USB-Stick mit der Version 1.1, meiner blinkt allerdings, wenn er an ist.
Könnte es vielleicht sein, das der Stick gar kein Strom bekommen hat, du aber den Wechseldatenträger im Dialog ausgewählt hast, bevor er aus ging/ getrennt wurde? Wenn dem so ist, wäre es doch kein Fehler, oder?
Dann müßte ich allerdings überprüfen, ob das Laufwerk verfügbar ist und gegebenfalls eine Fehlermeldung implementieren.

Nicht, das du mich veräppeln willst. :stupid:

PS: Die Win9x Reihe habe ich noch nicht getestet, leglich Windows 2000 mit SP4 sowie Windows XP mit SP2.
Und zum Menü kann ich nur sagen, ja das kommt davon wenn man noch selbst Hand anlegt und selbst frickelt, aber ich kümmere mich darum. ;-)

[himitsu]

Ich hab ja Zugriff auf den Stick und die LED ist auch an (außerdem ist FileDup da mit drauf, also wird er wohl auch an sein :roll: )

Ich klick halt auf Datei > Durchsuchen..., dann geh das Statusfenster auf und er sucht (angeblich), aber nichts passiert wirklich.

(hab hier kein Delphi drauf, sonst hätte ich schonmal versucht zu debuggen ._.)

Nochmal zum Menü ... wie wäre es, wenn du bei den "wenigen" Einträgen keine Untermenüs erstellst?
also nur "Durchsuchen", "Beenden" und "Version", dann bräuchte man ein paar Klicks weniger ^^