Hallo,
es geht um hohe Datenintegrität.
Ich habe müsam und ordentlich grippte CDs, eine große Sammlung und möchte für alle wav Dateien (auch anderen Dateien) Hashwerte ermitteln und irgendwie irgendwo abspeichern bzw verwalten.
So dass ich regelmässig mal überprüfen kann ob irgendwie was manipuliert oder korrumpiert wurde, Bits umgekippt sind oder gar ganze Dateien defekt sind.
Das Programm mus folgendes können:
Hashwerte von Dateien erstellen und irgendwie verwalten.
Kommen neue Dateien und Ordner (Alben) dazu, müssen diese ebenfalls gescannt und deren Hashwerte ermittelt werden.
Es geht also um eine ständige Erweiterung einer Hashwertesammlung.
Werden Dateien und Ordner umbenannt oder verschoben muss das Programm damit ebenfalls klarkommen.
Ich kennen kein Programm das das kann. Die können alle z.B: nur Hashwerte eines Ordners ermitteln und in eine Datei speichern.
Um diese Hashwerte zukünftig nutzen zu können bedingt das aber das ich in dem Ordner nie wieder was ändere.
D.H. ich kann diese Hashdatei nicht erweitern um neue Dateien, sondern immer nur wieder von vorne beginnen eine komplette Hashdatei aus dem Ordner zu erstellen.
Das ist aber nicht Sinn der Sache.
Ich möchte also einmalig nach dem Rippen Hashwerte erstellen und irgendwo verwalten. Kommen neue Dateien und Ordner dazu werden deren Hashwerte ebenfalls ermittelt und so immer weiter.
Oder kann man etwa Prüfsummen direkt an Dateien anhängen quasi irgendwo mit dazu schreiben?
Dann wäre es auch kein Problem wenn die Datei umbenannt oder verschoben wird, wenn die Prüfsumme irgendwie der Datei zugeordnet ist. Das wäre die Lösung.
Nur brauche ich dann ein Programm was automatisch den zugehörigen Hashwert ausliest, einen aktuellen aus der Datei erstellt und beide eben vergleicht um mir dann eben sagen zu können ob sich im Lauf der Jahre irgendwas an der Datei verändert hat.
Danke!
Anwendungs-Software und Apps 14.427 Themen, 72.820 Beiträge
Weiterhin sollte man berücksichtigen, das auch die Möglichkeit besteht das 2 unterschiedliche Dateien den gleichen Hash-Wert erhalten. Zumindest bei CRC ist das nicht abwegig, das hatte ich schon mehrmals.
Klar. Hash-Verfahren mit hoher Kollisionswahrscheinlichkeit darf man dann natürlich nicht verwenden. CRC hatte ich nun auch gar nicht mehr so recht auf dem Schirm, weil es heute als nicht-kryptographishes Hash-Verfahren kaum noch praktische relevanz hat (so zumindest mein Eindruck) und Kollisionsfreiheit dort auch nicht zu den Designzielen gehörte. Rein zum Vergleich würde das aber wahrscheinlich schon eine ausreichende Sicherheit bieten.
Damit ist jede Unterscheidung von Dateien allein am Hashwert potentiell gefährlich.
Ist letztendlich eine Frage der Länge. Ab bestimmten größen (und guten Hashfunktionen) sollte man allerdings hinreichend sicher davon ausgehen können, dass zwei Dateien identisch sind. Wie sicher man das letztendlich wissen muss hängt ja auch wieder davon ab was man mit der Information anstellt. Für Deduplikation würde ich auch auf einen 1:1 Vergleich bestehen, da dienen Hashes nur zum Finden der Duplikate.
Hier ginge es ja nur darum festzustellen ob die Dateien unverändert geblieben sind. Sofern keine Dateien dazu gekommen oder gelöscht wurden kann man mit dem Hash trotzdem noch was anfangen: Man hat eine Menge von Dateipfaden ohne Hash und man hat Hashes zu nicht mehr existierenden Dateipfaden. Wenn wir nun die unbekannten Hashes berechnen, so sollte die Ergegbnismenge identisch sein mit den Hashwerten der nicht mehr vorhandenen Dateien. Sonst haben wir einen Fehler.
Ich bleibe bei meiner Empfehlung den Hashwert in den Dateinamen zu setzen.
Halte ich auf jeden Fall auch für einen sehr interessanten Ansatz. Vorraussetzung ist allerdings, dass ein sauberes Dateinamensschema realisierbar ist und die Dateien nirgendwo namentlich referenziert werden. Dann hätten wir nämlich wieder andere Probleme. Hier dann z.B. in der Form, dass eine Playlist nicht mehr funktioniert.
Gruß
bor