Ich habe seit Jahren eine (uralte) Hibiscus-Jameica-Version mit ca. 10 unterschiedlichen Konten genutzt und jetzt updated durch Herunterladen der neuen Jameica-Version und update von Hibiscus und Plugins innerhalb von jameica. Aktuell habe ich jetzt

Jameica 2.8.4, Hibiscus 2.8.14, Windows 10, Aktuelle Java-Version (Version 8 Update 221?)

Testweise habe ich mal alle anderen Plugins deinstalliert (mit Mashup usw. war das Ergebnis aber das Gleiche). Bei der Synchronisierung jedes HBCI-Kontos (z.B. DKB) bekomme ich sofort nach dem Start der Synchronisierung

Invalid Stream Header

Das Log hänge ich unten an. Ich nehme mal an, dass noch irgendwas in meinen Konfigurationsdaten steht, das den Fehler provoziert. Hat jemand eine Idee? Ich kann leider auf die alten Kontodaten nicht verzichten...

Viele Grüße, Frank

[Sat Sep 07 11:21:00 CEST 2019][INFO][main][de.willuhn.jameica.gui.SplashScreen$3.run] starting jameica ...
[Sat Sep 07 11:21:00 CEST 2019][INFO][main][de.willuhn.jameica.services.SecurityManagerService.init] applying jameica security manager
[Sat Sep 07 11:21:00 CEST 2019][INFO][main][de.willuhn.jameica.security.JameicaSecurityManager.<init>] protecting program dir C:\Users\wuebbel\Desktop\Dropbox\Banking\jameica\
[Sat Sep 07 11:21:00 CEST 2019][INFO][main][de.willuhn.jameica.services.LockService.init] creating lockfile C:\Users\wuebbel\Desktop\jameica.wuebbel\jameica.lock
[Sat Sep 07 11:21:00 CEST 2019][INFO][main][de.willuhn.jameica.services.LockService.init] C:\Users\wuebbel\Desktop\jameica.wuebbel\jameica.lock successfully locked
[Sat Sep 07 11:21:00 CEST 2019][INFO][main][de.willuhn.jameica.services.LogService.init] using log level ERROR [500]
[Sat Sep 07 11:23:13 CEST 2019][ERROR][bg-task:Worker][de.willuhn.jameica.hbci.synchronize.AbstractSynchronizeBackend$Worker.run] error while synchronizing
java.io.StreamCorruptedException: invalid stream header: 90B44E2F
at java.io.ObjectInputStream.readStreamHeader(Unknown Source)
at java.io.ObjectInputStream.<init>(Unknown Source)
at org.kapott.hbci.passport.storage.format.legacy.ConverterPinTan.load(ConverterPinTan.java:35)
at org.kapott.hbci.passport.storage.format.LegacyFormat.load(LegacyFormat.java:73)
at org.kapott.hbci.passport.storage.PassportStorage.load(PassportStorage.java:107)
at org.kapott.hbci.passport.storage.PassportStorage.load(PassportStorage.java:65)
at org.kapott.hbci.passport.HBCIPassportPinTan.read(HBCIPassportPinTan.java:169)
at org.kapott.hbci.passport.HBCIPassportPinTan.<init>(HBCIPassportPinTan.java:103)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at org.kapott.hbci.passport.AbstractHBCIPassport.getInstance(AbstractHBCIPassport.java:711)
at de.willuhn.jameica.hbci.passports.pintan.PinTanConfigFactory$1.get(PinTanConfigFactory.java:216)
at de.willuhn.jameica.hbci.passports.pintan.PinTanConfigFactory$1.get(PinTanConfigFactory.java:206)
at de.willuhn.jameica.hbci.passports.pintan.server.PinTanConfigImpl.getPassport(PinTanConfigImpl.java:335)
at de.willuhn.jameica.hbci.passports.pintan.server.PinTanConfigImpl.getBLZ(PinTanConfigImpl.java:282)
at de.willuhn.jameica.hbci.passports.pintan.PinTanConfigFactory.findByKonto(PinTanConfigFactory.java:278)
at de.willuhn.jameica.hbci.passports.pintan.server.PassportHandleImpl.open(PassportHandleImpl.java:100)
at de.willuhn.jameica.hbci.synchronize.hbci.HBCISynchronizeBackend$HBCIJobGroup$TaskHandleOpen.internalExecute(HBCISynchronizeBackend.java:574)
at de.willuhn.jameica.hbci.synchronize.hbci.HBCISynchronizeBackend$HBCIJobGroup$TaskHandleOpen.internalExecute(HBCISynchronizeBackend.java:547)
at de.willuhn.jameica.hbci.synchronize.hbci.HBCISynchronizeBackend$HBCIJobGroup$AbstractTaskWrapper.run(HBCISynchronizeBackend.java:630)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3933)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3564)
at de.willuhn.jameica.gui.GUI.loop(GUI.java:916)
at de.willuhn.jameica.gui.GUI.init(GUI.java:327)
at de.willuhn.jameica.system.Application.init(Application.java:145)
at de.willuhn.jameica.system.Application.newInstance(Application.java:87)
at de.willuhn.jameica.Main.main(Main.java:75)

