ctb files and all ctb~backups concurrently corrupted #2148
Comments
gitnard
changed the title
|
The backups are rotated, so it means that for 40 subsequent saves in the same session (cannot be 2 different sessions as you would not have been able to open the document in the first place) the document written to disk was corrupted. Please confirm the type of error you get, is the one saying that the file is not a cherrytree document? Maybe I should change the backup strategy to rotate between sessions and not between subsequent saves. Another option would be that after one rotation, the backup document is opened and the full tree structure tested. I think I will try this second option first. |
…with verification of the backup before rotating (#2148)
…with verification of the backup before rotating (#2148)
|
Regarding, "The backups are rotated, so it means that for 40 subsequent saves in the same session (cannot be 2 different sessions as you would not have been able to open the document in the first place) the document written to disk was corrupted. That precisely may be the issue. Successfully reopened main.ctb files (and some in-session saves), were subsequently saved as incremented main.cbt-backups (without any error message). Then when the main.cbt became corrupted, all 40 main.cbt-backups then were observed to all be corrupt as well. Expected behaviour would be for the .ctb-backup files to have remained independent of the main.ctb corruption, and should not have all received the same Last Data Modification timestamp as the main.ctb. Regarding improving backup strategy. I concur with Not implementing "rotate between sessions and not between subsequent saves". Subsequent saves within a session provide an audit-trail and safety-net when pushing hard through substantive updating. Based on my unexpected problem, I embrace "after one rotation the backup document is opened and the full tree structure tested" Not that I am clear as to what a "rotation" is. Since I had previously thought that when saving a .ctb, each previously saved same-named .ctb and ctb-backup simply had an additional tilde suffixed to the filename extension. And that each backup gets no further changes. It would be reassuring to know each newly edited .ctb save is tested for corruption. And it would be unsettling to know all previously saved .ctb-backup might collectively somehow get additional changes. Here are the type of error I got, during my once only ever incident with Cherrytree. Type of error, when use gui to open any of the 40 corrupt .ctb files, is a pop up small window that says: Type of error, when use cli terminal to open the most recently saved .ctb, is: Type of error, when use cli terminal to open the earliest saved .ctb40~backup is: |
|
As I am currently implementing the sanity check of a document, it would be useful if you could share with me privately one or more of these corrupted documents (if different errors) so that I can also test the code on it. You can find my private email in cherrytree help--about dialog |
…with verification of the backup before rotating (#2148)
…with verification of the backup before rotating (#2148)
…with verification of the backup before rotating (#2148)
…ation of the backup before encryption and rotation (#2148)
|
I implemented the document integrity verification in upcoming 0.99.52 before backups rotation. I hope to not see anymore such issue. |
--- issue
My main.cbt and all 40 main.cbt~backups have become corrupted at the same time.
Three other .cbt files and their backups also stored in the same directory and used over the same several week time period did not become corrupted.
All 41 corrupted files now share the same Last Data Modification timestamp, matching the likely time of incident. Timestamps previously would have spanned several weeks.
All 41 corrupted files are of similar size. Seven separate sizes between 1372132 B and 1417188 B.
All 41 corrupted filed are SQlite Not Protected .cbt. and have following tree summary info: Rich Text Nodes 113, Plain Text Nodes 0, Code Nodes 0, Images 0, Embedded Files 0, Tables 2, CodeBoxes 0, Anchors 0.
--- sqlite info
In terminal, using cherrytree to open these files produces similar but not identical messages:
=== Database problems report ===
: *** in database main ***
Main freelist: freelist leaf count too big on page 291
Page 149: btreeInitPage() returns error code 11
... then
50 more btreeInitPage() messages , then...] [ ] [warning] %s Couldn't open file: on_openOn tree page 89 cell 1: invalid page number 5990766
On tree page 89 cell 0: invalid page number 5701632
Page 87 is never used
... then
40 more never used messages, then ...] [ ] [error][
[
In db-browser-for-sqlite-gui, node table for these corrupted files shows all ~113 nodes, but most notes show error loading, and only between 1 and 22 of the nodes do load. The loaded nodes names match cherrytree document nodes that have not been recently edited.
--- settings and system
Cherrytree >Preferences >Miscellaneous >Saving: Not Autosave Every n Minutes, Not Autosave on Quit, Yes Create a Backup Copy Before Saving, Number of Backups to Keep 40.
Using Cherrytree 0.99.41 on MX-Linux 21 (Debian 11, Xfce 16) on UPS protected desktop computer using local drive. The NVMe drive smartclt checks out ok. No other computer issues or file issues.
The text was updated successfully, but these errors were encountered: