Hallo Leute,

ich bin seit mehreren Monaten zufriedener Hibiscusnutzer, da ich persönlich die Datenbankfunktion mit Backup sowie die nicht zu überladenen Funktionen schätze.
Trotz alledem habe ich aber ein schwerwiegendes Problem bei der Nutzung des Programms:

Aus einem mir unerfindlichen Grund verschwindet einer meiner zwei Bankzugänge (2 unterschiedliche Sparkassen) einfach aus dem Programm, das merke ich dann immer daran, dass der Kontenrundruf nicht mehr funktioniert.
Um das ganze zu beheben, muss ich dann ein glücklicherweise automatisch erstelltes älteres Backup suchen, in dem der Bankzugang noch vorhanden war. Ein manuelles neues Hinzufügen des Zugangs funktioniert nicht, beim Testen kommt immer: "Fehler beim Ermitteln einer neuen System-ID", obwohl ich exakt dieselben Daten eingegeben habe wie vor dem Verschwinden.

Das Problem tritt immer in unregelmäßigen Abständen auf, ich logge mich allerdings auch nicht jeden Tag in Hibiscus ein. Zuletzt hatte ich das Programm am 18.11. benutzt, da ging es noch, aber wahrscheinlich im Verlauf der Arbeit daran "verschwand" der Zugang, sodass in den Backups vom 18.11. der Zugang schon weg war, ich musste eine Stufe zurück auf den 31.10., da war der Zugang noch vorhanden. Wenn ich das Backup dann eingespielt habe, ist aber wieder alles beim Alten, bis zum nächsten Vorfall.

Wisst ihr, woran das liegt und wie ich das Problem beheben kann? Ist halt schon recht nervig, seine ganzen Kategorien und Kommentare neu machen zu müssen, weil in der Datenbank der Bankzugang verschwunden ist.

LG

hazi

Finden sich denn in der Log-Datei "jameica.log" irgendwelche Fehlermeldungen? Siehe http://willuhn.de/wiki/doku.php?id=support:fehlermelden

Hab seit gestern genau das gleiche Problem - gibt es was neues?

Ja, meine Frage nach Fehlermeldungen im Log.

Hallo, ich hab mir das jetzt genau angeschaut - mit dem nightly build von heute.
Im Logfile gibt es keine Fehlermeldung
Wenn man an der Einstellung eines Zugangs irgendetwas ändert, wird im Verzeichnis "jameica\hibiscus\passports" eine temporäre Datei (vermutlich mit irgendwelchen Hashs) angelegt, die dann beim Speichern einfach nicht wieder in den Originalnamen kopiert werden sollte, aber nicht wird.
Ein Beispiel:
nach Speichern im Dialog "Details der PIN/TAN-Konfiguration" entsteht unter "jameica\hibiscus\passports" eine Datei wie folgt
"xxxxxxxxxx.pt_1649508911572368924"
Die ursprüngliche Datei "xxxxxxxxxx.pt" fehlt, und somit verschwindet der Bank.-Zugang aus der Liste. Durch umbenennen der temp. Datei kann man ihn beim nächsten Start wiederherstellen.
Ich habe verschiedene Einstellungen durchprobiert - mal funktioniert es, mal nicht. Hilfreich scheint mir zu sein, die BPD/UPD-Daten zu erneuern. Es könnte auch etwas damit zu tun haben, ob manuell angelegte Konten dem Zugang zugeordnet wurden.
Aber das überlass ich den Fachleuten - hoffentlich könnt ihr mir den Infos was anfangen!

Das mit den Temp-Dateien ist mir schon klar. Das ist ein gebraeuchliches Verfahren, um gesichert in Dateien zu schreiben. Man schreibt nicht direkt in die Zieldatei sondern erstmal in eine Temp-Datei auf der selben Partition. Nach dem erfolgreichen Schreiben loescht man die Originaldatei und und benennt dann die Temp-Datei auf den Namen der Originaldatei um. Auf diese Weise ist sichergestellt, dass immer eine intakte Datei existiert. Falls mitten im Schreiben der neuen Datei etwas schief geht, ist dann wenigstens noch die vorherige Version da.

