Eindeutiger Vergleich für große Dateien gesucht

[negaH]

Ok, ich setze noch einen drauf und habe dir die Unit fertig gecodet. In der letzen zeit hätte ich das Ding schon 2-3 mal selber gebrauchen können.

@Bigg: was ist an der ASM so lustig ?

Gruß Hagen

[bigg]

An Assembler ist gar nicht's lustig, aber die Länge deines Codes ist es. :)

[negaH]

das nennt man Loop-Unrolling ;) Der MD4 Code hat wenn ich mich recht errinnere einen Durchsatz von > 250MB/sec. Das ist auch der Grund warum der binäre Dateivergleich mit Hilfe von CompareMem() so langsam ist.

Gruß Hagen

[himitsu]

Irgendwo hatte ich mal 'ne Funktion, welche zwar auch auf MD5 aufbaute, aber dennoch dateien mit "gleichen Hash's unterschied.

Dazu liegt bei mir noch 'ne hübsche MD5-Version rum, welche fast komplette in ASM geschrieben wurde ... und wenn ich mich nicht irre, ist die auch schneller als die oben gezeigten.

Dazu hab ich auch mal Hagen's RipeMD320 nach dem schema meiner MD5-Version überarbeitet.
Und mit dem RipeMD320 ist auch nochmal ein besserer Vergleich möglich ... da der HJash ja mehr Bits, als das MD5 hat.

Ich versuche die entsprechenden Code mal nächste Woche hochzuladen,
aber jetzt muß ich erstmal weiter ... tschüssili :(

[add]
@Hagen:
ich hatte mal einige deiner Codes (DEC) von Luckies Seite runtergeladen
und dort stimmte die Anzahl der Werte in der MD5-Tabelle nicht ... es sollten doch nur 256 Werte sein und nicht mehr?

[negaH]

Zitat:

Dazu liegt bei mir noch 'ne hübsche MD5-Version rum, welche fast komplette in ASM geschrieben wurde ... und wenn ich mich nicht irre, ist die auch schneller als die oben gezeigten.

Ich kann dir versichern das MD4 garantiert schneller als MD5,SHA1/256,RipeMD ist. Benchmark aus meinem inoffiziellen DEC indem 3 erfahrene Coder alle Hashroutinen per Hand in Assembler optimiert haben:

Code:

THash_MD2           :      261.3 cycles/byte       5.74 Mb/sec
THash_MD4           :        5.9 cycles/byte     252.53 Mb/sec
THash_MD5           :        9.0 cycles/byte     167.01 Mb/sec
THash_SHA           :       21.0 cycles/byte      71.31 Mb/sec
THash_SHA1          :       20.7 cycles/byte      72.43 Mb/sec
THash_SHA256        :       47.2 cycles/byte      31.76 Mb/sec
THash_SHA384        :       86.1 cycles/byte      17.43 Mb/sec
THash_SHA512        :       88.0 cycles/byte      17.05 Mb/sec
THash_Sapphire      :       55.0 cycles/byte      27.25 Mb/sec
THash_Panama        :        8.1 cycles/byte     185.24 Mb/sec
THash_Tiger         :       24.7 cycles/byte      60.81 Mb/sec
THash_RipeMD128     :       15.1 cycles/byte      99.08 Mb/sec
THash_RipeMD160     :       26.5 cycles/byte      56.63 Mb/sec
THash_RipeMD256     :       14.8 cycles/byte     101.69 Mb/sec
THash_RipeMD320     :       25.7 cycles/byte      58.31 Mb/sec
THash_Haval128      :       13.9 cycles/byte     108.01 Mb/sec
THash_Haval160      :       14.1 cycles/byte     106.43 Mb/sec
THash_Haval192      :       33.4 cycles/byte      44.95 Mb/sec
THash_Haval224      :       34.7 cycles/byte      43.28 Mb/sec
THash_Haval256      :       26.2 cycles/byte      57.23 Mb/sec
THash_Whirlpool     :       98.9 cycles/byte      15.17 Mb/sec
THash_Whirlpool1    :       99.3 cycles/byte      15.10 Mb/sec
THash_Square        :       46.4 cycles/byte      32.34 Mb/sec
THash_Snefru128     :      168.2 cycles/byte       8.92 Mb/sec
THash_Snefru256     :      250.0 cycles/byte       6.00 Mb/sec

Gruß Hagen

[dahead]

@negaH:

Zitat:

Ok, ich setze noch einen drauf und habe dir die Unit fertig gecodet.

hättest du nicht unbedingt machen müssen, ich verwende lieber md5. vorallem weil ich keinen signifikanten geschwindigkeitsvorteil in einem kurzen test mit deiner FileCompare.pas festgestellt habe.

von nutzen ist deine unit aber auf alle fälle, nicht dass du mich falsch verstehst... ich verwende eben nur ungern den kompletten code von jemand anderem.

wie gesagt, nochmals danke für deine mühe!

@himitsu:

würde mich auch interessieren.

[negaH]

Zitat:

und dort stimmte die Anzahl der Werte in der MD5-Tabelle nicht ... es sollten doch nur 256 Werte sein und nicht mehr?

Du meinst den Initialisierungs-Vektor, nehme ich mal an ?

Das liegt daran ads THash_MD5 die Basisklasse auch für RipeMD ist, und dieser benutzt in den ersten Inits die gleichen Werte. Um mir eine überladene Methode für die verschiedenen abgeleiteten Klassen zu sparen habe ich diesen gleich in die Mutterklasse implementiert. Die überschüssigen Werte werden also für MD5 nicht benutzt.

Gruß Hagen

[negaH]

Zitat:

hättest du nicht unbedingt machen müssen, ich verwende lieber md5. vorallem weil ich keinen signifikanten geschwindigkeitsvorteil in einem kurzen test mit deiner FileCompare.pas festgestellt habe.

von nutzen ist deine unit aber auf alle fälle, nicht dass du mich falsch verstehst... ich verwende eben nur ungern den kompletten code von jemand anderem.

Das du keinen Untrschied merkst liegt daran das alle anderen nötigen Schritte viel mehr an Rechenzeit benötigen. Würde man aber auf schon geladenen Speicherbereichen MD4 mit MD5 vergleichen soentstünde obige Performance Tabelle.
Für Prüfsummen erachte ich MD4 als besser, für kryptographische Belange sollte man unbedingt MD5 benutzen, da in MD4 Teilkollisionen konstruiert werden konnten (ergo gilt als unsicher-er)

Den Source habe ich im Grunde erstmal für mich persönlich geschrieben, habe ja sonst nichts besseres zu tuen ;)

