Anwendungs-Software und Apps 14.492 Themen, 73.651 Beiträge

umfangreiches Programm gesucht um Prüfsummen/Hashwerte zu verwal

Nutellageil / 16 Antworten / Baumansicht Nickles

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!

bei Antwort benachrichtigen
ABatC Nutellageil „umfangreiches Programm gesucht um Prüfsummen/Hashwerte zu verwal“
Optionen

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.

http://www.ov2.eu/programs/rapidcrc-unicode

bei Antwort benachrichtigen
Borlander ABatC „Schau dir mal das Programm RapidCRC an. Das berechnet die ...“
Optionen
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.

bei Antwort benachrichtigen
ABatC Borlander „Das hört sich auf jeden Fall schon mal nach einer ...“
Optionen

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.

bei Antwort benachrichtigen
Nutellageil ABatC „In eine externe Datei exportieren kann das Programm die ...“
Optionen

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...

bei Antwort benachrichtigen
ABatC Nutellageil „Das ist noch nicht ganz was ich suche. Da passiert mir zu ...“
Optionen
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...

bei Antwort benachrichtigen
Borlander Nutellageil „Das ist noch nicht ganz was ich suche. Da passiert mir zu ...“
Optionen
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…

bei Antwort benachrichtigen
ABatC Borlander „Wenn Du einzelne Dateien einfach so verteilen willst, dann ...“
Optionen

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.

bei Antwort benachrichtigen
Borlander ABatC „Weiterhin sollte man berücksichtigen, das auch die ...“
Optionen
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

bei Antwort benachrichtigen
ABatC Borlander „Klar. Hash-Verfahren mit hoher Kollisionswahrscheinlichkeit ...“
Optionen
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 :-)

bei Antwort benachrichtigen
Borlander ABatC „Es gibt durchaus noch einige Bereiche in denen ...“
Optionen
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

bei Antwort benachrichtigen
ABatC Borlander „Da kann ich mich nun spontan aber an keinen einzigen Fall ...“
Optionen

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 :-)

bei Antwort benachrichtigen
Nutellageil Borlander „Wenn Du einzelne Dateien einfach so verteilen willst, dann ...“
Optionen
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.

bei Antwort benachrichtigen
Borlander Nutellageil „Was ich jetzt gelesen habe ist ZFS das sicherste für ...“
Optionen
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…

bei Antwort benachrichtigen
Nutellageil Borlander „Wenn Du Genug Zeit hast, dann könntest Du das sicherlich ...“
Optionen
Dieser Beitrag ist gelöscht!
Dieser Beitrag wurde versehentlich doppelt abgesendet. Deshalb wurde das Duplikat gelöscht und nur das Original beibehalten.
Nutellageil Borlander „Wenn Du Genug Zeit hast, dann könntest Du das sicherlich ...“
Optionen

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 !              ?

http://www.welt.de/wirtschaft/webwelt/article1202176/Warum-ein-Anruf-bei-Microsoft-85-68-Euro-kostet.html

bei Antwort benachrichtigen
Borlander Nutellageil „Was ist IFS und wie ein etwa richtet man das ein? ...“
Optionen
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.

bei Antwort benachrichtigen