Da der Fehler meines Wissens nach nur unter Windows auftritt, habe ich die Vermutung, dass da eine Art Race-Condition durch irgendwelche Virenscanner auftritt, die genau zwischen dem Moment passiert, wenn die alte Original-Datei geloescht wird und die temporaere Datei auf den Original-Namen umbenannt werden soll. Die Original-Datei existiert nach dem Aufruf des Loeschvorgangs vermutlich noch fuer den Bruchteil einer Sekunde. Gerade lange genug, dass das anschliessende Umbenennen fehlschlaegt.

Ich baue mal einen provisorischen Workaround ein, der ab morgen im Nightly-Build ist. Da das aber rein spekulativ ist, kann ich nicht sagen, ob das das Problem wirklich sicher beheben wird. Zumal es ja auch nur bei sehr wenigen Usern auftritt. Ein Indiz mehr, dass das nur unter ganz speziellen Bedingungen passiert.

Bingo! Ich glaube das ist die richtige Spur - bei abgeschaltetem Virenscanner tritt das Problem nicht mehr auf. Letzte Woche hat es ein Update vom Avast gegeben - das könnte auch erklären warum das Problem bisher bei mir nicht auftrat, denn bis vor ca. einer Woche hat noch alles bestens funktioniert.
Ich probiere es morgen mit dem neuen NB aus.
Kompliment!

So, ich melde mich nun auch mal wieder

Bis jetzt ist der Fehler noch nicht wieder aufgetreten, daher konnte ich noch kein log posten.

Zu meinem System: Win 8.1 mit Windows Defender als Antivirus.

Vor dem Verschwinden des Zugangs habe ich aber mMn nichts daran geändert, sondern ganz normal die Konten aktualisiert und Beträge kommentiert etc.

Ich hab mal ein wenig getestet: die
HBCI_Exception: could not rename xxxxxxxxx.pt_5886727503516989210 to xxxxxxxxx.pt
tritt immer auf, das Verschwinden eines Bankzugangs aber nicht.

Ein Schönheitsfehler: offensichtlich wird beim shutdown nicht aufgeräumt, so dass die xxxxxxxxx.pt_5886727503516989210 stehen bleibt und mit ins backup gepackt wird. Mit der Zeit scheint sich da einiges anzusammeln.

Ich hoffe, die zwei logs sind im Anhang.

Es geht nicht um das "Aufräumen beim Shutdown" sondern darum, dass da ein Virenscanner die Schreib- und Kopiervorgaenge stoert.

Deswegen hab ichs ja auch Schönheitsfehler genannt und nicht behauptet, dass das mit dem eigentlichen Problem was zu tun hat.
Meine belegbare Behauptung war, dass dieses fehlschlagen des umbenennens vorkommt (und dann besagte Dateien stehen bleiben), ohne dass danach der Bankzugang weg ist. Daher erscheint mir die Vermutung mit dem Virenscanner nicht so ganz einleuchtend.

Bei mir tritt das Problem erst seit etwa einem halben oder maximal einem Jahr auf (Hibiscus benutze ich schon bestimmt 6 Jahre), zuerst eher selten und nur auf dem XP-Rechner, in den letzten Monaten öfters und auch auf dem Win7-Rechner. Auf einem anderen Win7-Rechner mit Java8 ist der Fehler noch garnicht aufgetreten. Ja, auf allen Rechnern laufen Virenscanner, allerdings verschiedene.

Könnte es etwas mit der Java-Version zu tun haben?

Na doch. Das ist schon das eigentliche Problem. Und es ist eigentlich auch kein Schoenheitsfehler. Wuerde man aber beim Shutdown diese Dateien einfach loeschen, wuerde man den Fehler "unter den Teppich kehren" anstatt die Ursache zu loesen. Eigentlich duerfen diese Dateien gar nicht uebrig bleiben. Leider passiert es aber unter Windows, wenn da Virenscanner auf Dateien zugreifen, waehrend Hibiscus versucht, sie zu loeschen/zu schreiben.



Um Gottes Willen, das bestreite ich ja auch gar nicht. Im Gegenteil.



Das ist im Falle von PIN/TAN aber eher Glueck. Wuerde das beim Verfahren Schluesseldatei passieren, waere der Bankzugang ggf. kaputt.
Der Bankzugang ist normalerweise deshalb nicht weg, weil das Schreiben in die Passport-Datei transaktionssicher erfolgt. Es gibt keinen Moment, in dem weder die alte noch die neue Version der Datei existiert. Das heisst: Wenn das Schreiben fehlschlaegt, dann bleibt wenigstens die vorherige Version der Datei erhalten.



