Wie Dateiveränderung veststellen (bei Backup)
-
Ich schreibe an einem Backupprogramm welches einege spezielle Funktionen bietet. (Ist hier aber nicht weiter von belang)
Da ich nun die Dateigröße reduzieren will, denke ich daran nur die Dateien zu sichern die sich geändert haben seit dem letzen Backup.
Da dieses Verfahren aber absolut sicher sein muss, kann ich weder Änderungsdatum, Größe oder ähnliches heranziehen. Ich dachte folglich an Hash Funktionen.
Nun braucht aber zB MD5 alleine schon etwa 20 Minuten um für 40GB Prüfsummen zu berechnen. Das ist sozusagen untragbar.
Kennt jemand für solch einen Fall einen Lösungsweg? Hat jemand ne Idee?
-
Hallo
Wenn du wirklich den Inhalt und nicht nur Datumsstempel vergleichen willst wirst du immer eine gewisse Zeit brauchen, um danach zu suchen. Ob es wirklich etwas signifikant schnelleres gibt als MD5 weiß ich nicht.
Aber da das nichts Builder-spezifisches ist verschieb ich dich mal.
bis bald
akari
-
Dieser Thread wurde von Moderator/in akari aus dem Forum VCL (C++ Builder) in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
AntonWert schrieb:
Nun braucht aber zB MD5 alleine schon etwa 20 Minuten um für 40GB Prüfsummen zu berechnen.
Das macht 32MB/Sekunde, ist doch gar nicht so schlecht. Der Flaschenhals wird der Festplattenzugriff sein, selbst bei 100MB/Sekunde Übertragungsrate bräuchtest du über 6 Minuten. 40 GB sind einfach unheimlich viel.
-
MD5 ist auf modernen CPUs schneller als moderne Festplatten. Sprich etliche hundert MB/s.
Ein kleinwenig optimieren kann man es vermutlich indem man asynchrone IOs verwendet (dadurch kann man den aktuellen Block durch die MD5 schieben während der nächste schon gelesen wird, ohne sich auf das Prefetching von Windows zu verlassen).Aber schneller als die Festplatte wird's deswegen wohl auch nicht werden. Vermutlich. Behaupte ich mal.
-
Warum sollten Dateigrösse/Zeitstempel nicht gehen? Geht ein Verfahren, wo nur in Ausnahmefällen ein MD5 Hash eruegt wird? Und eventuell nicht über die ganze Datei, sondern nur über Blöcke einer Datei?
Du könntest zu jeder Datei, die du sicherst, einen Eintrag dauerhaft speichern, dieser Eintrag könnte die Dateigrösse und mehrere MD5 Hashes für je einen Block von vielleicht 1M. Jedes Mal, wenn du ein Backup machen musst holst du dir den entsprechenden Eintrag des vorhergehenden Backups und vergleichst erst einmal die Dateigrösse. Wenn die sich verändert hat kopierst du die Datei und ersetzt den Info Eintrag. Wenn die Dateigrösse gleich ist generierst du einen MD5 Hash über das erste MB der Datei und vergleichst ihn mit dem MD5 Hash des ersten MB aus dem Info Block. Wenn der MD5 Hash unterschiedlich sein sollte oder in dem Info Block fehlt dann kopierst du die Datei und ersetzt den Info Block durch den aktuellen. Sollte der MD5 Hash gleich sein bildest du den MD5 Hash über das nächste MB und so weiter.
-
AntonWert schrieb:
Da dieses Verfahren aber absolut sicher sein muss, kann ich weder Änderungsdatum, Größe oder ähnliches heranziehen. Ich dachte folglich an Hash Funktionen.
das änderungsdatum ist doch ok. die windoofs FILETIMEs bestehen aus 8 bytes und haben 'ne auflösung von 0.1µs, oder so. das ist fast schon so gut, wie ein richtiger hashwert. die dateigrösse allerdings sagt nicht viel aus über eine änderung.
-
+fricky schrieb:
AntonWert schrieb:
Da dieses Verfahren aber absolut sicher sein muss, kann ich weder Änderungsdatum, Größe oder ähnliches heranziehen. Ich dachte folglich an Hash Funktionen.
das änderungsdatum ist doch ok. die windoofs FILETIMEs bestehen aus 8 bytes und haben 'ne auflösung von 0.1µs, oder so. das ist fast schon so gut, wie ein richtiger hashwert. die dateigrösse allerdings sagt nicht viel aus über eine änderung.
Das Änderungsdatum kann man aber setzen.
Also
- Änderungsdatum lesen
- Datei ändern
- Änderungsdatum auf das zuvor gelesene zurücksetzen
Normale Programme machen sowas nicht, das stimmt schon. Wenn man aber absolut sicher, und egal was für komische Programme da was für komische Sachen machen, garantieren muss, dass sämtliche Änderungen irgendwo abgeglichen werden, kann man sich leider nicht auf das Änderungsdatum verlassen.
-
Hat NTFS nicht ein Archiv-Bit für solche Zwecke? Ich meine sowas mal gelesen zu haben.
Ein Archiv-Bit wird beim Archivieren gesetzt und bleibt so lange gesetzt bis die Datei geändert wird. Beim nächsten Archiviervorgang kann man alle Dateien überspringen welche das Bit noch gesetzt haben.
-
@Profi-Progger: Schlaubär. Wenn du dich auf das Archiv-Bit verlässt, kannst du dich gleich genausogut auf das Änderungsdatum verlassen. Das Archiv-Bit kann man nämlich genauso einfach zurücksetzen.
Davon abgesehen gibt es nur *ein* Archiv-Bit -- was willst du dann machen, wenn du zwei oder drei "Backups" bzw. allgemein Kopien updaten willst?
-
hustbaer schrieb:
+fricky schrieb:
AntonWert schrieb:
Da dieses Verfahren aber absolut sicher sein muss, kann ich weder Änderungsdatum, Größe oder ähnliches heranziehen. Ich dachte folglich an Hash Funktionen.
das änderungsdatum ist doch ok. die windoofs FILETIMEs bestehen aus 8 bytes und haben 'ne auflösung von 0.1µs, oder so. das ist fast schon so gut, wie ein richtiger hashwert. die dateigrösse allerdings sagt nicht viel aus über eine änderung.
Das Änderungsdatum kann man aber setzen.
klar, aber sollte ungefährlich sein. sollte irgendwas das änderungsdatum verbiegen, dann würden dateien nochmals 'ge-backupt', obwohl sie's nicht müssten. die wahrscheinlichkeit, genau den wert zu erwischen (es gibt ja alle 100ns einen neuen wert), der das backup-programm vom speichern abhalten könnte, ist sehr gering.
-
Ist überhauptnicht gering, wenn man den Wert vorher liest, dann die Datei ändert, und dann den alten Wert wiederherstellt
-
hustbaer schrieb:
Ist überhauptnicht gering, wenn man den Wert vorher liest, dann die Datei ändert, und dann den alten Wert wiederherstellt
das muss schon in böswilliger absicht geschehen, also ein programm, dass bei jedem schreibzugriff immer wieder denselben timestamp setzt. oder wie sonst willst du den wert wieder herstellen, den sich das backup-programm als indikator für 'nicht speichern' gemerkt hat? aber hast schon recht, möglichkeiten irgendwas auszuhebeln gibts natürlich immer.
-
+fricky schrieb:
das muss schon in böswilliger absicht geschehen, also ein programm, dass bei jedem schreibzugriff immer wieder denselben timestamp setzt. oder wie sonst willst du den wert wieder herstellen, den sich das backup-programm als indikator für 'nicht speichern' gemerkt hat? aber hast schon recht, möglichkeiten irgendwas auszuhebeln gibts natürlich immer.
Richtig, "normale" Programme machen das nicht. Hatte ich ja schon geschrieben:
hustbaer schrieb:
Normale Programme machen sowas nicht, das stimmt schon. Wenn man aber absolut sicher, und egal was für komische Programme da was für komische Sachen machen, garantieren muss, dass sämtliche Änderungen irgendwo abgeglichen werden, kann man sich leider nicht auf das Änderungsdatum verlassen.
Der OP meinte aber schon relativ früh, dass er sich nicht auf Timestamps verlassen kann/darf/will. Natürlich könnte man ihn fragen wieso (was vermutlich eine gute Frage wäre, weil er vermutlich keinen guten Grund dafür hat), aber das hab ich eben nicht, sondern es einfach mal als gegeben angenommen.
