Rückmeldung doch nicht per Mail, sondern hier öffentlich, denn das ist sicher auch für andere interessant (auch wenn hoffentlich noch niemand anders von so einem Problem betroffen ist!):
Hallo Peter,
ich habe mir deine Dateien angesehen: Es sind leider alle drei Dateien (dat, bak1 und bak2) defekt, alle mit leicht unterschiedlichen Defekten.
Der Grund ist folgender:
Ich habe in C-Diary einen Mechanismus implementiert, der beim Laden der Datenbankdatei automatisch auf die nächste intakte Backupkopie zurückfällt, wenn die Hauptdatei defekt ist (Reihenfolge: Versuche, .dat zu laden, wenn korrupt, versuche .bak1 zu laden, wenn korrupt, versuche .bak2 zu laden).
Aber dieser Mechanismus greift eben nur beim Laden, und du hast vermutlich C-Diary fast immer offen, trägst Daten ein und speicherst diese fleißig, aber in die Situation, die Datei zu laden, kommst du dann nur selten (z.B. nur nach Neustart des Telefons), und mein Rückfallmechanismus greift daher nicht.
So pflanzt sich ein Fehler in der Datenstruktur (evtl. verursacht durch ein Symbian-Bug, RAM-Defekt, kosmische Strahlung (kein Scherz)..., evtl. natürlich auch durch ein C-Diary-Bug, was ich aber für wenig wahrscheinlich halte, da bisher sonst niemand so einen Fehler gemeldet hat) über die Backupkopien fort. Das ist ein Fall, den ich beim Programmieren nicht beachtet habe.
Leider habe ich aber auch nicht die Möglichkeit, mit vertretbarem Aufwand die intakten Daten aus deiner Datei herauszuziehen.
Der Grund dafür ist, dass ich in dem Framework, in dem ich programmiere, die Datei dadurch erzeuge, dass ich die Datenstruktur so, wie sie im RAM liegt, direkt in die Datei kopiere (und umgekehrt). Das ist ein simples Kommando wie (vereinfacht):
"file.write(file, database)"
bzw.
"file.read(database, file)"
d.h. die Struktur, in der die Daten in der Datei abgelegt sind, ist mir gar nicht im Detail bekannt. In deinem Fall schlägt dieser monolithische read()-Befehl fehl, und es werden KEINE Daten in den RAM geladen, d.h. ich kann auch keine Daten auslesen.
Ich müßte sehr aufwändig versuchen, diese Datenstruktur empirisch zu ermitteln, um einen Datei-Parser zu programmieren, der bis zur fehlerhaften Stelle die Daten extrahieren kann.
Das würde ich zwar gern tun, aber dafür fehlt mir die Zeit. Tut mir wirklich leid!
Ich werde aber Folgendes tun:
Ich werde im Programmcode (fließt dann in die nächste Version, 1.26, ein) einen Mechanismus einbauen, der die Datei nach jedem Speichern neu lädt, so dass C-Diary sofort nach dem Speichern merkt, wenn die Datei korrupt ist, und dann auf eine intakte Backupkopie zurückfällt (d.h. die seit dem letzten manuellen bzw. automatischen Speichern eingegebenen Daten wären dann wieder verschwunden, es wird auch eine entsprechende Warnung ausgegeben).
So vermeide ich, dass sich ein Fehler in der Datenstruktur, der sich einmal eingeschlichen hat, bei kontinuierlicher Verwendung von C-Ciary (also ohne zwischenzeitliches Neuladen der Datei) über alle verfügbaren Datenbankkopien (dat, bak1 und bak2) fortpflanzt und so immer mindestens eine intakte Datei existiert.
Das verlängert die Zeit, die C-Diary zum Speichern braucht, etwas, aber ich denke dass das ein Preis ist, den man für diese zusätzliche Sicherheit gern zahlt.
Evtl. werde ich das Timeout für die automatische Speicherung dann von 15 Sekunden auf vlt. 30 Sekunden erhöhen, damit man nicht so oft vom längeren Speichern gestört wird, wenn man Daten in langsamer Folge eingibt oder bearbeitet.
Viele Grüße,
Daniel
