Database size keeps growing despite no content added

[ghost]

Version, Operative system
State the Version and the Operative System/Desktop. Try the latest available version before reporting an issue.

Cherrytree 0.99.52, Linux Mint 21 Cinnamon

Describe the bug
A clear and concise description of what the bug is.

Database size keeps growing despite no new content being added. This behavior started fairly recently, as i noticed Cherrytree startup times increasing slowly. I checked my database size today which was 36MB. When i saved the database again from CTZ to CTX (or vice versa), the filesize shrunk to 70kB. However, this format also increases in size when i modify the database contents. Both SQLite and XML exhibit the same behavior.

The same effect happens when saved with "save and vacuum" function. I don't know what that is supposed to do, but vacuuming usually indicates cleaning/shrinking, instead of increasing in size.

edit: opened my database when it was 67,4kB. I added one letter to a single node, and saved the document. Size was now 134,9kB. I then removed the same letter and saved again. Size is now 202,3kB.
edit2: it's now 5MB. I have been editing just one node this evening, text only.

To Reproduce
If applicable, attach a non-personal document where the issue can be reproduced systematically.
Steps to reproduce the behavior:

1. Open database, note the size of the database
2. Cut the contents of a node, save, note that size does not decrease
3. Paste the same content back to the node, save, note that the database size has now increased by almost 100kB

[giuspen]

Hi,is this happening only with the SQLite (CTB, CTX)?
Have I understood correctly that when you save and vacuum it does decrease in size?

[giuspen]

I'm not seeing the behaviour if not on the SQLite where it is expected. What package are you using (PPA/flatpak/appimage/snap)?

[ghost]

This happens both with SQLite and XML.

Save and vacuum increases the size, i just tested and the filesize increased from 5.6MB to 5.7MB just by clicking save and vacuum.

I have installed Cherrytree through PPA (add-apt-repository ppa:giuspen/ppa).

Why is it expected on SQLite? Is there an upper limit to the file size it can achieve? As i mentioned, by database was over 30MB and it was noticeably slow to open it.

[giuspen]

Can you do this test for me and then attach the result here so I can have a look:

1. create a test document CTX with one test node only and numbers 1 to 10 on 10 lines, copy and paste it it to another folder rename it it _PRE.
2. remove one or more of the 10 lines, save, copy and paste it it to another folder rename it it _POST.
   attach _PRE and _POST for my analysis

[giuspen]

(sorry before copy and paste close cherrytree just to be sure it's fully written)
It is expected in SQLite because SQLite occupies more space that it needs to be fast (it's the library, not cherrytree), save and vacuum was supported exactly for this reason.

[ghost]

testing_post.zip
testing_pre.zip

There, i hope i did it correctly. You need to rename the files from zip to ctx because Github didn't allow attachments with the ctx extension, so i only renamed it to zip.

The test file password is: testing

[ghost]

testing.zip

One more in case it's useful, this is the _POST file but i saved it with "save and vacuum" which increased the filesize while the contents remain the same.

[giuspen]

Thanks I need you to do this for the XML though because while with SQLite it is expected, in XML it is surely not.
So can you save as XML password protected (CTZ) and do the same for me?

[ghost]

test_ctz_post.zip
test_ctz_pre.zip

Sure. Same thing, renamed to zip. Same pass. Again, the filesize increased after deleting a few lines. I noticed the _POST file has an additional file inside when opened with Archive Manager as a zip file. Is this intentional when using XML?

[giuspen]

No the presence of 2 files in the archive is exactly the problem.
I need to understand why that happened for you since it isn't happening for me.
I will have a thought/do additional testing and will likely come back with questions unless I find out.

[ghost]

Okay, thanks. This rules out corruption etc in my regular database, then, since it occurs on a fresh file too.

My current database has 97 files in it, at 6MB. I can "reset" this by saving the database again in another format or name, but the files begin accumulating inside the archive as soon as continue modifying it.

[giuspen]

Have you un-ticked "Create a Backup Copy Before Saving" in the preferences dialog tab miscellaneous?

[ghost]

Have you un-ticked "Create a Backup Copy Before Saving" in the preferences dialog tab miscellaneous?

It is unticked.

[giuspen]

Thank you for reporting this, I will release a new version 0.99.53 shortly