FAQs


Fragen zur Installation

Warum soll ich Jacksum verwenden und nicht ... ?

Ihre Daten sind unersetzlich. Jacksum hilft Ihnen, die Kontrolle über die Datenintegrität Ihrer Daten zu behalten. Jacksum ist zuverlässig und bietet eine Menge an einzigartigen Merkmalen. Wenn Sie schlau sind, vergleichen Sie die Funkionen von ähnlichen Tools mit denen von Jacksum. Dann können Sie die Frage selbstsicher beantworten ;-)

 
Was kostet diese Software?

Jacksum ist kostenlos.

 
Wo kann ich diese Software herunterladen ?

Hier
 

Welche Plattformen werden unterstützt ?

Microsoft Windows, GNU/Linux, Mac OS X, Solaris und andere. Siehe Systemanforderungen, Programmeigenschaften und Bildschirmfotos.

 
Wie installiere ich diese Software ?

Lesen Sie bitte die Installationsanweisungen.

Welche Java Version soll ich verwenden?
Jacksum 1.7 läuft mit JRE 1.3.1 und jeder neueren Version. Sie sollten jedoch mindestens JRE 8 verwenden, weil alle öffentlichen Java-Versionen vor Version 8 von Oracle nicht mehr gepflegt werden.


[Ubuntu] Ich möchte die Java Laufzeitumgebung von Oracle statt das Open JDK verwenden. Wie kann ich das unter Ubuntu machen ?

Laden Sie sich das Oracle JRE von java.com herunter und installieren Sie es, z. B. nach

/opt/java/jre/64/latest8

Anschliessend starten Sie update-alternatives. Siehe auch https://help.ubuntu.com/community/Java

$ sudo update-alternatives --install "/usr/bin/java" "java" "/opt/java/jre/64/latest8/bin/java" 1
$ sudo update-alternatives --config java



Fragen zur Benutzung

Ich habe ein Problem mit Jacksum. Können Sie mir helfen?

Lesen Sie bitte die Seite Unterstützung.


Gibt es eine graphische Oberfläche für Jacksum?

Zusätzlich zum Kommandozeileninterface unterstützt das Jacksum Projekt auch die Integration in die berühmten Dateibrowser Windows Explorer, KDE Konqueror, Gnome Nautilus, ROX-Filer und Finder auf Mac OS X.

Jacksum's primäre Benutzerschnittstelle ist die Kommandozeile. Sie unterstützt die Kompatibilität mit anderen populären auf der Kommandozeile basierten Programmen unter Unix, wiecksum, sha1sum, sum oder md5sum. Jacksum wird stets das Kommandozeileninterface unterstützen, da es den Einsatz des Programms mit Cronjobs und Pipesermöglicht und seine Möglichkeiten in Kombination mit anderen nützlichen kommandozeilenbasierten Tools wie grep, sort, unique oderzip voll ausspielen kann und eine Integration in Ihrem bevorzugtem Browser möglich macht.

Jacksum unterstützt auch ein öffentliches API. Es kann vonanderen Projekten und graphischen Benutzeroberflächen benutzt werden.
Siehe auch "Kann ich Jacksum in meinem Projekt verwenden?" und "Software, die Jacksum verwendet"

Was bedeuten die Werte in der Ausgabe von Jacksum?
z. B.
599770357    23560    irgendein.txt

Die erste Zahl gibt die Prüfsumme an. Die Prüfsumme hängt ab vom verwendeten Algorithmus (-a) und vom hex-Schalter (-x, bzw. -X).
Die zweite Zahl gibt i. d. R. die Größe der Datei in bytes an. Ausnahmen sind bsd sum und UNIX system V sum. Sie geben die Größe der Datei in Blöcken an. Die Größe entfällt gänzlich bei den Hash-Algorithmen (SHA* oder MD*). Die dritte Spalte (zweite Spalte bei den Hash-Algorithmen) gibt den Dateinamen mit oder ohne Angabe des Pfades an. Der Dateiname entfällt, wenn die Standardeingabe gewählt wurde.

Seit Jacksum 1.3.0 gibt es die Möglichkeit, Zeitstempel von Dateien mit auszugeben. In diesem Fall erscheint eine zusätzliche Spalte in jeder Zeile (vor dem Dateinamen). Die Bedeutung des Zeitstempels ist abhängig vom Format, das mit der Option -t gesetzt werden kann.

599770357    23560    20031027140042     irgendein.txt


Es scheint, dass Jacksum falsch rechnet, wenn von der Standardeingabe gelesen wird?

Jacksum 1.7.0 und frühere Versionen operieren im Textmodus, falls die Standardeingabe verwendet wird. Die nächste Hauptversion, Jacksum 2.0.0 wird standardmäßig im Binärmodus operieren, falls Standardeingabe verwendet wird. Sehen Sie dazu also den Feature Request #11: https://sourceforge.net/p/jacksum/feature-requests/11/ (Read binary rather than text from standard input).


Welchen Algorithmen soll ich verwenden?

Mit der Option -a können Sie einen von mehreren Algorithmen wählen. Wenn Sie eine Datei von einer vertrauenswürdigen Seite heruntergeladen haben, und Sie wissen wollen, ob der Dateitransfer erfolgreich war, können viele Algorithmen gewählt werden. Um Ihre Daten jedoch auf Integrität zu überprüfen (Option -c) ist nicht jeder Algorithmus empfehlenswert, vor allem bei der Vielzahl von Dateien auf heutigen Festplatten.

Abzuraten:
Vom kryptographischen Standpunkt aus, ist die Verwendung der reinen Prüfsummenalgorithmen wie sum8, sum16, sum24, sum32 und xor8 abzuraten, da sie die Reihenfolge der Bytes unberücksichtigt lassen. Gebrochen wurden bereits auch MD2 und MD4. Auch sie sollten zur Überprüfung der Datenintegrität nicht mehr verwendet werden (u. a. werden sie auch von der RSA nicht mehr empfohlen). SHA-0 sollte ebenfalls nicht mehr verwendet werden, er wurde im Jahr 1995 durch SHA-1 ersetzt.

