Could not open cherrytree.exe.log

[stanleyrhodes]

This issue started with the exact same issue reported here:
#416

I would try to open a cherrytree file, it would tell me it couldn't open the cherrtree.exe.log in C:\Program Files (x86)\CherryTree\bin but I couldn't find that log file there. That seems like a bug or some sort of issue.

Then I followed the guidance in the above post to "Run as administrator" cherrytree.exe and a log appeared.

The log is as follows:
Traceback (most recent call last):
File "cherrytree", line 78, in
File "cherrytree", line 50, in f_main
File "main.pyc", line 248, in main
File "main.pyc", line 83, in init
File "main.pyc", line 88, in window_open_new
File "core.pyc", line 252, in init
File "core.pyc", line 1500, in file_startup_load
File "core.pyc", line 2002, in file_load
File "ctdb.pyc", line 650, in read_db_full
File "ctdb.pyc", line 563, in get_node_row_partial_from_id
sqlite3.DatabaseError: database disk image is malformed

The file that caused it, I believe, was originally an XML .ctd file, which after it grew quite large, I saved as a .ctb. I've been using it since that conversion, about 3 weeks ago, without problem. I'm a bit nervous because this is a very important file for my life and daily work.

[giuspen]

Can you try to run the testing version 0.99.2 which has additional checks on the database and report the result? Look at https://www.giuspen.com/cherrytree/#downl and scroll down.
Additionally you should have the backups in the same directory to try and open.

[stanleyrhodes]

I downloaded the 0.99.2_win64_portable version, unzipped, ran as administrator, and opened the problem .ctb file. I got these messages:
"The database file P:/Documents/stan_personal_notebook.ctb is corrupt, see log for more details"
"Error parsing the cherrytree file."

I looked around for a new log file, but I can't find one. Does the portable version put it somewhere not-obvious, or did I need to do something differently?

[txe]

Hi,
The cherrytree file itself is a sqlite database, and it's corrupted. You can open it by sqlitebrowser.
This article describes how to recovery the db.

[stanleyrhodes]

Thanks for giving me a little guidance. I am a SQL novice, so it wasn't obvious how to glue together the information you gave me into an entire process to get a recovered, working .ctb file. I was able to open the corrupted .ctb with sqlitebrowser but I'm not sure what I was supposed to do with that. In using it, I did notice that a top-level node with a lot of text was missing. Other stuff might have been missing too, but I didn't notice it.

I used the article you linked to download sqlite3.exe and I followed the instructions on that page. Using the integrity check it told me the following:
*** in database main ***
On tree page 1156 cell 0: 2nd reference to page 1325
Page 1070 is never used
[all the pages between the above and below page numbers here]
Page 1155 is never used

Edit: I just worked on this a lot more, quite a few hours. I was able to get the sql import to work once I removed PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; from the first two lines of the sql file. It literally took me hours to figure that out, and just on a hunch, not because anything I found on the web mentioned that issue. Perhaps unsurprisingly, the top-level node with a lot of text that was missing when I viewed the corrupted file in DB Browser for SQLite was also missing when I imported the recovered sql into a .db.

Now I know that if I can get the sql to import, I rename the recovered db file to a cherrytree .ctb file suffix and it seems to be a normal .ctb file. But it turns out to be pointless in this case because a node with a lot of data is missing. So the backups (e.g. .ctb~~) ended up being more useful for that particular node.

I'm really confused as to how this corruption of the .ctb happened, and whether it had to do with 1) this previously being in XML as a .ctd file; 2) the node that was lost having a lot of text data, or maybe something weird in the rich text; or 3) the .ctb file being saved to a folder that also synced with a cloud service. I also wonder, would this have happened if I had continued to use an XML .ctd file?

I'm also still confused by the log error that started the whole thing.

[txe]

When you removed BEGIN TRANSACTION; there were still errors in reading dump_all.sql but they were skipped.

I suppose the issue were caused by syncing, xml is definitely safer to use with cloud services.

About the log file, when cherrytree.exe has issues, it tries to write information in log file which place is in the same directory as cherrytree.exe is. It works OK for portable versions, but not for versions installed in C:\Program Files (x86) because user process cannot create files (e.g. log files) there. So cherrytree.exe cannot handle it and stop working. There is two ways to fix it:

• you can change privileges for C:\Program Files (x86)\CherryTree\bin, so user process can create and write files there.
• cherrytree.exe should create log files in other place.

[stanleyrhodes]

Thank you. Good to know that XML might be a better choice for cloud storage. I had wrongly assumed the two formats would be equivalently vulnerable to problems on cloud services. I much prefer the speed of sqlite but not if I'm going to lose work every month or two from a hiccup.

I think more novice users are likely to install CherryTree in the default way, which means the default functionality right now is failing to create a log on Windows. CherryTree already creates C:\Users\[Username]\AppData\Local\cherrytree which contains config.cfg. Perhaps this is the ideal place to create the log files. But I know very little about permissions on Windows.

[giuspen]

that log is actually automatically generated from the old library, the new version won't have this issue. If you want to try it you can find it already even if still under testing at https://www.giuspen.com/cherrytree/#downl scroll down see 0.99.3

[txe]

I suppose, the topic is concluded, so closing

[stanleyrhodes]

I've had this happen twice more since I posted this issue, including today. I'm still using this ctb file with a cloud service so I guess I'm rolling the dice. But I've noticed a pattern: every time it has happened, including that first time, I had pasted in in some text straight from a webpage. This time, I knew exactly what I had posted before it corrupted: the body text at https://www.europeansocialsurvey.org/about/

That page, in the third bullet point paragraph, has right single quotation marks rather than the regular typewriter apostrophe. Is there a chance there's an encoding issue when CherryTree takes pasted text with unicode characters like this and tries to save them in the sql-lite DB?

[giuspen]

you should upgrade to 0.99.46 as the old python version is no longer supported