Gruß Hagen

[himitsu]

Ich meinte meine MD5 gegenüber den obern aufgelisteten MD5's
dass MD4 schneller ist, weiß ich auch schon.

Außerdem ist MD5 auch nur'n aufgemotzes/langsammeres MD4 ^^

PS: ich hab an meinen obrigen Beitrag noch was angehängt ...

Ach ja, aber da ich ja die wirkliche geschwingig keit meiner Codes nicht weiß ... schicke ich sie dir irgendwann mal, dann kannst du sie ja mal auf deinem System (wegen des besseren Vergleichs) testen.

@dahead:
ich werd mich beeilen ...
hab die Codes ja in 'ner eigenen Codesammlung und, wo ich nur noch mit einen Basics kleine Probleme hab ... Zeiltich bin ich ja auch noch etwas eingeschränkt

Und wenn ich die entsprechenden Codes von einigen Funktioen meiner Lib (ohne größere Probleme) trennen kann, dann veröffentliche ich auch schon vorzeitig.

@Hagen
nein, ich meine die Werte für die Berechnung ... aber ich kann mich auch im Moment irren und es war bei der CRC32-Berechnung ... wenn ich daheim bin, werde ich da sicherheitshalber nochaml nachgucken.

aber das mit der Initialisierung hab ich schon bemerkt (das die Initfunktion von beiden verwendet wird ^^)

[dahead]

Zitat:

Das du keinen Untrschied merkst liegt daran das alle anderen nötigen Schritte viel mehr an Rechenzeit benötigen.

ja, ich weiß. ich könnte sicherlich mit md4 noch was rausholen, verwende md5 halt wg. der entdeckten kollision (gibts ja mtwl. bei md5 auch -> ergo ist meine begründung relativ sinnfrei, da gebe ich dir recht).

aus diesem grund bin ich auch auf himitsu's lösung gespannt.

Zitat:

Den Source habe ich im Grunde erstmal für mich persönlich geschrieben

davon haben sicherlich noch viele andere etwas. beachte einfach mal den download-counter von zeit zu zeit. ich wette der code findet viele abnehmer.

Zitat:

habe ja sonst nichts besseres zu tuen

wie darf ich das verstehen?

edit:
@himitsu:

Zitat:

ich werd mich beeilen ...

ich habe zeit, eilt nicht, trotzdem danke dafür.

[FriFra]

:shock: Das war ja mehr als ich erwartet hab... Danke negah :)

Eins ist mir allerdings aufgefallen... die CompareFile Funktion die du vor Deiner unit gepostet hast, ist bei mir deutlich schneller als die aus der FileCompare.pas. Ich hab das ganze über mehrere Dateien laufen lassen und komme mit der Funktion aus dem Thread auf 10s und mit der aus der unit auf 70s :gruebel: ... ich hab mir den Code aus der unit noch nicht näher angesehen, ist mir halt nur aufgefallen ;)

[himitsu]

Zitat:

Zitat von dahead

wie darf ich das verstehen?

na weil er viele seiner Codes nur für sich selbst zu machen schweint ...
jedenfalls veröffentlich er einiges nicht. (um sein DEC macht er ja auch so ein großes Geheimnis)
Aber bei Einigem kann man ihn ja auch verstehen.


So, aber nun muß ich wirklich los :cry:

[dahead]

@himitsu:

Zitat:

na weil er viele seiner Codes nur für sich selbst zu machen schweint ...

hehe

ich meinte damit egtl. eher warum er meint, dass er nichts besseres zu tun hat. das kann ich mir egtl. nicht vorstellen.

und klar, wenn jemand viel zeit in einen code investiert, gibt er/sie ihn klar nicht einfach so raus. ist verständlich.

@FriFra:

wenn du mit "CompareFile" die MMF Methode meinst, negaH hat in FileCompare.pas den binären vergleich verwendet, also keine memory mapped files. (CompareFile1 war die binäre variante).

[FriFra]

ja, das wars ;) ... nur das HashFile bremst das ganze bei mir extrem aus. Wenn ich ausschliesslich mit der MMF Methode vergleiche ist das ganze wesentlich schneller als über Hash. Ich weiss im Moment nicht so recht, wo der Vorteil/Sinn von diesem Hash-Vergleich liegen soll :gruebel:

[dahead]

naja, folgendes beispiel:

du willst 1000 dateien mit der mmf methode auf gleichheit prüfen. das dauert relativ lange. wenn du aber vorher bereits via md4/md5 oder sonstwas eine checksumme erstellst (was schnell geht), brauchst du nachher nur noch die dateien mit gleichen checksummen via mmf inhaltlich prüfen.

hoffe du konntest mir folgen.

edit: vielleicht sagt dir folgender code mehr als obiges:

Delphi-Quellcode:

      if (ItemI.fFileSize > 0) and (ItemF.fFileSize > 0) then
       if ItemI.fFileSize = ItemF.fFileSize then
        if ItemI.Hash = ItemF.Hash then
         a.) if CompareNormalFilesFileStreamStatic(ItemI.fFullFilename, ItemF.fFullFilename) = True then
         b.) if CompareMemoryMappedFiles(ItemI.fFullFilename, ItemF.fFullFilename) = True then
          doppelt

[negaH]

Zitat:

nein, ich meine die Werte für die Berechnung ... aber ich kann mich auch im Moment irren und es war bei der CRC32-Berechnung ... wenn ich daheim bin, werde ich da sicherheitshalber nochaml nachgucken.

Jo in der CRC32 Routine sind einige Bytes mehr in der Lookup Tabelle als nötig wären, das bleibt aber mein Geheimnis ;)

Zitat:

a, das wars ... nur das HashFile bremst das ganze bei mir extrem aus. Wenn ich ausschliesslich mit der MMF Methode vergleiche ist das ganze wesentlich schneller als über Hash. Ich weiss im Moment nicht so recht, wo der Vorteil/Sinn von diesem Hash-Vergleich liegen soll

Vorsicht ! Ich dachte auch erst das MMF's saumäßig überlegen sind, denkste. Das du so große Unterschiede bemerkst, zumindestens wars bei mir so, liegt daran das das OS bei MMF's diese sehr lange im Speicher belässt, selbst wenn man alle Handles geschlossen hat. Der erste Scan einer ungecachten Datei über MMF's dauerte dann bis zu 55 Sekunden, der zweite Scann (nach einige anderen Dateien) der selben Datei dauerte dann aber nurnoch 7 Sekunden.
Ließ dir mal obigen Link zu Borland Page genauer durch, dort wird das "Problem" beschrieben.

Desweiteren muß man stark differnezieren. Meine jetzigen Routinen vergleichen zwei IDENTISCHE Dateien langsammer als wenn man sie sofort per Binärem Scan vergleichen würde. Das ist absolut korrekt so, denn man zieht ja im schlechtesten Falle vorher noch zweimal einen MD Hash. Wenn diese gleich sind muß nochmals ein binärer Vergleich nachgeschoben werden. Wie aber im Source beschieben sind zwei absolut gleiche Dateien in einem durschnittlichen Dateiaufkommen sehr sehrunwahscheinlich. Wenn man aber schon vorher weis das die zu vergleichenden Dateien mit hoher Wahrscheinlichkeit identisch sind dann sollte man sofort mit CompareFilePhysical() arbeiten. Aber im Normalfalle sind sie sehr sehr unwahscheinlich identisch.

Zitat:

na weil er viele seiner Codes nur für sich selbst zu machen schweint ...

ICH bin für MICH Programmierer und eigentlich schon bekannt dafür viele meine Sourcen besonders hier in der DP mit anderen zu teilen. Und mal davon abgesehen meine ich das meine Sourcendie ich mit anderen teile keine "Abfallprodukte" darstellen, also eine gewisse Qualität besitzen.
Nee, den Schuh muß ich mir nicht anziehen.

Zitat:

ich meinte damit egtl. eher warum er meint, dass er nichts besseres zu tun hat. das kann ich mir egtl. nicht vorstellen.

Ja ich hätte schreiben sollen "Sarkasums on" .... "Sakrasmus off" ;)
Ich bin freiberuflicher Programmierer und muß Geld verdienen, mehr als jeder Angestellte. Meine Aussage bezog sich also darauf das ich diese Unit auch für ein kommerzielles Projekt benötigt habe und somit durch glücklichen Zufall am selben Thema arbeiten konnte ;) Normaleweise hätte ich also dazu keine Zeit gehabt.

[dahead]

@negaH:

ich meinte das nicht negativ, im gegenteil. wie gesagt, mit deinem wissen, was alleine das mmf thema anbelangt, konnte ich mir eben nicht vorstellen, dass du "nichts besseres" zu tun hast. ich bin sehr froh darüber, dass du dir dabei so viel mühe gemacht hast.

ich glaube niemand wollte dir unterstellen, dass deine offenen sourcen abfallprodukte sind, ganz im gegenteil. ich schätze wenn du dich nicht bei dem thema beteiligt hättest, hätte ich bis heute nicht gewusst was mmf überhaupt ist.

in diesem sinne, nochmals danke für die hilfe.

edit:

Zitat:

Jo in der CRC32 Routine sind einige Bytes mehr in der Lookup Tabelle als nötig wären, das bleibt aber mein Geheimnis Wink

evtl. ein copyright hinweis? oder hätte ich mir den kommentar verkneifen sollen?

[negaH]