Bedingt einsetzbar:
Aufgrund ihrer kurzen Bitlänge und ihrer mangelnden mathematischen Stärke sind CRCs (Adler32, BSD sum, POSIX cksum, CRC-16, CRC-32 (FCS-32), FCS-16, MPEG-2's CRC-32, CRC-64 und die Unix System V sum) zur Integritätsprüfung heutiger Datenmengen nur bedingt einsetzbar - Ausnahmen bestätigen wie immer die Regel. Siehe auch den CRC-Faker (der Link http://www.crc2003.250x.com ist nicht mehr gültig, verwenden Sie die Waybackmachine, um das Tool zu finden) und lesen Sie den Artikel "CRC and how to Reverse it" (der Link http://surf.to/anarchriz ist nicht mehr gültig, verwenden Sie eine Suchmaschine, um das Dokument zu finden). Ein Virus könnte Dateien geschickt manipulieren - mit einem CRC basierten Algorithmus könnten dann solche Anschläge nicht entdeckt werden. Obwohl Jacksum SFV bei Bedarf erzeugen kann, ist empfohlen, die Verwendung von SFV-Dateien zu vermeiden. Sie basieren auf CRC32 Werten und SFV ignoriert die Dateigröße komplett.

Bedingt zu empfehlen:
ELF-32 ist ein einfacher hash-basierter Algorithmus, der jedoch nicht die Bitstärke hat, um sehr sichere Datenintegrität zu garantieren. Der Algorithmus ed2k/eMule/eDonkey (basiert auf einem verbesserten MD4) ist ebenfalls hash-basiert und würde genug Bits haben, jedoch sind für MD5 und HAVAL_3_128 bereits im August 2004 reale Kollisionen bekannt worden (http://eprint.iacr.org/2004/199/) - mit Hilfe einer non-brute force Methode. Das Dokument erwähnt auch Kollisionen für RIPEMD-128, jedoch generiert das als Hexdump abgedruckte Beispiel keine Kollision (während alle anderen Beispiele im Dokument verifiziert werden konnten, scheint das RIPEMD Beispiel einen Tippfehler zu haben. Beachten Sie, daß RIPEMD-256 so sicher ist wie RIPEMD-128 und deswegen ebenfalls nicht mehr empfohlen werden kann. Tiger/128 und Tiger/160 sind tatsächlich abgeschnittene Hash-Funktionen von Tiger/192. Obwohl sie heute als sicher gelten, sind nicht-abgeschnittene Hashes zu bevorzugen.

SHA-1
Im Februar 2005 veröffentlichte der Sicherheitsspezialist Bruce Schneier eine von Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu umrissenen Attacke auf SHA-1. Die Autoren beschreiben, daß Ihre Attacke Kollisionen in der Vollimplementierung von SHA-1 finden könnte. Diese benötigte weniger als 269 Operationen (eine Brute-Force Suche würde 280 Operationen erfordern). In der akademischen Kryptographie wird jede Attacke, die weniger Berechnungsaufwand erfordert als der zu erwartende Zeitaufwand bei Brute-Force, als "Break" bezeichnet. Diese bedeutet aber jedoch nicht notwendigerweise, daß eine Attache auch praktisch durchgeführt werden kann. In der wirklichen Welt ist SHA-1 ist immer noch sicher, zumindest um Datenintegrität zu überprüfen. Für die neuesten Erkenntnisse der Kryptoanalyse von SHA-1 empfehle ich http://en.wikipedia.org/wiki/SHA1#Cryptanalysis_of_SHA-1.

Zu empfehlen:
Vom heutigen kryptographischen Standpunkt aus betrachtet (Februar 2016), sind folgende Ein-Wege-Hash-Algorithmen für die Überprüfung der Dateiintegrität zu empfehlen: HAVAL-{3/4/5}-{160/192/224/256}, RIPEMD-160, RIPEMD-320, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, Tiger, Tiger2 und Whirlpool (2te Revision). Jacksum unterstützt alle hier angeführten Algorithmen. Seit Jacksum 1.5.0 ist SHA-1 der Default-Algorithmus.

Seit Jacksum 1.7.0 können mehrere Algorithmen kombiniert werden. Ich empfehle mindestens zwei unterschiedliche Techniken für die Dateiintegritätsprüfung zu verwenden, einen Hash-Algorithmus wie z. B. SHA-1 und einen CRC wie z. B. CRC32 bilden eine gute Kombination für diesen Zweck. Auch wenn eine Kollision in der Zukunft für den hash-basierten Algorithmus festgestellt werden sollte, ist es sehr unwahrscheinlich, daß auch der CRC in diesem Fall identische Werte zurückliefert.

Warum gibt es alternative Implementierungen für die Algorithmen ?

Einige Algorithmen (adler32, crc32, md5, sha-1) sind fester Bestandteil des Standard Java API. Andere wiederum (sha-256, sha-384, sha-512) sind Teil des Standard Java API neuerer Java Laufzeitumgebungen. Wenn ein Algorithmus von Ihrer Java Laufzeitumgebung unterstützt wird, ruft Jacksum dessen API auf und verwendet dieses Angebot. Einige Hersteller eines JRE rufen nativen Code auf, der üblicherweise eine gute Performance bietet. Beachten Sie jedoch, daß dies die Details der Implementierung der jeweiligen JRE-Hersteller sind, sie können von Hersteller zu Hersteller und sogar von Version zu Version unterschiedlich ausfallen. Wegen einer Vielzahl an Anfragen stelle ich für alle Algorithmen alternative, in purem Java implementierte Algorithmen zur Verfügung. Unter einigen Systemen kann eine alternative Implementierung besser performen als die des JRE-Herstellers (MD5 zum Beispiel), jedoch hängt diese Performance ab von Ihrem Computer und der Java Laufzeitumgebung, die sie einsetzen. Gewöhnlich ist es eine gute Idee, die neueste Java Laufzeitumgebung zu verwenden, und sich auf die Performance zu verlassen, die die JRE bietet. Tests haben gezeigt, daß je neuer Ihre JRE ist, desto besser die Performance. In Einzelfällen bringt der Schalter -A bessere Ergebnisse.


Sind CRCs heute nicht überflüssig?

Nein, CRCs werden immer noch in Hardware, Firmware, Protokollen, einfachen Software-Installern (NSIS zum Beispiel) und modernen Dateisystemen (zfs) verwendet. In der Regel sind sie sehr schnell (und nicht so komplex wie ein Einweg-Hash-Algorithmus), sie sind sinnvoll um kleine Dateneinheiten zu überprüfen. Des weiteren sind sie eine gute Ergänzug zu hash basierten Algorithmen. Jacksum unterstützt außerdem das Model "Rocksoft (tm) Model CRC Algorithm", welches es möglich macht, benutzerdefinierte CRCs zu berechnen.


Wie wird ein CRC berechnet?

Viele Leute haben mich diese Frage bereits gestellt. Es gibt ein paar gute Webseiten, die genau erklären wie CRC berechnet wird. Besuchen Sie http://surf.to/anarchriz oder ftp://ftp.rocksoft.com/papers/crc_v3.txt. Sie könnten auch einen Blick auf den Sourcecode von Jacksum werfen.


Unterstützt Jacksum den CCITT checksum Algorithmus ?

Viele Referenzen definieren den CRC-16/CCITT als

    crc:16,1021,FFFF,false,false,0

Die Notation "crc:width,poly,init,refIn,refOut,xorOut" wird seit Jacksum 1.7.0 verwendet, um einen CRC Algorithmus entprechend dem "Rocksoft(TM) Model CRC Algorithm" zu definieren. Verwendet man die Nachricht "123456789", liefert der CRC Algorithmus mit den obigen Parametern den Wert 0x29B1:

  jacksum -q txt:123456789 -X -a crc:16,1021,FFFF,false,false,0
  29B1

Andere Quellen behaupten jedoch, daß der entsprechend des CCITT Standards (siehe oben), einer Nachricht vor der Berechnung zuerst 16 Null-Bits vorgeschaltet werden müssten. Diese Interpretation des Standards kann wie folgt ausgedrückt werden:

    crc:16,1021,1D0F,false,false,0

Beachten Sie, daß in diesem Fall nur der Initialwert unterschiedlich ist, da eine 16 Null-Bit Nachricht durch einen CRC mit dem Initialwert 0xFFFF berechnet, die Prüfsumme 0x1D0F zurückliefert, die wiederum dem Initialwert für die alternative Interpretation des Algorithmus entspricht.

Verwendet man die Nachricht "123456789" , liefert der CRC Algorithmus mit den obigen Parametern den Wert 0xE5CC:

  jacksum -q txt:123456789 -X -a crc:16,1021,1D0F,false,false,0
  E5CC

Es ist nun vollkommen Ihnen überlassen, welchem CCITT Standard Sie glauben ;)
Jacksum kann beide Algorithmen berechnen (und auch jede andere Interpretation dieses "Standards").
 

Welche Algorithmen werden von Jacksum nicht unterstützt?

Es gibt einige Algorithmen, die Jacksum (noch) nicht unterstützt. Dazu gehören Cellhash, Boognish, DHA-256 (relativ neu), FEAL (patentiert), FFT-hash, FORK-256 (ziemlich neu), Panama (broken), Snefru (broken), DSS1, MAA (Message Authenticator Algorithm, broken), MDC2 (Patent abgelaufen), Maelstrom-0, Maelstrom-1, Maelstrom, N-Hash (patentiert und unsicher), PMD-N, PMD-V, PMD-128, PMD-160, PMD-192, PMD-224, PMD-256 (koreanische Standards, keine komplette englische Dokumentation vorhanden), VEST-4, VEST-8, VEST-16, VEST-32 (Patent schwebend), VSH (relativ neu) und die VMS/VAX checksum (sehr wenig Information verfügbar). Wenn Sie Sourcecode zu diesen Algorithmen (vorzugsweise in Java) besitzen und mir senden, werde ich auch diese in Jacksum aufnehmen. Beachten Sie, daß die meisten dieser Algorithmen schon etwas älter und nicht wirklich kryptographisch stark sind, für die meisten von ihnen sind bereits Kollisionen bekannt worden (bzw. lassen sich zu leicht berechnen), jedoch sind die Algorithmen auf meiner Wunschliste für Lehrzwecke und der Vollständigkeit halber. Die Implementierung der Algorithmen aus der offiziellen SHA-3-Submission fehlen ebenfalls noch, da noch nicht klar ist, welche Algorithmen wirklich hart genug sind, um die SHA-2-Familie auf längere Sicht hin ablösen zu können.
 

Mein Freund hat einen PC von dem ich denke, dass er gehackt wurde, aber ich habe keine andere Maschine, um diese miteinander zu vergleichen ...

Die Prüfsummen der gängigsten UNIX/Linux-Derivate fanden Sich bis Dezember 2006 hier: http://www.knowngoods.org
Für Solaris gab es den Service von Sun auf http://sunsolve.sun.com/pub-cgi/fileFingerprints.pl bis im Jahr 2010 Oracle Sun Microsystems übernommen hatte.
Für Windows habe ich damals wie heute keinen äquivalenten Service gefunden.
 

Wie kann ich Verzeichnisse synchronisieren?

Mit Hilfe von Jacksum kann eine unidirektionale Synchronisation durchgeführt werden, d. h. Jacksum kann Veränderungen auf einem Rechner erkennen und diese Veränderungen rückgängig machen, bzw. diese Veränderungen auf andere Rechner anwenden. Diese Synchronisation klappt sogar, wenn keine Verbindung zwischen den beiden Rechnern besteht. Gehen wir davon aus, Sie haben einen fehlerfreien und einen fehlerhaften Computer.

Beispiel für Windows:
1. Wechseln Sie in das fehlerfreie Verzeichnis auf Ihrem fehlerfreien Computer und führen Sie folgende Kommandos aus:
  cd good
  jacksum -a sha1 -m -r . > c:\temp\check.jacksum

2. Die Datei check.jacksum repräsentiert eine Momentaufnahme aller Dateien des fehlerfreien Computers im fehlerfreien Verzeichnis.
   Transferieren Sie die Datei check.jacksum anschliessend zum fehlerhaften Computer.

3. Wechseln Sie in das fehlerhafte Verzeichnis auf dem fehlerhaften Computer und führen Sie folgende Kommandos aus:
  cd faulty
  jacksum -c c:\temp\check.jacksum -l > c:\temp\files.list

4. Die Datei files.list enthält nun eine Liste der Unterschiede zwischen dem fehlerfreien und dem fehlerhaften Verzeichnis.
    Transferieren Sie die Datei files.list nun zum fehlerfreien Computer.

5. Wechseln Sie in das fehlerfreie Verzeichnis auf Ihrem fehlerfreien Computer und führen Sie folgende Kommandos aus:
  cd good
  type list.txt | zip -@ patch.zip

    Für den Fall, daß Sie .tar.bz2 anstelle von .zip bevorzugen:
  cd good
  tar cfv patch.tar -I files.list
  bzip2 -9 patch.tar

6. Die Datei patch.zip enthält nun alle Dateien des fehlerfreien Computers, die auf dem fehlerhaften Computer modifiziert oder gelöscht wurden. Transferieren Sie die Datei patch.zip zum fehlerhaften Computer und extrahieren Sie die im zip enthaltenen Dateien ins fehlerhaften Verzeichnis. Die Dateien im zip überschreiben die Dateien des fehlerhaften Verzeichnisses und aus dem fehlerhaften Computer wurde ein fehlerfreier Computer.
 

Wie erstelle ich einen Patch mit Jacksum?

Als Entwickler könnten Sie Ihren Treuekunden einen Patch für Ihre Version zur Verfügung zu stellen. Jacksum kann Ihnen hier behilflich sein.

Beispiel für Unix:
1. Wechseln Sie in das Verzeichnis der neuen Version und führen Sie folgende Kommandos aus:
  cd ~/newversion
  jacksum -a sha1 -m -r . > /tmp/check.jacksum

2. Wechseln Sie in das Verzeichnis der alten Version und führen Sie folgende Kommandos aus:
  cd ~/oldversion
  jacksum -c /tmp/check.jacksum -l > /tmp/files.list

3. Wechseln Sie erneut in das Verzeichnis der neuen Version und packen Sie die neuen und überarbeiteten Dateien in die Datei patch.zip
  cd ~/newversion
  tar cfv patch.tar -T /tmp/files.list   (GNU/Linux, Mac OS X, PC-BSD)
  tar cfv patch.tar -I /tmp/files.list   (PC-BSD, Solaris)
  bzip2 -9 patch.tar

    Für den Fall, daß Sie .zip anstelle von .tar.gz den Vorzug geben:
  cd ~/newversion
  cat /tmp/files.list | zip -@ patch.zip (GNU/Linux, Mac OS X, Solaris)

Vielen Dank an Girish Narang, mit dem ich eine "Patch-Erstell-Lösung" mit Hilfe von Ant entwickelt habe. Laden Sie das Ant script und das zugehörige property file herunter, um Patches mit Jacksum und Ant zu erzeugen.
 

Ist es möglich, zwei Verzeichnisse zu überprüfen?

Ja, seit Jacksum 1.3.0 können Sie die Option -c benutzen, um Dateien gegen eine gegebene Liste zu überprüfen. In diesem Fall werden Sie exakt wissen, welche Dateien modifiziert oder gelöscht wurden. Sie erzeugen eine solche Liste mit der Option -m. Siehe dazu die Beispiele in der Dokumentation.

Alternativ dazu, führen Sie die folgende Befehlssequenz bei beiden zu überprüfenden Verzeichnissen durch. Dabei ist es wichtig, dass Sie in das jeweilige Verzeichnis mit cd wechseln:

cd <zu überprüfender Verzeichnisbaum>
jacksum -r -f -a sha1 . | jacksum -a sha1 -

Wenn beide Prüfsummen übereinstimmen, wissen Sie, dass beide Verzeichnisse (einschließlich Unterverzeichnisse) identisch sind. Mit diesem Trick lässt sich z. B. auch überprüfen, ob eine gebrannte CD-[R/RW] oder DVD-[R/RW] auch wirklich das enthält, was man brennen wollte. Erinnern Sie sich, die Option -c gibt eine wesentlich genauere Auskunft über Veränderungen in einem Dateibaum.
 

Warum erhalte ich unterschiedliche Fingerprints mit -S, obwohl die Verzeichnisse wirklich gleich sind?

Es macht einen Unterschied, ob Sie eine Prüfsumme auf beispielsweise c:\daten oder d:\daten berechnen, weil Jacksum diesen Unterschied mit berücksichtigt. Wenn Sie nicht wollen, daß Jacksum diese (absolute) Pfadinformation berücksichtigt, die sie an der Kommandozeile angegeben haben, müssen Sie das aktuelle Arbeitsverzeichnis erst wechseln. Ich empfehle relative Pfade wie "daten" (wenn das aktuelle Verzeichnis c:\ ist) oder "." (wenn das aktuelle Verzeichnis c:\daten is), statt "c:\data" anzugeben. Wenn Sie auf d: die Berechnung durchführen, müssen Sie die gleichen Parameter verwenden, wie Sie sie bereits für c: verwendet haben. Siehe auch Feature Request #1028816.

Falsche Erwartung - alle Prüfsummen werden unterschiedlich sein:
jacksum -a sha1 -S c:\data
jacksum -a sha1 -S d:\data
jacksum -a sha1 -S d:\backup\data

Richtige Verwendung - die Parameter sind bei allen Berechnungen identisch, alle Prüfsummen werden gleich sein (vorausgesetzt, daß die Verzeichnisse wirklich gleich sind):

jacksum -a sha1 -S -w c:\data
jacksum -a sha1 -S -w d:\data
jacksum -a sha1 -S -w d:\backup\data

ODER

c:
cd \data
jacksum -a sha1 -S .

d:
cd \data
jacksum -a sha1 -S .

cd \backup\data
jacksum -a sha1 -S .
 

Warum erhalte ich unterschiedliche Fingerprints mit -S unter Windows und Linux?

Ich habe eine Share-Partition. Sie ist als FAT32 formatiert, damit ich auf meine Dateien sowohl von Linux als auch von Windows aus zugreifen kann. Wenn ich die Option -S benutze, bekomme ich unterschiedliche Prüfsummen unter Linux und Windows. Was ist da falsch?

Gewöhnlich passiert das, wenn Sie suboptimale Mountoptionen verwenden. Wenn Ihre Share-Partition als "vfat" unter Linux gemountet ist, sollten Sie auch die Mountoption namens "shortname" spezifizieren. Sie definiert das Verhalten für das Erzeugen und die Anzeige von Dateienamen, die in das 8+3 Zeichenschema passen. Diese Mountoption ist nötig, da Jacksum bei der Verwendung der Option -S auch die Dateinamen und Verzeichnisse in die Prüfsequenz mit einrechnet. Für mehr Informationen lesen Sie "man mount". Alternativ zu -S können Sie auch die Optionen -m und -c benutzen, um Dateien plattform- und mountoptionunabhängig zu verifizieren.
 

Fehlermeldungen

Ich erhalte den Fehler "java.io.IOException: Datenfehler (CRC-Prüfung)". Was bedeutet das?

Das ist ein Fehler, den das deutsche Windows (NT basierend) meldet und er bedeutet, daß Windows nicht mehr in der Lage ist, von Ihrem CD-ROModer DVD-Laufwerk eine Date zu lesen. Sie sollten Ihre Dateien auf einen neuen Datenträger sichern, um weitere Datenverluste zu vermeiden.Unter Linux heißt der Fehler entsprechend "java.io.IOException: Input/output error" (Beispiel Red Hat).


[Windows] Beim Versuch mit einem normalen Benutzer auf jacksum-sendto.bat (aus der Jacksum Windows Explorer Integration) zuzugreifen, erhalte ich die Fehlermeldung "Auf das angegebene Gerät, bzw. den Pfad oder die Datei kann nicht zugegriffen werden. Sie verfügen eventuell nicht über ausreichendeBerechtigungen, um auf das Element zugreifen zu können."

Das kann unter NTFS formatierten Systempartitionen passieren. Die Fehlermeldung sagt, daß der Benutzer nicht die nötigen Rechte besitzt, die Batch-Datei auszuführen. Als Administrator des Systems können Sie aber jacksum-sendto.bat die nötigen Lese- und Ausführungsrechte für normale Benutzer geben. Das geht i. d. R. am einfachsten, wenn man als Administrator die jacksum-sendto.bat Datei kopiert, die originale Datei löscht und die Kopie von jacksum-sendto.bat wieder nach jacksum-sendto.bat umbenennt. Falls das nicht klappt, müssen Sie als Administrator das NTFS-Rechtemanagement von Windows bemühen.


[GNU/Linux, Unix] Ich erhalte bash: !": event not found

jacksum -a crc32 -q "txt:Hello World!" gibt mir:
bash: !": event not found

Dies ist ein Problem der Bash shell. Das Ausrufezeichen ! in der Bash hat eine spezielle Bedeutung (die auch geändert werden kann), es symbolisiert den "history expansion character". Die Störung ist auch mit echo reproduzierbar.

$ echo "!"
bash: !: event not found

$ echo "\!"
\!

$ echo \!
!

Die korrekte Verwendung ist daher

jacksum -a crc32 -q "txt:Hello World"\!
472456355    12

jedoch ist diese Syntax nicht sehr komfortabel. Zum Glück können einfache Hochkomma verwendet werden, um das Problem elegant zu lösen::

$ echo '!'
!

jacksum -a crc32 -q 'txt:Hello World!'
472456355    12

Siehe auch die Manpage der Bash "Enclosing characters in single quotes preserves the literal value of each character whithin the quotes".
 

Fragen von Entwicklern

Gibt es irgendwelche Codebeispiele wie man Jacksum in einem anderen Projekt verwenden kann?

Ja, einer der grundlegenden Codeschnipsel ist hier:
 


   import java.io.*;
   import java.security.*;
   import jonelo.jacksum.*;
   import jonelo.jacksum.algorithm.*;
   // ...

   AbstractChecksum checksum = null;
   try {
     // select an algorithm (md5 in this case)
     checksum = JacksumAPI.getChecksumInstance("md5");
     // On some systems you get a better performance for particular
     // algorithms if you select an alternate algorithm (see also option -A)
     // checksum = JacksumAPI.getChecksumInstance("md5", true);
   } catch (NoSuchAlgorithmException nsae) {
     // algorithm doesn't exist
   }

   // updates the checksum with the content of a file
   try {
     checksum.readFile(filename);
   } catch (IOException ioe) {
     // ...
   }
   System.out.println(checksum);
 

Die update-Methoden können verwendet werden, um das Checksum-Objekt mit bytes oder bytearrays zu aktualisieren:
 


   // reset the object for reuse (any formatting rules remain)
   checksum.reset();
   // update the checksum with a single byte
   checksum.update(abyte);
   // update the checksum with a bytearray
   checksum.update(bytearray);
   // update the checksum with the first 10 bytes in the bytearray
   checksum.update(bytearray, 0, 10);

   System.out.println(checksum);

Um zu erfahren, welche Algorithmen unterstützt werden, verwenden Sie das folgende Snippet. Wenn Sie JSE 5.0 oder neuer verwendet, können Sie Generics einsetzten, um Castings zu vermeiden.
 


   Map map = JacksumAPI.getAvailableAlgorithms();
   Iterator iterator = map.entrySet().iterator();
   while (iterator.hasNext()) {
       Map.Entry entry = (Map.Entry)iterator.next();

       String description = (String)entry.getValue();
       // do something with the description
       // ...

       AbstractChecksum checksum = JacksumAPI.getChecksumInstance((String)entry.getKey());
       // do something with the checksum object
       // ...
   }
 

Um das Ausgabeformat zu bestimmen, können Methoden auf dem checksum Objekt angewendet werden:
 


   // checksum is printed in hex form (see also option -x)
   // example: 7d93370d5ef94450151826ca20c6e512
   checksum.setEncoding(HEX);

   // checksum is printed in uppercase hex form (see also option -X)
   // example: 7D93370D5EF94450151826CA20C6E512
   checksum.setEncoding(HEX_UPPERCASE);

   // checksum is printed in uppercase hex and grouped form (see also options -g, -G)
   // example: 7D93-370D-5EF9-4450-1518-26CA-20C6-E512
   checksum.setEncoding(HEX_UPPERCASE);
   checksum.setGrouping(2, '-');

   // checksum is printed in Base 64 form (see also option -E)
   // There is also BASE16 and BASE32
   // example: fZM3DV75RFAVGCbKIMblEg==
   checksum.setEncoding(BASE64);

   // checksum is printed in BubbleBabble form (see also option -E)
   // example: xizen-fetab-tilaz-necuh-buhyc-mynys-pemes-kunyc-daxox
   checksum.setEncoding(BUBBLEBABBLE);
 

Das Ausgabeformat einer kompletten Zeile kann z. B. mit der format Methode beeinflußt werden:
 


   // print the checksum, the default output format depends on the algorithm
   System.out.println(checksum);

   // print the checksum, the default output format depends on the algorithm
   checksum.setSeparator(";");
   System.out.println(checksum);

   // print the checksum value only (see also option -F)
   System.out.println(checksum.format("#CHECKSUM"));

   // print the checksum value with a customized format (see also option -F)
   System.out.println(checksum.format("<a href=\"ed2k://|file|#FILENAME|#FILESIZE|#FINGERPRINT|\">#FILENAME</a>"));
 

Obiges Beispiele sollen lediglich als kleine Hilfe dienen, die ersten Hürden zu nehmen. Für detaillierte Informationen über alle Möglichkeiten mit Jacksum, schauen Sie bitte in den Open Source Code oder erzeugen Sie sich javadoc mit Hilfe des Ant-Scripts.


Was ist für die nächsten Versionen geplant?

Ich habe immer noch eine Menge an neuen Ideen für Jacksum und einige brilliante Verbesserungsvorschläge von anderen Leuten rund um den Globus für das Jacksum Projekt. Keine dieser Ideen wird vergessen werden, aber es dauert seine Zeit, sie zu implementieren, zu testen, zu optimieren und sie zu dokumentieren. Die folgende Liste behandelt die Top-Ten Anfragen, die für die nächsten Versionen geplant sind (unsortiert, nur englisch):

- Identify extra data (files and/or directories) that have been added to the target location during a comparison operation,
  thanks to John D. for the feature request and thanks to Dipl.-Inf. (FH) Ralf Kahrl for the reference implementation!
- a new API suggestion which could be used by both the CLI and a GUI.
  Thanks to Stephan Classen, Sibylle Dürr, Barbara Keller, Audrey Lim and Judith Rüesch
  for working on it as part of their IT-project at the ETH Zürich, Switzerland
- A Swing GUI for Jacksum (maybe a separate project)
- HMAC support for the algorithms
- Read files from a list
- Distinguish between missing files versus files that are different also if option -l is used
- CRCs with 1-7 bit length
- Tree Hash for more algorithms
- Filter for processing particular files only
- Performance support for boxes having multiple CPUs and/or cores
- Filesystem specific file attributes (see also JSR 203)
- New algorithms


 

Lizenzrechtliche Fragen


Welche Lizenz verwendet Jacksum?

Das komplette Programm veröffentliche ich unter den Bedingungen der GPL v2 und neuer, so daß jeder auf dieser Welt dieses Programm kostenlos, frei und uneingeschränkt nutzen kann.

Warum die GPL ?

Die GPL stellt sicher, daß das Programm auch frei bleibt und gewisse Freiheiten garantiert werden. Die GPL besagt, daß wenn Sie eine eigene Erweiterung bzw. Änderung gemacht haben, und diese veröffentlichen, diese ebenfalls unter die GPL stellen müssen. So ist sichergestellt, dass der Nährboden des Wissens stets fruchtbar, d. h. quelloffen bleibt und auf ihm neue Früchte gedeihen können.


Kann ich Jacksum in meinem Projekt verwenden?

Ja, vorausgesetzt Sie respektieren die Freiheit von Feier Open Source und akzeptieren die Bedingungen der GNU GPL. Es ist untersagt, Jacksum in properitärer Software zu verwenden ("kommerziell" und "proprietär" ist nicht das selbe!), die Arbeit als die Ihre auszugeben ist ebenfalls untersagt. Machen Sie doch selbst mit bei Freier Open Source, dann sind sich auch herzlich eingeladen, am Erfolg von Open Source Software teilzunehmen.


Darf ich den Namen Jacksum für mein eigenes Projekt verwenden?

Der Name Jacksum ist meine persönliche Wortneuschöpfung und er existiert öffentlich seit Juli 2002. Der Name Jacksum ist urheberrechtlich geschützt und ich bitte das zu respektieren. Jacksum's source code steht hingegen unter den Bedingungen der freien Open Source Lizenz GPL jedermann zur Verfügung.


Darf das Programm auf Datenträgern (z. B. CD-ROM oder DVD) verbreitet werden?
Ja, gerne.


Download

Glanzpunkte



Das Team


Die Liste von Mitwirkenden finden Sie stets im neuesten Download und in der Copyright Sektion. Der Gründer und Leiter dieses Projektes ist Johann N. Löfflmann aus Deutschland. Seit 2002 arbeitet er in seiner Freizeit mit talentierten Menschen aus aller Welt zusammen, um Jacksum gemeinsam weiter zu verbessern.

OSI zertifiziert
Get Java Software