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.