Alex Pankratov :
May 20, 2014
.
The following applies to the case when you see a red warning message in the log panel -
https://bvckup2.com/files/beta/bad-log.png
The issue is caused by the corruption of the log file index, which in turn is typically caused by killing the app instead of letting it shut down orderly.
While the app includes multiple provisions to minimize the chance of such corruption and takes steps to detect and rectify it, it will inevitably happen if you are in a habit of yanking power from your computer.
--
To explain the background – when an entry is written into a backup log, it first goes into the backup.log, which is just a plain text file. The location of the entry in the .log is then added to the (binary) index file, called backup.tdb, which is used by the app to locate and render log entries in the log viewer.
The log is a hierarchy, so this adds heck of a lot of complexity to the index maintenance. For example, whenever an item is expanded or collapsed the list of visible items in the index is recalculated. Now imagine that you just expanded or collapsed an item with 1,000,000 sub-items. This still needs to perform in a near real-time and that’s quite tricky to arrange for that. Hence all the internal complexity.
This in turn means that the logging module must be aggressive with write caching. Changes that are made to the index are kept in the memory and only occasionally flushed to the disk. When the app is shut down abruptly and if it is running a backup, the index *will* get corrupted, because there’ll be unsaved changes in the cache. If it is not running backup, then the app does a decent job of proactively flushing the cache, but there’s still a chance of log index corruption.
The app detects such partial updates in several ways, but it has no way of detecting the situation when a *Windows* disk cache didn't get a chance to flush to the disk. In other words, the app would write things out and think everything is in order, but the computer will die before Windows could write all app's changes to the disk. Caching does miracles to the performance, but it also makes things much more brittle.
--
Long story short – please let the app exit gracefully if it’s at all possible. If it’s not possible, then the next time you run into this problem, just exit the app, find and nuke all .tdb files and start the app again. You'll loose an *index* of the log history, but the logs will still remain available should you need them.