[Gispelmob]

Bisher nutzte ich die Konsolen-Version von exactfile um Checksummen in Windows-Batches zu erzeugen. Das klappt auch ganz gut. Nur leider kann dieses Tool weder von Netzlaufwerken (\\Name\Ordner) lesen noch in diese schreiben. Es erzeugt in dem Fall nur eine leere Datei und lässt sich nur mit CTRL-C beenden.

Hat jemand einen Tipp für ein consolenfähiges Tool welches auch innerhalb des Netzwerkes funktioniert?

Dieser Beitrag wurde von Gispelmob bearbeitet: 22. Oktober 2017 - 11:06

[Gispelmob]

FCIV - nur MD5 und SHA1
HashMyFiles - nur MD5/SHA1/CRC32

certutil unterstützt das was ich brauche, ich werde es mal testen

Edit: Die aktuelle RSAT Version läuft nur mit 1709, welches ich noch nicht habe. Die vorherige Version ist nicht zu finden. Also warten ...

Dieser Beitrag wurde von Gispelmob bearbeitet: 21. Oktober 2017 - 09:30

[RalphS]

Wie sieht's denn mit den üblichen Verdächtigen wie md5sum, sha***sum und so weiter aus? Die gibt's als Teil der msys2-Umgebung.

[Gispelmob]

Ich hab es jetzt anders gelöst. excatfile erzeugt die Checksum Datei nun auf dem aktuellen Rechner. Diese wird danach mit copy auf den Server kopiert. So hab ich die Checksummen die ich wollte.

Ist zwar nicht der direkte Weg, aber alles andere wäre umständlicher gewesen. 7z kann zwar auch hashen, das dauert aber viel zu lang.

[Gispelmob]

Nochmal ne Frage.

SHA512 Hash für ein 100GB File dauert ewig. Kann man das irgendwie beschleunigen? Reicht eventuell auch MD5 für solch große Dateien? Was nutzt ihr für welche Dateigrößen? Sind doch einige dabei die Checksummen für große Files erzeugen wenn ich mich nicht irre.

Dieser Beitrag wurde von Gispelmob bearbeitet: 21. Oktober 2017 - 14:51

[RalphS]

Was heißt "reicht"? Was willst Du damit - zu irgendwas wirst Du die Dinger ja vermutlich erstellen wollen?

Prüfsummen laß ich nur berechnen, wenn mir jemand sagt, hier ist ne Datei und das ist die Prüfsumme dazu, dann fütter ich das in DownThemAll! und der sagt mir dann, ja scheiße Datei wurde fehlerhaft übertragen (oder auch nicht).

Prüfsummenerstellung generiert jede Menge Traffic, weil ja im Minimum die gesamte Datei gelesen werden muß. Und dann sind das ja normalerweise mehrere Iterationen. Beschleunigen kann man das mit einem ausreichend großen Cache, damit das nicht alles übers Netzwerkkabel (oder gar WLAN!) muß.

Die paar Mal, wo ich tatsächlich ne Prüfsumme haben wollte für ne größere Datei, hab ich das direkt auf dem Server ausrechnen lassen. Der macht das dann ganz ohne weiteres Zutun. Irgendwann ist das dann schon fertig.


Je nach Ansinnen kannst Du Dir natürlich auch Deine eigene Prüfsummenmethodik überlegen. Wenn dazu nicht die gesamte Datei gelesen werden muß, dann geht das logischerweise schneller. Daß man also nur die ersten (oder letzten) X Bytes berücksichtigt. Oder man nimmt simples CRC oder DES (ja, Single-DES ist gemeint). Hat natürlich kryptographisch keinen Bestand, aber als Prüfsumme in dem Sinn reicht es mehr als aus.

[Gispelmob]

Ja, es geht eigentlich nur darum um zu testen ob die Datei von Rechner auf den Server (und später vom Server auf den Rechner) korrekt übertragen wurde. Kryptographisch ist mir das ganze in dem Fall relativ egal.