Nochmal was zur Performance, da es hier um grundsätzliche Verständnissprobleme die unter Programmieren sehr häufig vorkommen geht.

Mal als Beispiel alles ein bischen idealisert dargestellt.

Wir gehen mal davon aus das auf einer HD eine Million Dateien gespeichert wurden. Nun sollen alle Duplikate gefunden werden. Alle Dateien zusammen sind 1 Terrabyte groß. Von diesen Dateien sind 10% mit gleicher Dateigröße zueinander und von diesen sind nur 0.1% absolut identisch zueinander.

So per MMF's=Binärem Dateivergleich benötige ich pro Mb 10 Sekunden.
Einen Hash über diese Datei zu erzeugen benötige ich 5 Sekunden, also die Hälfte der Zeit da ich ja nur eine Datei statt zwei einlesen muß.


Die Aufgabe ist es nun 10% von 1 Million = 100000 Dateien untereinander zu vergleichen. Per Hash ziehe ich 100000 mal eine Prüfsumme und vergleiche diese untereinander. Das dauert 100000 *5 = 500.000 Sekunden. von diesen1 100.000 Dateien wissen wir das aber nur 0.1% wirklich identisch zueinander sind. Nach 500.000 Sekunden müssen wir also noch 100 Dateien tatsächlich binär vergleichen, was 100 * 10 Sekunden= 1.000 Sekunden dauert. Wird kommane auf 501.000 Sekunden um per Hash-Methode alle 100 identischen Dateien zu finden.

Nun per MMF's=binärem Drekt vergleich. Wir haben wieder 100.000 Dateiem mit gleicher Größeum vergleichen jede dieser 100.000 mit jeder anderen der 100.000 Dateien, ergibt 10^9 Vergleich a 10 Sekunden, macht 10^10 Sekunden die man benötigen würde um die 100 identischen Dateien zu finden.

D.h. selbst wenn 1 Vergleich per Hash + Binärem Vergleich also 20 Sekunden dauert, im gegensatz zu 1* 10 Sekunde pro binärem Vergleich, so ändert sich dieses Ratio ganz ganz gewaltig wenn man vom NORMAL-Fall ausgeht, nämlich das von 1 Million Dateien tatsächlich nur 100 identisch sind.

Man muß also als Programmierer sehr genau die Wahrchenlichkeiten des Auftratens bestimmter Ereignisse berücksichtigen und dann einen Optimierungsweg einschalgen der diese Wahrscheinlichkeiten auch aktiv berücksichtigt.

Exakt darin liegt das Geheimnis viel Algorithmen, zb. JPEG,MP3,Suchalgorithmen etc. pp. Ansich sind sie alle im Grunde aufwendig oder verlustbehaftet aber das stört nicht weil sie im Normalfalle eben bei den wahscheinlichst auftauchenden Daten enorm schnell und effektiv sind.

Gruß Hagen

[negaH]

Zitat:

evtl. ein copyright hinweis? oder hätte ich mir den kommentar verkneifen sollen?

Nöö kann jeder wissen, SOLLTE jeder gute Programmierer auch aus dem Source erkennen müssen ! Das denoch in sovielen kommerziellen Produkten meine Copyright's auftauchten ist schon ein Wunder, ein Wunder das es soviele "schlechte" Programmierer gibt die einfach 1 zu 1 andere Source, hm raub-kaufen. Immerhin DEC ist zwar Freeware, d.h. aber nicht das man ohne meine Zustimmung DEC einfach mal so kommerziell benutzen darf.

Aber im Falle der CRC32 ist mein Copyright wirklich ziemlich stupide und eigentlich offensichtlich versteckt worden, wirklich ein Wunder das du bisher der einzigste Programmierer bist der mich darauf anspricht.

Die richtigen Signaturen sind aber bei weitem besser getarnt ;) Es gibt also noch mehr im DEC zu entdecken !

Gruß Hagen

PS: das fällt mir doch ne lustige Episode ein. Eines Tages bekomme ich ne Mail ob man mein DEC kaufen könnte. Eine Firma hat entdeckt das in ihren Binaries mein Copyright drinnen war (lesbar selbstverständlich). Sie hatte sich eine kleine Software gebaut die mein Copyright aus der EXE nach dem kompilieren raus-patchte. Nun, sie hatten aber auch meine kompletten Sourcen vor sich liegen, nur fanden sie mein Copyright nicht im Source !!
Tja, irgendwann waren sie es wohl leide jedesmal ihre Programme patchen zu müssen und mailten mich eben an.

[dahead]

hehe. ja, so gehts, wenn man sich nichtmal genau ansieht, was man verwendet/kopiert.

daher habe ich auch oben erwähnt, dass ich ungern den kompletten source von jemand anderem einfach übernehme.

[negaH]

Zitat:

ja, ich weiß. ich könnte sicherlich mit md4 noch was rausholen, verwende md5 halt wg. der entdeckten kollision

Ja in MD4 wurden Kollisionen entdecket, um exakt zu sein 1 Kollision konnteentdeckt werden. Aber, man benutzte dazu einen modifizierten MD4 Algorithmus der nur 64 Bit Komplexität besaß, der entscheidende Teile des Algorithmus'es (das Wort sieht irgendwie schei.e aus) deaktivert hatte. Diese Vorgehensweise ist durchaus üblich wenn man in rein akademischer Art ein Verfahren analysieren möchte. Nun, rein rechnerisch hätte bei diesem modifizierten MD4 denoch nicht diese Kollision auftreten dürfen, und ergo interpoliert man dies auf den originalen MD4 und behauptete das dieser "unsicher" sei.

