Tresor in Cloud angeblich aktueller

Hi,

ich habe seit kurzem eine merkwürdiges Problem.

Ich benutze Banking 4W (Build 6.3.1.6026) mit zwei Datentresoren. Nennen wir sie A und B.
Beide werden im Web.de Onlinespeicher (Smartdrive) gesichert.

Seit kurzem gibt es dabei aber einen Fehler.

In Tresor A und B werden Bankgeschäfte erledigt. Nach Beendigung werden die beiden Tresore in die Cloud geladen, Banking 4W geschlossen. Beim nächsten Start von Banking 4W meldet mir das Programm, dass für Tresor A eine neuere Datentresordatei in der Cloud vorhanden ist und fragt ob ich diese zuerst von der Cloud laden möchte.

Problem dabei ist, dass in der Cloud keine neuere Datei ist bzw. nicht sein kann. Es spielt dabei keine Rolle ob ich Banking 4W nur für ein paar Sekunden schließe, oder es für längere Zeit beendet habe. Banking 4W meldet immer, dass Tresor A in der Cloud neuer wäre.

Was ich bisher getan habe:
- Beide Tresore direkt in der Cloud gelöscht und somit beim nächsten Start von Banking 4W die lokalen Tresore komplett neu hochgeladen.
- Einen anderen Account vom Web.de Onlinespeicher genutzt (andere Emailadresse)

Jemand eine Idee?

Die Uhrzeit vom PC stellt sich automatisch und ist auch korrekt.

Der Upload erfolgt durch Banking 4W.

Das seltsame ist, dass nur einer von zwei Datentresoren diesen Fehler aufweist. Der Fehler tritt auch erst seit ein paar Tagen auf. Davor lief es bisher immer einwandfrei.

Das Problem hatte ich auch mit mehreren Tresoren und mehreren Webdav-Anbieter (u.A: GMX und Strato).

Anfangs trat das Problem seltener auf, je größer der Tresor wurde und auch je langsamer die Verbindung ist, umso öfter kam es zu dem geschilderten Problem. Zum Schluß war es eigentlich nur noch so. Andreas hat dann irgendwann im Programm die Prüfung etwas weniger scharf gemacht (die Tresore werden immer noch als gleich angesehen, wenn sie so und soweit zeitlich auseinander liegen). Das hat aber letztendlich auch nicht wirklich geholfen. Am Ende war es eigentlich jedes mal so (nachdem die Tresore eine bestimmte Größe erreicht hatten). Mir ging das so auf die Nerven, daß ich letztendlich dann doch die mit kritischen Augen betrachtete Dropbox genommen habe, denn die geht mit einem eigenen Protokoll und nicht mit Webdav. Dort hatte ich interessanterweise noch NIE ein solches Problem. Und sowohl das Hoch- als auch das Runterladen gehen extrem massiv schneller als mit Webdav.

Hallo,

das grundsätzliche Problem liegt in "fehlerhaften" WebDAV-Implementierungen. Nach einem WebDAV-Upload wird vom WebDAV-Server ein Zeitstempel für die neu hochgeladene Datei geliefert. Diesen Zeitstempel speichern wir und nehmen ihn als Referenz für den späteren Vergleich. Leider gibt es WebDAV-Server die direkt nach dem Upload einen anderen Zeitstempel liefern, als bei einer späteren WebDAV-Statusabfrage der gleichen Datei. Deshalb werden diese in der App dann als ungleiche Dateien angesehen. Um diesen Fehler zu entschärfen erleuben wir ein Zeitfenster von aktuell 12 Sekunden. Das heißt, liegen die beiden Zeitstempel innerhalb von 12 Sekunden, so wird die Datei dennoch als identisch angenommen.

Nicht alle WebDAV Implementierungen verhalten sich so. Korrekte Implementierungen liefern nach dem Upload den gleichen Zeitstempel wie bei einer späteren Abfrage. Ich habe aber leider keine Liste von korrekten WebDAV anbietern. Zumindest unser QNAP NAS verhält sich hinsichtlich WebDAV einwandfrei.

Auch die Dropbox liefert nach einem Upload exakt den gleichen Zeitstempel wie bei späteren Abfragen. Deshalb funktioniert es hier problemlos.

Ich schreibe hier von B4A also unter Android. Der Sync wird von B4A selbst durchgeführt, sonst müßte ich hier ja garnchts dazu schreiben. Ich erinnere mich, daß Andreas geschrieben hatte, daß er keine Bibliothek von Dropbox verwendet. Allerdings wird protokollmäßig sicher was anderes als WebDav verwendet. Jedenfalls funktioniert es vollkommen problemlos und es ist vorallem ganz extrem viel schneller als der Komplettupload per Webdav. Meine Tresore sind recht groß, ich kann mir fast nicht vorstellen, daß die bei Dropbox komplett hochgeladen werden, dafür geht es einfach zu schnell... Mit Webdav war das immer eine Quälerei...

Oh. Da habe ich tatsächlich was durcheinander gebracht. Wie komme ich nur drauf, daß der Starter Android gemeint hat? Meine Ausführungen galten Android und dem Sync von B4A selbst. Unter Windows verwende ich (natürlich) nicht die Sync-Funktion von B4W. Die Android-Version synct diese in die Dropbox unter Apps/Banking. Diese kommen mit dem Dropbox-Client auf dem PC an und diese Dateien öffne ich dann direkt im Dropbox-Verzeichnis. Erstens denke ich, daß der Dropbox-Client das syncen selbst am besten beherrscht und außerdem muß ich es dann zumindest auf dem PC nicht immer von Hand tun.

Nachdem es mich jetzt interessiert, werde ich die Tage mal Tests vornehmen, wie schnell der Sync mit B4W unter Windows geht...

Dass der Sync unter Android durch B4A selbst so extrem viel schneller geht, als ein Webdav-Sync unter Android auch mit B4A ist allerdings kurios...

Was ist daran besser? Der spätere Vergleich hängt ja dann von genau diesem externen Server ab, wofür das Ganze ja gemacht wird...

besonders nervig ist auch, dass - wenn man das komplizierte Passwort gerade mal zur Hälfte eingegeben hat - das Popup "Soll der Tresor neu geladen werden J/N" dazwischenfunkt.
Also "N" und Passwort von vorne

Andreas@subsembly: bitte Zeitstempel korrigieren und gut

ich verstehe nicht, warum eine banking-Software an einen fehlerhaften Server (Software) angepasst werden soll

die anderen User haben sonst Probleme, wenn die Zeit bspw. auf 30 sec. (statt 12 aktuell) Toleranz gelegt wird, dass dann dies als gleiche Datei angesehen wird, obwohl weitere Daten bereits (evtl.) hinzugekommen sind.

hurra - der Fehler scheint mit dem aktuellen Update behoben zu sein