Eigenen Prüfsumme Algo

[xXRobo_CubeXx]

Ich möchte mein eigenen Algo herstellen und daraus eine einzigartige Prüfsumme machen. Bis jetzt meine abzufragende Werte:
-Dateigröße
-Erstellung Ddatum
-Änderung Datum
-Datei Name
-Datei Atribute
-die ersten und letzten 10 Zeichen
Reicht das für eine kolisionsfreie Prüfsumme? Oder habt ihr bessere vorschläge?

[NicTheQuick]

Prinzipiell eine gute Idee, dein Vorschlag ist allerdings sehr speziell. Er zielt wohl darauf ab, direkt zu erkennen, ob Dateien sich im Dateisystem geändert haben und nicht ob sich ihr Inhalt geändert hat. Wenn das dein Ziel ist, dann würde ich vom Inhalt der Datei noch 1 kB am Anfang und Ende dazu nehmen, dann sollte das ziemlich sicher sein.

Natürlich bringt das nichts, wenn du Dateien vergleichen willst. Denn es wird sehr selten vorkommen, dass zwei Dateien den selben Namen, das selbe Erstellungsdatum und den selben Inhalt haben.

Es kommt also auf den Zweck an. Erkläre uns genauer, was du mit dieser Prüfsumme erreichen willst, dann können wir dir genauer sagen, ob das etwas bringt.

[mhs]

Ja erklär uns doch erstmal im Groben, wofür du den Vergleich machen möchtest, dann können wir mehr sagen.

Die einfachste Variante ist natürlich zuerst die Dateigröße vergleichen und nur wenn beide Dateien gleich groß sind einen der bekannten Hash Algorithmen einzusetzen.

Es gibt z.b. unter Windows noch das "Archiv" Flag, welches bei jeder Änderung der Datei automatisch vom Betriebssystem zurückgesetzt wird. Evtl. würde dir das schon weiterhelfen.

[xXRobo_CubeXx]

Ich will vergleichen können ob die Dateien indentisch sind. Ich habe mal angefangen und versucht dies umzusetzen. Hier mein Ansatz (noch nicht fertig!) ...

Code: Alles auswählen

Dateipfad.s = "Test.txt"

Dateiname.s = GetFilePart(Dateipfad)
Erstellungsdatum = GetFileDate(Dateipfad, #PB_Date_Created)
Aenderungsdatum = GetFileDate(Dateipfad, #PB_Date_Modified)

ReadFile(0, Dateipfad)
Dateigroesse = Lof(0)
Laenge = Dateigroesse * 1 / 100 ; 1 %

*MemoryID1 = AllocateMemory(Dateigroesse)
ReadData(0, *MemoryID1, Laenge)
AnfangInhalt.s = PeekS(*MemoryID1, Laenge)
FileSeek(0, Dateigroesse-Laenge)
*MemoryID2 = AllocateMemory(Dateigroesse)
ReadData(0, *MemoryID2, Laenge)

EndeInhalt.s = PeekS(*MemoryID2, Laenge)

FreeMemory(*MemoryID1)
FreeMemory(*MemoryID2)
CloseFile(0)


RohePruefsumme.s = Str(Dateigroesse) + Str(Erstellungsdatum) + Str(Aenderungsdatum)

For i=1 To Len(RohePruefsumme) Step 2
  Pruefsumme.s + Chr(Val(Mid(RohePruefsumme, i, 2)) + 33) ; Erst ab "!" Zeichen
Next
  
Debug Pruefsumme

; AnfangInhalt und EndeInhalt fehlen noch...

Ich weiss der Code sieht scheisse aus

[mhs]

Ich will vergleichen können ob die Dateien indentisch sind.

Wenn du wirklich vergleichen willst, ob die Datei identisch ist, dann kannst du die rot markierten Punkte gleich mal streichen:

-Dateigröße
-Erstellung Ddatum
-Änderung Datum
-Datei Name
-Datei Atribute
-die ersten und letzten 10 Zeichen

Also quasi alles was du hast

Das Erstellungs- und Änderungsdatum sagt ja nicht aus, dass die Datei identisch ist. Kopierst du eine Datei von einem Verzeichnis in ein anderes, erhält sie auch andere Datumswerte, ist aber vom Inhalt her 1:1 identisch.

Der Dateiname ist auch nur Schall und Rauch, mach Copy & Paste unter Windows und du hast "Datei", "Datei - Kopie 1", "Datei - Kopie 2", etc und alle Dateien sind inhaltlich genau gleich.

Die Dateiattribute? Sagen auch nichts über den Inhalt aus. Einzig und allein das "Archiv" Flag könnte dir unter Windows helfen, wenn du immer die gleiche Datei auf Änderungen überwachen möchtest. Verarbeite die Datei, setzte das Archiv Flag zurück und überprüfe dann regelmäßig ob das Archiv Flag durch das Betriebssystem wieder neu gesetzt wurde. Wenn ja, dann verarbeitest du die Datei wieder, weil sie verändert wurde und setzt anschließend das Archiv Flag wieder zurück.

Die ersten und letzten 10 Zeichen... und was ist mit den 99999999... Zeichen dazwischen? Eine Datei kann am Anfang und Ende immer genau gleich sein und sich nur dazwischen ändern.

Dir bleibt gar nichts anders übrig, als die gesamte Datei einzulesen und zu vergleichen. Das machen im Grunde auch die Hash Algorithmen so... Aus Performance Gründen würde ich nur immer als erstes die Dateigröße vergleichen, weil wenn die eh unterschiedlich ist, dann ist auch die Datei unterschiedlich...

[RSBasic]

Die Dateigröße kann man auch streichen, weil das sehr unsicher ist. Wenn jemand den Inhalt einer Datei "Hallo" in "Halle" ändert, bleibt die Dateigröße gleich.

[mhs]

Die Dateigröße kann man auch streichen, weil das sehr unsicher ist. Wenn jemand den Inhalt einer Datei "Hallo" in "Halle" ändert, bleibt die Dateigröße gleich.

Aus Performance Gründen würde ich nur immer als erstes die Dateigröße vergleichen, weil wenn die eh unterschiedlich ist, dann ist auch die Datei unterschiedlich...

[RSBasic]

Okay, du hast gewonnen.

[gekkonier]

Wenn mans übertreiben will reicht doch, wenn man mit FileFingerprint(...) mit allen möglichen Algorithmen und mehreren optionalen Offsets drüberlaufen lässt.



Und wenn dann noch das Angsti da ist stattdessen halt byte für byte vergleichen.

[GPI]

Was heist hier angst - wenn du eine Datei auf 32Byte (oder wie groß die Prüfsumme ist) reduzierst, gehen zwangsweise Informationen verloren. Es sollte nicht schwer sein, zwei gleich große Dateien zu finden, die komplett unterschiedlich sind und die gleiche Prüfsumme haben. Besonders wenn man hier doppelte Dateien zum löschen finden will, ist Datenverlust quasi vorprogrammiert.