Es ist also alles relativ, aber denoch reicht dieser Verdacht vollkommen aus um MD4 in der Kryptographie als tot zu erklären. Die Reaktion der Kryptographen ist also absolut verständlich denn 0.0000000000000000000000000000001 % Unsicherheit in einem Verfahren das 100% sicher sein sollteist einfach zu viel.

Aber für unsere Belange absolut irrelevant.

Gruß Hagen

[FriFra]

@negaH: Eben diese Wahrscheinlichkeiten sind nach meinen Erfahrungen/Tests "etwas" anders...
Wenn ich ein Programm habe, welches alle gefundenen gleichgroßen Dateien vergleichen soll, dann dauert das Erzeugen der jeweiligen Hashwerte deutlich länger als ein Bitweiser Vergleich, da sich die meisten "duplikate", trotz gleicher Größe erheblich unterscheiden. Es liegt auf der Hand, daß es länger dauern muß, einen Hashwert der gesamten Datei zu erzeugen, als einen kleinen Block bitweise zu vergleichen.
Ich hab es jetzt extra nochmal mehrfach getestet und MIT Hash ist es um ein vielfaches langsamer als ohne.

Natürlich ist es auch immer eine Frage der gewünschten/geforderten Anwendung. Für den Fall mit der Datenbank macht der Hashwert durchaus Sinn, zum reinen Dateivergleich eher nicht.

[negaH]

@FriFra:

ich kann deine Argumentation sehr wohl verstehen, eben weil ich exakt der Auffassung bin das es vom Set der verschiedenen Dateien abhängt. In meinem Falle gibt es Aufnahmen verschiedener Krankheitsherde im Bitmap Format. Somit sind sehr viele Dateien in gleicher Dateigröße vorhanden da das Bildformat stdandardisiert ist. Es gibt sogar viele Serienaufnahmen der gleichen Wunden und in diesem Falle kann ich garantieren das ich bei Tests eine wesentliche Performancesteigerung per Hashs erreichen konnte. Immerhin pro Bild ca. 4Mb Dateigröße und pro Packet neuer Bilder ca. 50-200 Dateien die zu archivieren sind. Da in mehreren Filialen die Bilder sehr häufig doppelt gespeichert sind erhöht sich bei Übernahme eines Klientens die Wahscheinlichkeit das Bilder doppelt archiviert werden enorm. Die Klienten werden häufig in mehreren Filialen parallel geführt und nur von Zeit zu Zeit deren Akten untereinander aktualisiert. Die Bilder sind in Datenbanken mit der Anamese zusammen gespeichert, man benötigt ja auch textuelle Informationen zu den Wunden. Und in dieser DB speicheren wir natürlich auch den Hash über die Bilder.
In meinem Falle wohl eine ideale Anwendung.

Aber auch Bildrachivierungsprogramme könnte von der Unit profitieren.

Gruß hagen

[himitsu]

OK, 's war doch nicht bei MD5, sondern bei CRC32:

DECUtil.pas Version 3.0
function CRC32(CRC: LongWord; Data: Pointer; DataSize: LongWord): LongWord; assembler;
268 Werte in Tabelle @CRC32 (67 Zeilen á 4 Werte)

CRC16 war OK, aber ob sowas noch bei anderen Tabellen vorliegt kann ich nicht mit Sicherheit sagen.

(na ja, ich hatte bei meinem MD5 einige Werte in Tabellen ausgelagert und hab da wohl etwas mit den Tabellen verwechselt ... aber da es normaler Weise keine Tabellen im MD5 gibt, blieb nur noch CRC übrig ^^)