Da mir MD5 mit exactfile zu lang dauert, werd ich mal testen wie schnell andere im Vergleich dazu sind.

Dieser Beitrag wurde von Gispelmob bearbeitet: 22. Oktober 2017 - 09:59

[Candlebox]

Ich benutze seit Jahren Hashly.

[Gispelmob]

Das ist in einem ersten Test bei MD5 noch langsamer als alle anderen. Ergebnisse folgen sobald ich ein 100GB File hab.

[RalphS]

Wenn das zu langsam ist, ist der Lesecache zu klein. Größer basteln. Insbesondere muß für sowas RAM verfügbar sein; wenn es davon von vornherein zuwenig gibt, wird das noch noch sehr viel langsamer.

So oder so hat Hashing eine Laufzeit in Abhängigkeit der Informationslänge; 100GB werden entsprechend "etwas" dauern.

Aber da muß man ja nicht zugucken. Alles raufkopieren, einen Job erstellen (egal wie) und denn dann abarbeiten lassen, irgendwann ist das dann schon fertig. Nicht vergessen, die generierten Hashwerte irgendwo anders als auf den Bildschirm zu schreiben.

[Gispelmob]

Ich hab mir eine Batch geschrieben die verschiedene Tools bencht. Da man bei den meisten keinen Cache oder sonstiges einstellen kann, hab ich die Standardeinstellungen gelassen. Hinweise zur Performanceverbesserung einzelner Tools können gemacht werden.

So sieht die Testumgebung aus:

- AMD FX8350.
- 2GB DDR3 1333MHz Speicher
- gelesen von einem RAID10 mit 4 Stück WD5000AAKX 500GB SATA3 Festplatten
- getestet wurden Dateien mit 1GB, 10GB Größe (100GB später)
- es handelt sich in dem Fall um mit 7z auf Ultra gepackte Archive

Zur Berechnung der MD5 Prüfsumme wurden verwendet:

- exf.exe 1.0.1.6 BETA (www.exactfile.com)

- MD5sums 1.2 (www.pc-tools.net)

- FCIV V2.05 (support.microsoft.com/de-de/help/841290/availability-and-description-of-the-file-checksum-integrity-verifier-u)

- CertUtil (woher auch immer das ist, sollte in der Home nicht vorhanden sein, vielleicht hab ich es früher mal installiert oder kam mit VSStudioCommunity)

- withopf md5 (www.withopf.com/tools/md5/)

- f2ko md5 (www.f2ko.de/de/cmd.php/md5)