die beiden aktuellen Prob.-T. durchgelesen?
forum/topic.php?t=23114
forum/topic.php?p=147487#real147487

Lieber Infoman,



Ja. Beides hilft mir, denke ich, nicht weiter.

Zu 1: Bei mir startet das Programm ja, DKB-Kreditkarte kann ich auch mit Mashup aktualisieren.
Zu 2: Bis zum Update des UPD/BPD kommt er bei mir ja gar nicht... Ich probiere es trotzdem mal.

Ah, danke. Das ist der Fehler: Zum Löschen des BPD bin ich in die Kontozugänge gegangen. Da waren vier unlesbare "passports" (invalid password). Versuch, die aus dem GUI heraus zu löschen, brachte sofort einen internen Fehler.Ich habe die vier betreffenden jetzt manuell im Explorer gelöscht.

Geht jetzt wieder.

Danke, Frank

Die eigentliche Ursache fuer die kaputten Bankzugänge ist das hier: C:\Users\wuebbel\Desktop\Dropbox

Mir haben schon mehrere User berichtet, dass der Sync-Client von Dropbox sich scheinbar nicht die Bohne dafür interessiert, ob gerade Schreibzugriffe durch andere Anwendungen passieren sondern schreibt einfach drüber. Nimm den Benutzer-Ordner aus der Dropbox-Synchronisierung raus oder stelle sicher, dass er nur synchronisiert, wenn Hibiscus nicht läuft. Du wirst sonst immer wieder Probleme mit kaputten Dateien kriegen.

Lieber Hibiscus,


Hmmm. Ist das neu? Ich nutze Jameica jetzt seit ca. 2013, wenn ich das richtig sehe, und lange in dieser Konfiguration. Zugegebenermaßen hat das am Anfang häufiger mal Ärger gemacht mit den Passport-Dateien (damals sind sie gern mal verschwunden und mussten aus dem Backup wiederhergestellt werden), jetzt aber schon lange nicht mehr. Das einzige, was ich sehe: Da bleiben gerne mal Haufen von pt_XXX-Dateien im Passport-Ordner stehen.

Meine Vermutung wäre doch eher dass das ein Ergebnis des Updates war. Schauen wir mal, wird die Zeit zeigen.

Danke, viele Grüße, Frank

Hibiscus speichert die Dateien seit 2.8 anders. Nämlich so, dass es nicht zu Datenverlusten kommen kann, wenn das Schreiben nicht klappt. Ich werde das Verfahren jedenfalls nicht wieder umstellen. Ich hatte das bewusst so eingebaut, weil es in der Vergangenheit regelmäßig vorkam, dass Antivirenprogramme dazwischengefunkt hatten.

Dieses dämliche Dropbox soll einfach die Finger von offenen Datei-Handles lassen.

Lieber Hibiscus,

Danke. Schauen wir mal.

Viele Grüße, Frank

Es kann auch sein, dass es einfach eine zufällige statistische Häufung ist oder dass der Dropbox-Client neuerdings aggressiver synchronisiert.

Das würde aber doch wohl voraussetzen, dass diese Datei auf mehreren Dropbox-Clients gleichzeitig verwendet wird!? Sonst gibt es ja für Dropbox nichts zu synchronisieren!? Ich bin Dropbox gegenüber auch skeptisch, aber es ist der einzige Dienst, der Diff-Synchronisiert, den ich kenne. Und das macht bei großen Dateien schon einen massiven Unterschied. Ich verwende B4 auf mehreren Rechnern und auch einem Androidgerät dropboxsynchronisiert - allerdings nie gleichzeitig. Ich hatte noch nie irgend einen Fehler...

Ich habe nicht getestet, in welchen Situationen es genau zu diesem Fehler kommt. Sowas laesst sich auch schwer reproduzieren, weil es eine sogenannte "Race Condition" ist. Also eine Fehlersituation, die nicht zwingend eintreten muss sondern nur dann, wenn es genau in diesen paar Millisekunden, in denen die Datei geschrieben wird, zu einer Kollision beim Zugriff von Hibiscus (welches versucht, die Datei mit dem Bankzugang zu schreiben) und einem Antivirenprogramm oder Cloud-Sync-Client (welches versucht, die Datei zu scannen/zu lesen, welche Hibiscus gerade loeschen will) kommt.

Zum technischen Hintergrund für das bessere Verständnis.

Im simpelsten Fall findet das Schreiben von Dateien durch ein Programm so statt, dass die neue Version der Datei einfach über die bisherige Version drüber geschrieben wird. Wenn es aber genau in diesem Moment zu einem Fehler oder Absturz kommt, kann hierbei eine kaputte Datei entstehen, da der Schreibvorgang noch nicht abgeschlossen war.