Hab auch mal meine Hashdatei und die zugehörige Demo angehängt.
Und wie schon gesagt, läßt sie sich nicht einzeln verwenden, da ja noch einige Dateien fehlen.
(ich möchte halt dieses Dateien nicht veröffentlichen, solange ich weiß, dass darin etwas nicht stimmt)
Also, auf jeden Fall nicht funktionsfähig sind z.B. die xxxFile-Funktionen, aber wie man eine Datei ausließt und an xxxUpdate übergibt sollte ja bekannt sein ... die Basic-Funktionen sollten lauffähig sein.
(für 'nen einiger Maßen durchschittlichen Programmierer sollte es keine Probleme geben diese Datei, durch Löschung/Änderung der entsprechenden Funktionen, zum laufen zu bringen)

Aber wie mir weiter oben aufgefallen ist, hat Hagen nun doch einen ASM-Variante ... diese wird eventuell doch schneller sein, da ich nicht komplett auf Speed geproggt hab ... hatte mal vor 'ner Weile meine Codes, in Beziehung auf die Codegröße, etwas überarbeitet und durch die entstandenen Schleifen wurde es etwas langsamer ... gegenüber reinem Pascal kann sich die Geschwindigkeit bestimmt dennoch sehen lassen :mrgreen:



Ich bin im Moment damit beschäftig alle meine Dateien nochmal durhzusehen und bin zuversichtlich, dass die meisten Dateien in Ordnung sind.
Und wenn die wichtigsten Dateien OK sind, werd' ich endlich mal den ersten Teil hochladen können.

[negaH]

Zitat:

(ich möchte halt dieses Dateien nicht veröffentlichen, solange ich weiß, dass darin etwas nicht stimmt)

Du spielst damit auf versteckte Signaturen an ? Falls ja kann ich dich beruhigen, meine Signaturen liegen eher in der Art&Weise wie ich was programmiert habe, zb. in ASM Teilen richte ich Schleifen fast immer an 4 Bytes Grenzen aus und als Opcode-Lückenfüller baue ich dann eine 2 oder 3 Bytes große immer wiederkehrende Signatur ein. Das ist im Source offensichtlich erkennbar, aber auf Grund der Systematik und der Unwahrscheinlichkeit das dies andere Programmierer auch so machen, erkenne ich in disassemblierten Binaries schon mit hoher Wahrscheinlichkeit Codes von mir.

Innerhalb der wichtigen Daten der Hashs, Ciphers etc. kann und darf ich nichts zum Original verändern, das dürfte wohl klar sein.

Davon mal abgesehen, ich habe ja grundsätzlich garnichts dagegen das ein Programmierer von anderen Programmierern lernt, das ist sogar notwendige Bedingung um sich weiterzubilden. Ich habe nur was gegen Programmierer die unverschämt einen Source kopieren, relevante Stellen modifizieren und später als ihre Schöpfung ausgeben. Sprich sich mit den Federn Anderer schmücken. Besonders im kommerziellen Bereich gibt es Landstriche auf unserem Globus wo dieses Unrechtsempfinden stärker ausgeprägt zu sein scheint. Es gefällt mir zwar nicht aber aus meiner Erfahrung muß ich zugeben das in östlichen geographischen Lagen das stärker auftritt als in westlicheren Zeitzonen (obwohl ich selber ein Ossi bin). Einerseits habe ich echt offene und mitteilsamme Leute per Mail so kennen gelernt, zb. die Leute von ASPack (Russen) nutzten DEC einige Zeit lang und sendeten mir freiwillig eine freigeschaltete Vollverson zu, bedankten sich fürs DEC und fragten ausdrücklich nochmals nach ob sie es einbauen dürften. Im Readme.txt sogar ein Hinweis auf alle bebnutzten 3'rd praty Komponenten. Das waren keine Einzelfälle. Aber es gibt auch Negativbeispiele aus der gleichen Region.

Egal, tut ja eigentlich nichts zum Thread beitragen.

Gruß Hagen

[dahead]

Zitat:

das in östlichen geographischen Lagen

hätte jetzt eher auf die usa getippt.

Zitat:

Egal, tut ja eigentlich nichts zum Thread beitragen.

stört mich nicht.

[Sharky]

Hai Hagen,

sei doch bitte so nett und hänge den Code aus diesem Posting als Anhang an. Bei über 600 Zeilen Quellcode im Posting scrollt man sich die Flossen wund.

Danke :-)

[negaH]

Zitat:

hätte jetzt eher auf die usa getippt.

Nö kann ich eigentlich nicht sagen, oder sie tarnen es einfach besser. In die USA, England, Frankreich, Italien sogar Japan habe ich eigentlich gute und offene Kontakte. Es ist ja nicht so das DEC was besonderes wäre, es ist Freeware und kann frei genutzt werden. Es freut mich nur einfach wenn ich über so eine Arbeit nette Kontakte kennen lerne.

Die Amerikaner halten sich ziemlich zurück, das liegt aber an den besonderen Bedingungen die im Falle der Kryptographie dort herrschen. Besonders dramatisch ist es in Frankreich, da ist im grunde jegliche Form der privaten Nutzung von Kryptographie verboten, ergo lernte ich besonders solche Leute kennen die man als "Randgruppe" bezeichnen könnte, verstehst ? Die Italiener wierderum scheinen sich einen Dreck um Gesetze zu kümmern, bei denen heist es immer "no problem" ;) Japaner sind wiederum enorm höflich, schei. freundlich und trotzdem weiß man nie so recht woran man wirklich ist, weil sie teilweise ein bißchen "verspielt" scheinen.

Jo, ich bin froh ein Programmierer geworden zu sein.

Gruß Hagen

[negaH]

@Sharky,

das würde ich gerne tuen weil du absolut Recht hast, die DP bringt folgende Fehlermeldung

Zitat:

Du kannst einen Beitrag nach seiner Erstellung nur innerhalb von 1440 Minuten bearbeiten.

sollte ich jetzt beim Moderator nachfragen ?

Gruß Hagen

Edit: ups, DU bist ja der Moderator, nach Aussage des PHP-Script-Fehlers bitte ich dich also dies zu tuen ;)

[Sharky]

:oops: Habe ich doch tatsächlich die Edit-Sperre vergessen ;-)

Zitat:

Zitat von negaH

... Edit: ups, DU bist ja der Moderator, nach Aussage des PHP-Script-Fehlers bitte ich dich also dies zu tuen ;)

"Ich habe es getan"

[himitsu]

