SearchSameFiles v2.0 (SSF)

[himitsu]

Beiträge zur Version 2 ab hier:
http://www.delphipraxis.net/internal...=663073#663073

aktueller Download immer noch im ersten (diesem) Beitrag


************************************************** *****************


Ich wollte nur mal ein kleines Programmchen vorstellen und nachfragen ob es für'n Anfang i.O. ist?
Außerdem würde ich gern wissen, ob sowas überhaut noch Jemand gebrauchen kann und ob's sich auch lohnt, wenn ich das noch weiterentwickeln würde.
>> Arbeitsspeicher, Geschwindigkeit/Durchsatz(KB/s) und was sonst noch wichig ist

Es vergleicht alle Dateien in dem angegebenen Verzeichnis und seiner Unterverzeichnisse miteinander und gibt am Ende eine Liste mit allen Dateien aus, welche den selben Inhalt haben.


Seit aber nicht all zu hart zu mir ... dieses ist nur so'n kleines Nebenprojekt und ich hatte halt nicht gerade viel Arbeitszeit reingestecken können.
Und das an der Optik/Bediehnung unbedingt noch einiges gemacht werden muß, ist mir bekannt.

Und dafür, daß es Funktionen meines "neuen" UCC verwendet und derzeit das 2. größere (NichtDemo)Programm ist, welches darauf aufbaut, lauffähig ist und anscheinend ohne Probleme läuft, bin ich erstmal damit zufrieden und die Hoffnung der baldigen UCC-Veröffentlichung steigt immer mehr in mir auf (na ja, 2 winzige Kleinigkeiten wurmen mich immernoch).


Intern basiert es ja auf meinem UCC und sonst ist da noch nicht so viel drin.

Zitat von SourceCode Counter von JLSoft Software:

SearchSameFiles.dpr 12 Zeilen 247 Byte 213 Zeichen
SearchSameFilesU.pas 220 Zeilen 7.9 KB 6190 Zeichen
[add]hat jetzt'n paar Zeilchen mehr ... sowar passiert halt, wenn man etwas aufrüstet -.-''

Verglichen werden die Dateien, aus Performancegründen, per CRC32.
Einen vorzeitigen Abbruch bekommt man über das nette [X].


Ach ja: im Moment werden weder Registry, noch irgendwelche anderen Einträge/Veränderungen in/an eurem System vorgenommen.
Es gibt also nur diese "kleine" EXE, welche wirklich nur nach gleichen Dateien sucht ^^



PS: ich hab durch dieses Programm gelernt, wie man die Speicherverwaltung des Heap aushebeln kann.
Durch die staren und nicht verschiebbargen Blöcke hatte ich auf Grund der 2 verwendeten Haupt-Arrays und mit lediglich 55.000 Vergleichsdateien ein massiges Speicherproblem bekommen.
Es gab also nach einer Weile einen kleine Exception (Out of Memory) ... na ja, über 300 MB RAM+Pagefile war wohl 'n bissl zuviel -.-''
Aber nach 'ner kleinen Optimierung bei den Arrays und Strings konnte einiges an Speicher eingesparrt werden (bei meinem Testlauf sind es jetzt nur noch rund 5 MB).
Und ein optimierteres SetLength brachte auch noch etwas Tempo mit rein.


Zum Schluß bleibt dann nur noch eine Überlegung:
Soll ich den Quellcode für dieses Programm ebenfalls veröffentlichen und in Ruhe zusehen, ob nicht zufällig jemand etwas mehr Zeit investieren kann und daraus vielleicht doch noch was großartiges macht?

[himitsu]

Ich hab mal einige Kleinigkeiten verändert.

Die Wichtigsten sind:

• 0 Byte-Dateien werden jetzt ignoriert
• die Hauptsuchprozedur wurde um 'ne Fehlerbehandlung erweitert
  (mir ist aufgefallen, das wenn doch mal die Suche durch 'nen Fehler abbricht, man das Programm nicht mehr ordnungsgemäß beenden kann -.-'')
• und die Auswahl des Suchverzeichnisses ist jetzt keine JEDI-Komponente mehr

Ach ja, derzeit werden die Suchergebnisse nach der Suche gelöscht.
Aber man könnte diese Ergebnisse ja noch beibehalten, so daß man dann die angezeigte Liste der Suchergebnisse z.B. über Filter einschränken kann.
Wenn also jemand Ideen hat, wie man diese Liste filtern kann, so möge er/sie mir dieses bitte mitteilen


Zur Verfügung stehen derzeit die folgenden Rohdaten:

Delphi-Quellcode:

Files: Array of Record
  Directory: LongInt;          // Verzeichnis der Datei
  FileName: AnsiString;        // Dateiname der zuerst gefundenen Datei
  FileSize: LargeInt;          // die Dateigröße
  SameFiles: Array of Record
    Directory: LongInt;        // Verzeichnis/Dateiname der anderen 
    FileName: AnsiString;      //   Dateien, mit dem selben Dateiinhalt
  End;
End;

Als Anhang sind jetzt auch mal die Quellcodes zu finden,
falls mal jemand dort reinschauen möchte.


Aber nicht wundern, da wird ja einiges aus'm UCC verwendet, allerdings hab ich ja vor kurzem den integrierten Memory-Manager verändert und muß jetzt wiedermal einige "Low-Level-Zugriffe" im UCC entsprechend anpassen

[himitsu]

So, jetzt hatte ich nochmal Zeit dafür und hab einiges geändert.

• Die Anzeige der Dateien ist jetzt übersichtlicher
• Dateien können jetzt direkt über's Programm gelöscht werden
  (und zwar in den Papierkorb, können also wiederhergestellt werden)
• es besteht jetzt die Möglichkeit das Suchergebnis zu filtern
  - man kann man kann derzeit Dateien nach Verzeichnis/Dateiendung aus der Liste entfernen lassen
• PopUp-Menü in die ListBox eingebaut, worüber die Filerfunktionen aufgerufen werden können.
• Die einzelen Hauptschritte sind jetzt einzeln abbrechbar.
  Immernoch über's [X].
• neuer MemoryManager ist auch drin.
  Der integrierte MemoryLeakCheck hatte mich gleich mal dazu gebracht mir 'ne neuere JVCL zu besorgen.
  In meiner alten JVCL v3.00 Build 1758 hatte die JvCheckTreeView den Speicher nicht vollständig geräumt
  und ich dachte erst, es wäre ein Fehler in meinem Programm -.-''
  
  Ich hab auch mal eine Version mit UsageTracker angehängt.
  Wenn es jemanden interessiert, der wird sehen wie erst beim Füllen der JvCheckTreeView der Speicherverbrauch in die Höhe schießt.
  (ein minimiertes/geschlossenes UsageTracker-Fenster verbraucht keine CPU-Resourcen)
• ...

Relativ schnell scheint's Programmchen jetzt auch zu sein.
Was mich aber noch stört, ist das langsame Füllen der ListBox.
Diese visuellen Komonenten sind ja leider nicht gerade schnell und im Moment ist dieses auch einer der längsten Arbeitsschritte.
Der reine Dateivergleich dauert bei mir für rund 11 GB, 128.000 Dateien mit 20% Gleichen knapp 32 Minuten.

[Kara]

Hm, bin ich blind, oder hast dus nirgends verlinkt? Ich würds gern haben, wenns schon Freeware ist.
Funktioniert das für mp3s?

[himitsu]

Das vergleicht alles, unabhänig von Name/Typ.
Aus diesem Grund kann man das Suchergebnich auch erst nach der Suche einschränken.

Und die Dateien sind im Ersten Beitrag (das machst sich in diesem Unterforum am Besten )

[Kara]

Sorry, dann hat der IE vorhin gesponnen und sie nicht angezeigt. (IE NUR in der Arbeit )

[himitsu]

Es kann natürlich auch sein, dass ich die "neuen" Dateien in diesem Moment gerade hochgeladen hab.

PS: me = dauer IE-User

[Hador]

Ist gar nicht schlecht.
Verbesserungsvorschläge:

- Angeben von mehreren Pfaden (Entweder alle Pfade durch Trennzeichen getrennt oder die Pfade in'nen Memo) - Siehe auch die Angabe der Libphade bei Delphi ^^

- Beschränken auf bestimmte Dateitypen, z.B. nur *.jpeg oder nur *.mp3

- Wofür stehen die Zahlen vor den jeweiligen Dateinamen ? Wenn die wie ich vermute für Durchsuchte, bzw. gefundene doppelte Dateien stehen, dann sollte das evt. irgendwo dabei stehen.

- Die Anzeige für die Datei die grad getestet wird ändert sich nur ca. alle 150 Dateien mal

[Luckie]

Was ist denn das immer für ein zweites fenster dahinter, an das man kaum drankommt? BTW bleibt die Memorymap bei mir immer leer.

Nach der ersten Suche bekam ich folgende Meldung:

Zitat:

---------------------------
search same files
---------------------------
Ein deaktiviertes oder unsichtbares Fenster kann nicht den Fokus erhalten.
---------------------------
OK
---------------------------

[himitsu]

Also das Meldungfenster kenn' ich noch garnicht ... kommt das auch bei der normalen Version, oder nur dort, wo der UsageTracker eingebunden ist?



@Hador
werd' mir mal einige Gedanken über deine Vorschläge machen.
Im Moment Versuche ich aber erstmal einige Dinge zu beschleunigen - vorallem die TreeView.
Da dieses allerdings nur ein Nebenprojekt ist und ich vorallen an den Basicfunktion arbeite, worauf dieses Projekt aufbaut, bleibt da leider nicht all zuviel Zeit für.
Aber einiges wird sich in der nächsten Zeit bestimmt umsetzen lassen.

Es ist ganz normal, das die Anzeige der durchsuchten Dateien springt, denn die diese Anzeige erfolgt etwa alle 0,75 Sekunden ... es wäre Sinnlos und auch extrem Zeitfressend, wenn die Anzeige nach jeder Datei erfolgen würde.

Und ja, die Zahl steht für die Anzahl der gleichen Datei in der entsprechenden Untergruppe.
Da ich diessén Teil aber erst gestern eingebaut hab, ist das noch nicht so ganz Optimal gelöst ... es wird sich dort also bestimmt noch etwas verbessern lassen.

Das es sich hierbei noch um ein Projektchen in der Anfangsphase handelt hab ich ja versucht anhand der Versionsnummer dazustellen.
Und obwohl es bis jetzt bei mir fehlerfrei gelaufen ist, hat mir der Luckie natürlch auch durch diese Erfolgserlebnis einen Strich gemacht -.-''