Eine einfache Sicherung der Transaktion sieht so aus, dass das Programm die Datei nicht direkt überschreibt sondern die neue Version unter einem anderen (temporären) Dateinamen direkt neben der vorherigen Version abspeichert. Wenn das erfolgreich war, wir die alte Datei geloescht und die neue Datei auf den Namen der bisherigen Datei umbenannt. Auf diese Weise existiert immer eine vollstaendige und intakte Version der Datei. Erst nur die alte Version, dann fuer kurze Zeit beide Versionen. Und zum Schluss nur noch die neue Version.

Mit diesem Verhalten gab es in der Vergangenheit unter Windows bei manchen Usern aber immer mal wieder Probleme. Weil ein Virenscanner die neue (temporäre Version) der Datei "gesehen" hat und begann, diese zu scannen. Also hat er sie geöffnen, um den Inhalt zu lesen - hierbei aber gesperrt. Währenddessen versuchte Hibiscus, die tempoäre Datei auf den originalen Dateinamen umzubenennen. Was dann jedoch fehlschlagen konnte, wenn der Virenscanner mit seinem Scan noch nicht fertig war.

Daher hatte ich das Schreiben der Dateien irgendwann mal so erweitert, dass Hibiscus nach jedem Schritt probiert und wartet, probiert und wartet... bis das kollidierende Programm fertig war.

Also:

1. Neue Version der Datei unter einem temporären Namen neben der alten Version ablegen.
2. Alte Version der Datei löschen
3. Prüfen, ob die Datei wirklich weg ist. Wenn nicht, in einer Schleife einmal pro Sekunde (maximal 20 Sekunden lang) warten, bis sie weg ist
4. Wenn die Datei dann immer noch da ist, mit Fehler abbrechen
5. Temporäre Datei auf den Namen der alten Datei umbenennen
6. Prüfen, ob Umbenennen erfolgreich war. Wenn nicht, in einer Schleife einmal pro Sekunde (maximal 20 Sekunden lang) warten, bis das Umbenennen tatschlich durchgeführt wurde
7. Wenn die Datei dann immer noch nicht umbenannt wurde, mit Fehler abbrechen

Das habe ich vor ca. 2 Jahren so eingebaut. Von Problemen mit Virenscannern habe ich seither nicht mehr gehört. Überhaupt war es seither ziemlich ruhig um das Thema geworden. Seit ca. 4 Monaten höre ich aber hin und wieder von Problemen mit Dropbox. Allerdings nur von Dropbox. Von Problemen mit anderen Cloud-Sync-Clients habe ich noch nichts gehört. Zusammen mit diesem hier sind mir jetzt ingesamt 3 Fälle bekannt. Das ist immer noch ziemlich wenig. Es könnte auch sein, dass das kein pauschales Problem mit Dropbox ist sondern das nur unter bestimmten Umständen auftritt. Allerdings verstehe ich nicht, was genau da falsch läuft.

Das einzige Szenario, was ich mir vorstellen kann ist, dass Dropbox sich die Datei greift um sie zu synchronisieren, dann aber ein Problem hat, den Dropbox-Server zu erreichen (entweder weil der Server grad schlecht erreichbar ist oder der Internetzugang hängt) um die Datei zu übertragen. Dadurch reisst der Sync-Client das 20-Sekunden-Wartelimit von Hibiscus und bewirkt, dass Hibiscus das Schreiben der Bankzugangsdatei mit einem Fehler abbricht.

Hallo zusammen,

ich benutze seit kurzem den Syncdienst "filen.io". Arbeitet vom Prinzip her genau wie Dropbox. Ich habe Probleme ohne Ende, ständig unterschiedlichste Fehler - eben auch der hier geschilderte. Manchmal verschwinden Plugins "einfach so", etc.... Ich werde jetzt nur noch synchronisieren, wenn Hibiscus nicht läuft.

Hallo,

ich bekomme seit heute (zurück aus dem Urlaub) die Fehlermeldung:



Da ich seit der letzten Synchronisation den Rechner nicht eingeschaltet hatte, frage ich mich, ob es sich um ein ähnliches Problem wie oben handelt - ich nutze jedosch OneDrive auf einer Win11-VM. Jedenfalls sind auch alle meine Bankzugänge weg und ich kann auch keine neuen mehr anlegen. Ich habe auch schon versucht, die alten Versionen von OneDrive zurückzuspielen, aber ohne das gewünschte Ergebnis...

Ja, das ist die selbe Ursache. Du kannst versuchen, ein Backup einzuspielen. Siehe https://www.willuhn.de/wiki/doku.php?id=support:backup
Wenn das nicht hilft, bleibt noch als Option, den PIN/TAN-Bankzugang zu löschen und neu anzulegen. Die Konten und Umsätze gehen dabei nicht verloren.