Hab zwar den Code zum Dateivergleich noch nicht gefunden, aber ein Stringvergleich tut es doch auch.
Der Dateivergleich entsprach aber in etwa dem Inhalt der "If Length(S2) > 1 Then"-Bedingung.
(hauptsächlich Vergleich der Hash's und bei gleichem Hash nochmal einen byteweisen Vergleich der Daten,
damit das Problem gleicher Hash's, trotz unterschiedlicher Rohdaten nicht auftritt)

"S2 = Wortliste..." führt eine Funktion aus, welche die Bytes vergleicht und beim ersten Unterschied den Vergleich abbricht,
also die gesammten Stringdaten werden fast niemals verglichen/bearbeitet.

Und wenn man jetzt mal die beiden Varianten misst, dann wird eine erhebliche Steigerung der Geschwindigkeit dankt der Hash's auffallen.

Ein Vergleich ohne Hash's ist halt nur dann schneller, wenn nur ein einziger String, oder eben eine einzige Datei mit einem anderen String / einer anderen Datei verglichen wird.
Aber wenn man mehrere Strings/Dateien untereinander vergleicht, sieht das ganz anders aus, da ja sonst jeder String / jede Datei mehrfach eingelesen wird ... beim Hash hat mann dagegen einen netten kleinen Wert zum Vergleich ganz schnell zur Hand.

Warum hier unter Umständen nochmals die Strings/Dateien direkt miteinander Verglichen wird,
brauch ich dank Nico/Hagen ja nichtnochmal zu erklären.
z.B.

Zitat:

Wenn die Prüfsummen gleich sind, müssen die Daten nicht identisch sein.

Input: S
z.B. Inhalt einer TextDatei

Output: Wortliste
Liste aller enthaltenen Wörter
bestehend aus 0-9, A-Z, "_" und a-z

Delphi-Quellcode:

Var S, S2: AnsiString;
  i, i2, i3, L: Integer;
  H: LongWord;
  Wortliste: Array of Record
    Hash: LongWord;
    Wort: AnsiString;
  End;

Begin
  Wortliste := nil;
  L := Length(S);
  While (i <= L) and not (S[i] in ['0'..'9', 'A'..'Z', '_', 'a'..'z']) do Inc(i);
  While i <= L do Begin
    i2 := i;
    While (i2 <= L) and (S[i2] in ['0'..'9', 'A'..'Z', '_', 'a'..'z']) do Inc(i2);
    S2 := Copy(S, i, i2 - i);
    i := i2;
    If Length(S2) > 1 Then Begin
      H := CRC32(S2);
      i3 := -1;
      For i2 := High(Wortliste) downto 0 do
        If (H = Wortliste[i2].Hash) and (S2 = Wortliste[i2].Wort) Then Begin
          i3 := i2;
          Break;
        End;
      If i3 < 0 Then Begin
        i3 := Length(Wortliste);
        SetLength(Wortliste, i3 + 1);
        Wortliste[i3].Hash      := H;
        Wortliste[i3].Wort      := S2;
      End;
    End;
    While (i <= L) and not (S[i] in ['0'..'9', 'A'..'Z', '_', 'a'..'z']) do Inc(i);
  End;
End;

Delphi-Quellcode:

Var S, S2: AnsiString;
  i, i2, i3, L: Integer;
  Wortliste: Array of AnsiString;

Begin
  Wortliste := nil;
  L := Length(S);
  While (i <= L) and not (S[i] in ['0'..'9', 'A'..'Z', '_', 'a'..'z']) do Inc(i);
  While i <= L do Begin
    i2 := i;
    While (i2 <= L) and (S[i2] in ['0'..'9', 'A'..'Z', '_', 'a'..'z']) do Inc(i2);
    S2 := Copy(S, i, i2 - i);
    i := i2;
    If Length(S2) > 1 Then Begin
      i3 := -1;
      For i2 := High(Wortliste) downto 0 do
        If S2 = Wortliste[i2].Wort Then Begin
          i3 := i2;
          Break;
        End;
      If i3 < 0 Then Begin
        i3 := Length(Wortliste);
        SetLength(Wortliste, i3 + 1);
        Wortliste[i3] := S2;
      End;
    End;
    While (i <= L) and not (S[i] in ['0'..'9', 'A'..'Z', '_', 'a'..'z']) do Inc(i);
  End;
End;

In etwa so könnte es z.B. für Dateien aussehen:

Delphi-Quellcode:

List: Array of Record
  Hash: LongWord;
  FN: AnsiString;
End;


H := CRC32File(FileName);
i2 := -1;
For i := High(List) downto 0 do
  If (H = List[i].Hash) and CompareFile(FileName, List[i].FN) Then Begin
    i2 := i;
    Break;
  End;
If i2 < 0 Then Begin
  // Datei in die Liste eintragen
  i2 := Length(List);
  SetLength(List, i2 + 1);
  List[i2].Hash := H;
  List[i2].FN   := FileName;
End Else Begin
  // eine Datei mit dem selben Inhalt existiert bereits
End;

PS: wie Hagen schon sagte, kann man jetzt noch die Dateigöße mit in den Vergleich mit einbeziehen, um nochmeh Geschwindigkeit rauszubekommen.
Aber so wie mein DemoCode aufgebaut ist, ist dieses nicht wirklich nötig, da ein weiteres Vergleichskriterium die gesammte Prozedur natürlich erstmal etwas verlangsamt
und die erhoffte Beschleunigung nur dann eintreten wird, wenn die Hash's gleich sind ... was ja auch nicht gerade oft vorkommt.
Ergo ist ein weiteres Vergleichskriterium, wie Größe/Datum... hierfür unnötig.
Aber wie gesagt, wenn man wiederum nur eine Datei mit einer anderen Vergleichen will, können witere Kriterien Wunder bewirken ;)

PSS: was ich noch sagen bezöglich der maximalen Dateigröße sagen wollte ...
Viele Dateifunktionen arbeiten nur mit 32 Bit ... und obwohl die netten WinAPI-Funktionen auch 64 Bit verstehen können, wird dennoch (meistens) nur mit 32 Bit gearbeitet.
Also versagen die meisten Hashfunktionen schon bei Dateien über 2 GB.
Die Hashfunktionen mögen ja auch mit mehr als 2 GB umgehen können, aber wenn der Dateiinput dort aufgibt, bringt dieses nun auch nichts.

Und da die Dateien/Datenträger immer größer werden, sind mehr als 2 GB nichts exotisches mehr,
also hab ich meine UCC und demnach dir darin enthaltenen Hashfunktionen natürlich mit 64-Bit ausgestattet.


PS: Ja, das mit dem unverschämten Kopieren ist nicht nett und ich kann sowar ja auch nicht leiden.
Ich bin allerdings der Meinung, das es dabei nicht auf bestimmte Regionen ankommt, wie die Programmierer dort damit umgehen.

In meinem UCC habe ich zwar das Meißte selbst erstellt und an den entsprechenden Stellen, wo es nicht volltändig aus meiner Feder stammt, wird dieses dann auch erwähnt.




[add]
och menno ... immer dieser Hagen mit seinen Geheimnissen ... da denkt man mal, man hat 'nen Fehler in seinen Codes gefunden und dann behauptet der doch tatsächlich, das es angeblich richtig so sei :(
und wenn man dann die vielen Beiträge dort oben nochmal durchsieht, dann fällt einem auf, daß man sich die Arbeit mit den Codes auch hätte sparen können, weil einiges davon schonmal gesagt wurde :wall:

Ich muß unbedingt mal wieder etwas mehr Zeit hier verbringen ... denn bei solchen Themen fällt es doch stark auf, wenn man nicht ständig hier ist ... man kommt einfach nicht mehr hinterher -.-''

so, noch 2 Datei übrig

[MuTzE.Y85]

Mahlzeit,

der Thread ist schon sehr alt, aber ich habe da trotzdem mal eine Frage :-D
Ich nutze die FileCompare.pas von negaH (Hagen) um 2 Verzeichnisse (A und B) zu Vergleichen, also Datei für Datei.

Dabei nutze ich diese Funktion

Code:

function CompareFile(const FileName1, FileName2: String): Boolean; overload;
begin
  Result := (AnsiCompareText(FileName1, FileName2) = 0) or
            ((GetFileSize(FileName1) = GetFileSize(FileName2)) and
             (HashFile(FileName1) = HashFile(FileName2)) and
             CompareFilePhysical(FileName1, FileName2));
end;

Anschließend werden die unterschiedlichen Dateien synchronisiert (Von A nach B).
Lasse ich nun die Funktion nochmal drüber laufen, findet er wieder Unterschiede (sogar andere Dateien wie vorher), obwohl ich nichts verändert habe.
Nehme ich aber aus der Funktion oben den Teil mit der MD4-Überprüfung raus (HashFile), funktioniert es.

Ist da vielleicht ein Fehler drin :?:

[p80286]

Zitat:

Zitat von MuTzE.Y85 (Beitrag 1258448)

Ich nutze die FileCompare.pas von negaH (Hagen) um 2 Verzeichnisse (A und B) zu Vergleichen, also Datei für Datei.
...
Ist da vielleicht ein Fehler drin :?:

Die Wahrscheinlichkeit ist eher gering. U.u hast Du eine Kleinigkeit geändert, die sich so auswirkt?
Ich habe mir nicht den ganzen Thread durchgelesen, aber wenn ich es richtig behalten habe geht Hagen von einer bestimmten "üblichen" Konstellation aus.
Ich würde so arbeiten

Code:

if filesize(file1)=filesize(2) then
  if hash(file1)=hash(file2) then
    if binary(file1)=binary(file2) then FileIsEqual

Das AnsiCompareText hat mir nichts gebracht, aber das kann natürlich auch an den Dateiinhalten liegen.

Ändern sich die Inhalte einer Datei nicht, ändert sich auch der Hash-Wert nicht. Falls doch ist da etwas faul. U.U. solltest Du da mal ein Vergleichsprotokoll mitlaufen lassen um zu sehen mit welchen Daten Du da hantierst.

Gruß
K-H

[Sir Rufo]

Das AnsiCompare ist ja nur für den Fall, dass man beides Mal den gleichen Dateinamen angibt.
Die sind definitiv gleich, weil diesselbe ;)

[p80286]

:oops: Das kommt davon wenn man nicht richtig liest, Jahre her und trotzdem aufgefallen:oops:

Gruß
K-H

[MuTzE.Y85]

Zitat:

Zitat von p80286 (Beitrag 1258456)

Ich würde so arbeiten

Code:

if filesize(file1)=filesize(2) then
  if hash(file1)=hash(file2) then
    if binary(file1)=binary(file2) then FileIsEqual

Naja die oben genannte Funktion, die ich nutze ist ja aus der FileCompare.pas :wink:
Sie wurde also von Hagen dort hinein geschrieben.

Zitat:

Zitat von p80286 (Beitrag 1258456)

Die Wahrscheinlichkeit ist eher gering. U.u hast Du eine Kleinigkeit geändert, die sich so auswirkt?

Darum habe ich mich auch vorsichtig ausgedrückt :)