Doch, doch. Das ist so. Das Thema ist auch nicht neu. Und wir haben das auch schon reproduzieren koennen. Nach Abschalten des Virenscanners bzw. Hinzufuegen des Hibiscus-Ordners zur Whitelist (damit der Scanner da nicht mehr dazwischen funkt), liess sich das Problem reproduzierbar beheben.



Der Fehler ist von seiner Art eine Race Condition (https://de.wikipedia.org/wiki/Race_Condition). Von daher tritt er je nach Umgebung unterschiedlich haeufig auf. Wenn das Lesen, Schreiben und Locken von Dateien in Java 8 geringfuegig anders implementiert ist, kann es durchaus sein, dass das Problem dann seltener bzw. fast gar nicht mehr auftritt.

Ok, in Sachen race condition und Virenscanner hab ich keine Gegenargumente mehr: nach deaktivieren des "Echtzeit-Scans" beim McAfee bzw. Avira tritt das Problem nicht mehr auf.
Aber: auf dem Win7-Rechner mit vollgeblasenem McAfee Virenscanner, auf dem das problem nicht auftritt, habe ich Bandbreite bis zum Abwinken (im Gegensatz zu denen zuhause). Die race condition könnte demnach zuschlagen, wenn auf der Passportdatei eine Netzwerkverbindung noch nicht geschlossen ist.

Mag sein. Fuer Hibscus spielt es aber keine Rolle, da ich darauf keinen Einfluss habe. Das Problem tritt ausserhalb der Java VM auf - in Hibiscus selbst habe ich quasi keine Chance, diese Fehlersituation irgendwie zu erkennen und zu beruecksichtigen.

Nee, ich würd sagen innerhalb, und zwar beim Java Networking. Und deshalb kommst du von Hibiscus aus da nicht ran.

So, genug gebesserwisst! Danke nochmal für deine Mühe!

Nein. Wenn es innerhalb der JVM waere, gaebe es die Race-Condition mit ausserhalb gar nicht.

Es hat eigentlich auch nichts primaer mit dem Networking zu tun, weil der Fehler auch schon bei Usern mit lokalem Benutzerordner auftrat.

Meine Benutzerordner sind auf allen Rechnern lokal.
Ich meinte das anders: wenn das Problem auftritt, dann imho hier:
[Tue Dec 22 15:15:53 .HBCICallbackSWT.status] führe Dialog-Initialisierung aus
[Tue Dec 22 15:15:53 .HBCICallbackSWT.status] erzeuge HBCI-Nachricht DialogInit
[Tue Dec 22 15:15:53 .HBCICallbackSWT.status] signiere HBCI-Nachricht
-> PIN wurde eingegeben
[Tue Dec 22 15:16:17 .HBCICallbackSWT.status] verschlüssele HBCI-Nachricht
-> ; jetzt gehts ins Netzwerk!
[Tue Dec 22 15:16:17 .HBCICallbackSWT.log] creating a connection to https://f.../ and checking the certificate
[Tue Dec 22 15:16:17 .HBCICallbackSWT.status] versende HBCI-Nachricht
[Tue Dec 22 15:16:17 .HBCICallbackSWT.status] warte auf Antwortdaten
[Tue Dec 22 15:16:17 .HBCICallbackSWT.log] waiting for response
[Tue Dec 22 15:16:17 .HBCICallbackSWT.status] entschlüssele Antwortnachricht
[Tue Dec 22 15:16:17 .HBCICallbackSWT.status] überprüfe Signatur der Antwortnachricht
[Tue Dec 22 15:16:17 .HBCICallbackSWT.log] message has no signature
[Tue Dec 22 15:16:17 .HBCICallbackSWT.log] installed new UPD with version 0
[Tue Dec 22 15:16:17 .HBCICallbackSWT.status] nutzerspezifische Daten aktualisiert - neue Version is 0

Es passiert beim Speicher der Passport-Datei.
Wir muessen hier auch nichts mehr weiter diagnostizieren. Die Ursache ist schon seit einer Weile bekannt. Mit ein paar Workarounds konnte ich die Wahrscheinlichkeit fuer das Eintreten des Fehlers ein gutes Stueck senken. Aber ganz verhindert laesst es sich nicht, wenn ein besonders renitenter Virenscanner die zu loeschende Datei partout nicht wieder loslaesst.