warvair / peerblock

Automatically exported from code.google.com/p/peerblock
Other
0 stars 1 forks source link

History.db not being pruned #29

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. In Settings, set History to "Archive & Remove" Every 1 Days.
2. Wait for 24 hours, until the next "Archive" cycle hits.

What is the expected output? What do you see instead?
- Expected: A copy of history.db should have been made in the ...\archives
directory, and the size of the original history.db should be much smaller.
- Actual: A copy of history.db is made, but the original history.db file
never shrinks.

What version of the product are you using? On what operating system?
- Reported in r70, but sounds like it was an issue in the original PG2 code
as well.
- Reported on XP 32-bit I think, but probably affects all OS versions.

Please provide any additional information below.
- Bug report submitted via email by Tim M.

Original issue reported on code.google.com by peerbloc...@gmail.com on 30 Jul 2009 at 1:04

GoogleCodeExporter commented 9 years ago

Original comment by peerbloc...@gmail.com on 31 Jul 2009 at 4:42

GoogleCodeExporter commented 9 years ago
Fixed in commit r73.

Turns out that sqlite doesn't actually free up the data-structures holding 
table data
until you run the "vacuum;" command.  See
http://web.utk.edu/~jplyon/sqlite/SQLite_optimization_FAQ.html#compact for more 
details.

Original comment by peerbloc...@gmail.com on 31 Jul 2009 at 4:56