- Hashly (lafin.de/software.html#hashly)

Resultate in Reihenfolge:

1GB

md5sums - 8 Sekunden
fciv - 8 Sekunden
certutil - 8 Sekunden
f2ko md5 - 8 Sekunden
withopf md5 - 9 Sekunden
exactfile - 12 Sekunden
hashly - 29 Sekunden

10GB

withopf md5 - 1 Minute 17 Sekunden
fciv - 1 Minute 18 Sekunden
md5sums - 1 Minute 19 Sekunden
f2ko md5 - 1 Minute 25 Sekunden
certutil - 1 Minute 41 Sekunden
exactfile - 2 Minuten 4 Sekunden
hashly - 2 Minuten 46 Sekunden

100GB fehlen noch, die Reihenfolge könnte sich dort erneut ändern.

Für mich sieht es derzeit nach einem Umstieg von exactfile zu fciv oder md5sums aus. Die bringen die besten Ergebnisse.

Dieser Beitrag wurde von Gispelmob bearbeitet: 22. Oktober 2017 - 14:29

[RalphS]

Den Dateisystemcache stellt man direkt am Dateisystem ein. Wobei ich bei Windows grad passen müßte, wo man da genau gegentreten muß. Im Zweifel auf die Speicherverteilung schauen und gucken, was dem Dateisystemcache zugeteilt ist und ob das überlastet ist oder ob es ggf woanders hakt.

Ansonsten, klar, jeder darf natürlich Hashalgorithmen implementieren wie er will und bei den einen ist das dann performanter und bei den anderen nicht. Aber auf die paar Sekunden... naja, gut, wenn man endlos viele Dateien hat, die alle eine Prüfsumme kriegen sollen. Okay. Für ein paar wenige interessiert das aber nicht.

Certutil ist Teil von ADCS. Wenn es nicht da ist, sollten die Zertifikatsdienstverwaltungstools aus RSAT helfen, bzw die entsprechende Komponente auf dem Server. Note: wenn man unter 10 RSAT installiert, werden automatisch alle Tools daraus aktiviert; bis 7 oder so muß man das selber machen.

Wobei certutil irgendwie komische Ausgaben schreibt. Kann das Format auch irgendwer lesen? Ansonsten würd ich da was anders nehmen. Lieber hab ich ne Prüfsumme nach Schema

d41d8cd98f00b204e9800998ecf8427e  d1.text
d41d8cd98f00b204e9800998ecf8427e *d2.binary

ne Viertelsekunde später, als daß ich mich mit irgendwelchen Hashcodes rumärgern muß, weil die erstmal aus dem Ausgabetext rausgefischt und irgendwie den richtigen Dateien zugeordnet werden müssen.

PS. Unter anderem Robocopy kann beim Kopieren prüfen. Spart man sich die Prüfsummen, jedenfalls dann, wenn man nicht zu oft kopieren und verifizieren will. "Normal" sind Hashwerte eigentlich nur sinnvoll, wenn man die zugehörige Datei öffentlich bereitstellen will, muß dann aber dafür sorgen, daß Datei und Hashwert auf unabhängigen Systemen gespeichert sind (auch wenn das heutzutage kaum einer mehr macht).

[Candlebox]

Zitat (RalphS: 22. Oktober 2017 - 12:37)

"Normal" sind Hashwerte eigentlich nur sinnvoll, wenn man die zugehörige Datei öffentlich bereitstellen will, muß dann aber dafür sorgen, daß Datei und Hashwert auf unabhängigen Systemen gespeichert sind (auch wenn das heutzutage kaum einer mehr macht).

Ich mag ohne Hashs nicht mehr arbeiten. Meine gerechneten Filmchen in .h264 und h.265 sind da sehr sensibel, wenn da beim kopieren was nicht paßt. Da ist die Datei nämlich mit Bildfehlern für mich unbrauchbar.

Bin da vor zig Jahren mal über ein paar solcher Dateien beim abspielen gestoßen, daß die plötzlich Bildfehler aufwiesen, und die Sicherheitskopie vom Datengrab natürlich auch hinnüber war. Muß wohl beim turnusmäßigen erneuern der Festplatten passiert sein. Seitdem kriegt jedes Filmchen einen Hash, sofort nach dem erstellen und wird mit der .md5-Datei aufs Datengrab geschoben und auch auf der Sicherheitskopie verewigt.

Führe ich nun jedesmal aus, wenn ich meine Platten turnusmäßig tausche.

Zitat (Gispelmob: 22. Oktober 2017 - 12:12)

Für mich sieht es derzeit nach einem Umstieg von exactfile zu fciv oder md5sums aus. Die bringen die besten Ergebnisse.

Ob besser=zuverlässiger ist, würde ich doch glatt mal gegenprüfen, ob die Turbos untereinander auch das jeweils gleiche Ergebnis liefern. Wenn ja, dann schneidet hashly wirklich schlecht ab. Muß ich auch mal schauen, ob ich da vielleicht was an meiner Hashmethode was dran ändere.

[Gispelmob]

So nun meine letzten Benches und die Bewertung

1GB (1,03 GB)

fciv - 00:00:04
withopf md5 - 00:00:04
md5sums - 00:00:07
certutil - 00:00:08
f2ko md5 - 00:00:09
exactfile - 00:00:12
hashly - 00:00:18

10GB (9,69 GB)

fciv - 00:00:52
withopf md5 - 00:00:53
md5sums - 00:00:57
f2ko md5 - 00:01:07
certutil - 00:01:23
exactfile - 00:01:49
hashly - 00:02:30

100GB (91,5 GB)

fciv - 00:10:29
withopf md5 - 00:10:29
f2ko md5 - 00:11:43
certutil - 00:13:39
exactfile - 00:17:11
md5sums - 00:21:59
hashly - 00:23:39

Gesamt für alle 3 Dateien

fciv - 00:11:25
withopf md5 - 00:11:26
f2ko md5 - 00:12:59
certutil - 00:15:09
exactfile - 00:19:12
md5sums - 00:23:03
hashly - 00:26:27

Bewertung der Programme:

exf.exe 1.0.1.6 BETA (www.exactfile.com)

+ verschiedene Optionen für die Kommandozeile
+ viele Hashfunktionen verfügbar (adler32, crc32, md2, md4, md5, sha1, sha256, sha384, sha512, ripemd128, ripemd160, tiger128, tiger160, tiger192, gost)
+ auch als Version mit GUI erhältlich
- relativ langsam
- nur als Windowsversion verfügbar
- kann nicht in Netzlaufwerke schreiben

MD5sums 1.2 (www.pc-tools.net/win32/md5sums/)

+ verschiedene Optionen für die Kommandozeile
+ auch als Linuxversion verfügbar, bzw. ist von dieser abgeleitet
+ erkennt auch Drag & Drop
- kann nur MD5 Hashes berechnen
- bei großen Dateien >10GB relativ langsam

FCIV V2.05

+ sehr schnell
+ verschiedene Optionen für die Kommandozeile
- nur als Windowsversion verfügbar
- nur wenige Hashfunktionen verfügbar (MD5 und SHA1)

CertUtil

+ verschiedene Optionen für die Kommandozeile
+ viele Hashfunktionen verfügbar (MD2, MD4, MD5, SHA1, SHA256, SHA384, SHA512)
+ Schnelligkeit im Mittelfeld
- nur als Windowsversion verfügbar
- muss mit einem Remote Server Administration Tools (RSAT) Pack nachinstalliert werden

withopf md5 (www.withopf.com/tools/md5/)

+ verschiedene Optionen für die Kommandozeile
+ viele Hashfunktionen verfügbar (MD5, HMAC-MD5, SHA1, SHA3_224, SHA3_256, SHA3_384. SHA3_512, Whirlpool)
+ Schnelligkeit gut
- unübersichtliche verwirrende Kommandozeilenparameter mit + und -
- nur als Windowsversion verfügbar

f2ko md5 (www.f2ko.de/de/cmd.php/md5)

+ Schnelligkeit gut
- kann nur MD5 Hashes berechnen
- wenige Optionen für Kommandozeile
- nur als Windowsversion verfügbar

Hashly (lafin.de/software.html#hashly)

+ GUI integriert
- schlecht funktionierende Kommandozeilenparameter, falsche Reihenfolge führt zu Nichtbeachtung der Option
- wenn man die Option -c nicht extra mit angibt, verbleibt das Programm im Speicher
- kein Anhängen der Ausgabe an bestehende Dateien möglich
- nur als Windowsversion verfügbar
- langsamstes Tool im Test

Das Ergebnis meines Tests ist, dass ich meine Batches von exactfile auf fciv umstellen werde.

P.S.:

- Es ging nur um die Messung der Zeit für die Erzeugung von MD5 Prüfsummen.
- Es wurde keine Zeit für die Erzeugung von anderen Prüfsummen gemessen.
- Es wurde keine Zeit der Prüfung der Dateien auf die erzeugten Prüfsummen gemessen.
- Eine eventuell vorhandene GUI wurde nicht genutzt, da die Ausgabe per Batch in eine Datei geschrieben wurde.

Das Ergebnis kann ganz anders aussehen, wenn man die Prüfsummen der Dateien mit den erzeugten Prüfsummen vergleicht oder aber wenn man andere Algorithmen verwendet.

Dieser Beitrag wurde von Gispelmob bearbeitet: 22. Oktober 2017 - 20:48