![]() |
Re: FileDup - identische Dateien in einem Ordner suchen
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 |
Re: FileDup - identische Dateien in einem Ordner suchen
moin hagen,
Zitat:
Zitat:
da alle Anweisungen in jedem Fall ausgeführt werden. Zitat:
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) |
Re: FileDup - identische Dateien in einem Ordner suchen
Zitat:
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 |
Re: FileDup - identische Dateien in einem Ordner suchen
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? |
Re: FileDup - identische Dateien in einem Ordner suchen
schönes Programm, aber ich hätte es gerne rekursiv :-)
|
Re: FileDup - identische Dateien in einem Ordner suchen
Zitat:
btw: Der Scannvorgang kann auch noch nicht abgebrochen werden. Programm mit Source im ersten Beitrag... |
Re: FileDup - identische Dateien auf einem Laufwerk suchen
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:
2. Dann vielleicht noch eine automatische Loeschfunktion fuer die doppelten Dateien.
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; 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* |
Re: FileDup - identische Dateien auf einem Laufwerk suchen
Liste der Anhänge anzeigen (Anzahl: 1)
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:
- 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 |
Re: FileDup - identische Dateien auf einem Laufwerk suchen
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. ;-) |
Re: FileDup - identische Dateien auf einem Laufwerk suchen
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 ^^ |
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:04 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz