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.489 Themen, 73.614 Beiträge
Schau dir mal das Programm RapidCRC an. Das berechnet die Prüfsummen und hängt die auf Wunsch an den Dateinamen an (wahlweise auch in den NTFS-Stream). Und bei einer erneuten Überprüfung erkennt es auch die Prüfsummen im Dateinamen und vergleicht automatisch damit.
Das Programm unterstützt CRC32, MD5, SHA1, SHA256 und SHA512 und klinkt sich auch in das Kontextmenü ein.
und hängt die auf Wunsch an den Dateinamen an (wahlweise auch in den NTFS-Stream).
Das hört sich auf jeden Fall schon mal nach einer interessanten Lösung an. Auf eine zusätzliche Liste mit Hash-Werten würde ich dann allerdings trotzdem nicht verzichten.
Die Alternate Datastreams können leider recht schnell verloren gehen, vor allem wenn z.B. Dateien zwischen verschiedenen NTFS-Dateisystemen/Partitionen/Laufwerken verschoben werden mit Programmen die diese nicht berücksichtigen und spätestens natürlich wenn mal ein anderes Dateisystem als NTFS zum Einsatz kommt.
In eine externe Datei exportieren kann das Programm die Prüfsummen auch. Zusätzlich kann die verwendete Dateiendung mit RapidCRC verknüpft werden, ein Doppelklick auf die Datei stösst dann automatisch eine Prüfung aller Dateien in der Liste an.
Vorteil beim Eintrag in den Dateinamen ist halt, das man die Dateien hin- und herverschieben kann, während bei der Verwendung einer Liste immer alle Dateien im gleichen Verzeichnis bleiben müssen.
Das ist noch nicht ganz was ich suche. Da passiert mir zu viel im Verborgenen, wie das Programm da vergleicht. Da steht dann nur file OK, aber was genau verglichen wurde kann ich nicht sehen. Auch gefällt mir nicht die Summe an den Dateinamen zu hängen da meine Dateinamen so schon ellenlang sind. Und das mit dem NTFS Stream ist wohl zu unsicher außerdem steht der auch irgendwo verborgen. Wenn ich bei einem Programm nicht durchschaue was da gerade genau ausgelesen und verglichen wird, habe ich da kein richtiges Vertrauen.
---------------------------------------------------------------------------------------------------------------------
Also es geht darum für jede Datei die "geboren" wird einmalig eine Checksumme zu erstellen und irgendwo zu verwalten. Um immer wieder mal prüfen zu können. Am besten alle Dateien auf einmal, die indiziert sind bzw wo eine Hash vorliegt.
Das Problem ist, werden Dateien umbenannt/verschoben wie soll ein Programm dann wissen wo die Datei jetzt liegt?
Dafür suche ich eine Lösung. Vielleicht gibt es aber auch etwas ganz anderes...
Da passiert mir zu viel im Verborgenen, wie das Programm da vergleicht. Da steht dann nur file OK, aber was genau verglichen wurde kann ich nicht sehen
Naja, die Algorithmen habe ich ja oben aufgelistet - CRC32, MD5, SHA1, SHA256 und SHA512. Das sind keine Exoten, sondern die üblichen Standardalgorithmen für derartige Überprüfungen. Die Funktionsweise und mathematischen Grundlagen sind im Netz auch entsprechend dokumentiert. Also nix verborgenes...
Zu deinen restlichen Vorstellungen fällt mir leider kein passendes Programm ein, insbesondere die Verwaltung von Dateien NACH dem Verschieben in andere Ordner finde ich etwas optimistisch :-) Man kann seine Ansprüche auch etwas zu hoch schrauben...
Das Problem ist, werden Dateien umbenannt/verschoben wie soll ein Programm dann wissen wo die Datei jetzt liegt?
Wenn Du einzelne Dateien einfach so verteilen willst, dann wird es schwierig irgendwelche Metadatan zuverlässig zu erhalten. Wobei sich mir nicht so ganz erschließt warum Du die Struktur in einem Speicherarchiv so häufig ändern willst. Das führt auch beim Backup zu Ärger.
Was man natürlich machen kann: Bei Dateipfaden die nicht in der Hash-Liste auftauschen prüfen ob deren neu berechneter Hash-Wert zu einem anderen Pfad in der Liste passt bei dem die Datei nicht mehr existiert. In dem Fall kann man davon ausgehen, dass die Datei verschoben wurde. Wenn nun allerdings zusätzlich noch Dateien ergänzt und gelöscht wurden, dann kann man nicht mehr eindeutig zu verschobenen Dateien und solchen bei denen sich der Hashwert geändert hat unterscheiden.
Dafür suche ich eine Lösung. Vielleicht gibt es aber auch etwas ganz anderes...
Für Windows nicht, oder wenn wird es teuer. Nimm ein Speichersystem auf Basis von ZFS oder einem anderen Dateisystem, dass intern Checksummen verwaltet und kopiere / verschiebe ausschließlich mit ausschließlich mit Verifikation des Ziels über Dateisystengrenzen.
Wenn Du volle Kontrolle haben willst, dann musst Du es wohl oder übel selbst implementieren. Das kann aber auch böse ins Auge gehen, wenn man nicht genau weiß was man tut…
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. Bei den anderen Prüfsummen ist die Wahrscheinlichkeit wesentlich geringer, allerdings immer noch theoretisch vorhanden.
Damit ist jede Unterscheidung von Dateien allein am Hashwert potentiell gefährlich. Da Dateien aber auch umbenannt werden sollen sehe ich da so direkt keine Möglichkeit das risikolos zu managen.
Ich bleibe bei meiner Empfehlung den Hashwert in den Dateinamen zu setzen. Damit kann die Datei nach belieben verschoben und umbenannt werden (sofern man den Hashwert am Ende des Dateinamens beibehältet, typischerweise in Klammern) und der Hashwert ist eindeutig einer Datei zugeordnet.
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
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)
Es gibt durchaus noch einige Bereiche in denen CRC-Prüfsummen verwendet werden, allerdings nicht im professionellen Sektor. Dabei handelt es sich dann meist um eine schlichte Fehlerkontrolle, insbesondere auf korrekten Download.
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.
Da im Anforderungsprofil bereits von Verschieben und Umbenennen die Rede war dürfte es auf die Hashwerte im Dateinamen auch nicht mehr ankommen :-)
Dabei handelt es sich dann meist um eine schlichte Fehlerkontrolle, insbesondere auf korrekten Download.
Da kann ich mich nun spontan aber an keinen einzigen Fall erinnern bei dem ich das in den letzten 10 Jahren gesehen hätte. Gerade bei Downloads möchte man doch möglichst auch ein kryptographisches Hash-Verfahren um unentdeckte Manipulationen durch Dritte zu verhindern. Da hat sich MD5 oder SHA1 eingebürgert und von MD5 wird auch schon länger abgeraten…
Da im Anforderungsprofil bereits von Verschieben und Umbenennen die Rede
Da ist natürlich was dran :-D
Im Video-Sektor sind CRC-Prüfsummen noch recht üblich - eben auch mit den Hashes im Dateinamen. Da geht es ganz schlicht darum einen kompletten Download sicherzustellen bzw Downloadfehler auszuschliessen. Manipulationen sind da eher nicht relevant :-)
Nimm ein Speichersystem auf Basis von ZFS oder einem anderen Dateisystem, dass intern Checksummen verwaltet
Was ich jetzt gelesen habe ist ZFS das sicherste für Datenintegrität, mit guten Checksummen.
Gibt es keine Möglichkeit das unter Windows zu implementieren?
----------------------------------------------------
Wenn ich unter Linux einen ZFS Datenträger erstelle und parallel aber noch Windows nutze und diesen dann unter Windows hochfahre, was passiert dann?
----------------------------------------------------
Ansonsten bliebe noch ReFs mit Win 8. Das soll auch Checksummen haben aber nicht so gut sein wie ZFS.
Gibt es keine Möglichkeit das [ZFS] unter Windows zu implementieren?
Wenn Du Genug Zeit hast, dann könntest Du das sicherlich als IFS realisieren. Wobei es wohl zumindest schon ein Projekt gibt, dass an ZFS-Support für Windows arbeitet: https://code.google.com/p/zfs-win/ Wäre nun aber nichts was ich für den Produktivbetrieb empfehlen würde…
und diesen dann unter Windows hochfahre, was passiert dann?
Nichts. Windows erkennt außer FAT und NTFS praktisch keine anderen Dateisysteme und ignoriert entsprechende Datenträger dann…
Ansonsten bliebe noch ReFs mit Win 8.
Bist Du ReFS auf dem Desktop bekommst könnte es aber noch eine ganze Weile dauern. Ich würde zumindest meine Hand nicht dafür ins Feuer legen, dass das tatsächlich schon bei Win8.1 nur auch in der Desktop-Version mit dabei ist und ob dann alle Funktionen bereits realisiert sind. Außerdem ist es durchaus mit Risiken behaftet verbunden neue Dateisystem einzusetzen die noch keine nennenswerte Verbreitung haben und entsprechend gut durchgetestet wurden…
Dieser Beitrag wurde versehentlich doppelt abgesendet. Deshalb wurde das Duplikat gelöscht und nur das Original beibehalten.
Was ist IFS und wie ein etwa richtet man das ein?
------------------------------------------
Bei dem Projekt ist es wohl noch nicht gelungen.
Da steht: A read-only drive can be mounted with the help of Dokan.
D.h. es kann nur gelesen werden von der Platte?
-------------------------------------------
ReFS gibts für Win 8.1
http://www.drwindows.de/content/1840-windows-8-1-bekommt-dateisystem-refs.html
Ich traue mich das als erster mal zu benutzen. Soviel Vertrauen habe ich in Microsoft.
Bleibt nur die Frage was es kann in Win 8.1. Es gibt ja auch noch 8.1 Pro.
Das könnte man aber mal bei der Microsoft Technik Hotline genauer erfragen.
Die soll allerdings 80 Euro pro Anruf kosten habe ich gelesen ! ?
Was ist IFS
http://en.wikipedia.org/wiki/Installable_File_System
D.h. es kann nur gelesen werden von der Platte?
Keine Ahnung. Ich habe mir das nicht näher angeschaut…
ReFS gibts für Win 8.1 http://www.drwindows.de/content/1840-windows-8-1-bekommt-dateisystem-refs.html
In den ganzen Berichten ging es aber immer nur um die Vorwersion. Ob es in der Finalen Version mit drin ist konnte ich nicht ermitteln und auch nicht wie weit der Support dann geht. Möglicherweise wird nur dann nur ein Teil des Funktionsumfangs unterstützt.
Ich traue mich das als erster mal zu benutzen. Soviel Vertrauen habe ich in Microsoft.
Das hatten die Nutzer vom WHS damals vermutlich auch bevor bekannt wurde, dass dort ein Datenverlust eintreten kann…
Ansonsten verweise ich mal auf die aktuell bekannten Probleme:
http://en.wikipedia.org/wiki/ReFS#Stability_and_known_issues
Zusammenfassend sehe ich da aktuell höhere Risiken für die Daten als durch Einzelbitfehler. Vor allem bei Deinem Anwenungsszenario wo es um Audio-Daten geht.