If you've been paying attention, you've probably noticed by now that under most conditions, ABP is inert. Under all but the most particular circumstances backups are disabled, and therefore ABP does nothing. The reason is simply that it would be dangerous for ABP to do otherwise. This page explains why.
The Backup Paradox: It may seem a paradox to claim that in order for ABP to reliably back up your database, backups must sometimes be disabled. But if ABP backs up too aggressively, the backups you want will be destroyed by the backups you don't want.
Atypical Actions: ABP is designed to support the KeePass user who has a single password database that opens automatically at start-up. For the typical ABP user, the password database is backed up as needed, and everything is fine. But sometimes the typical ABP user may do atypical things; that is, things other than the typical actions. And so may an atypical user. Unless these atypical actions disable backups, valid backup copies of the “single” password database could be overwritten – and therefore destroyed – by copies of other databases. Each significant atypical action is discussed below in detail.
KeePass Start-Up Semantics
The Two Methods for Opening at Start-Up: Although ABP is designed to back up the database opened at start-up, two different methods can be used to configure KeePass to open a password database at start-up. ABP only works with the second one.
If both methods are specified, the KeePass option is ignored, and the command line argument is in effect. Backups are enabled only if the command line argument method (Method 2) is in effect. If Method 1 is in effect, backups are disabled.
Unless backups are disabled when Method 1 is in effect, atypical actions by the user could change which database is backed up. This may inadvertently destroy all backups of one database by overwriting them with backups of another database. The following counterexample shows why this is so.
Counterexample: Alice stores her passwords in C:\Files\Database.kdb, and views them by opening KeePass through a shortcut which specifies the backup path(s), but not the initial database. Thus, Method 1 is in effect. Assume, for the purposes of this counterexample, that backups of the database opened at start-up are not disabled when a database is opened automatically through this shortcut. Now suppose Bob gives Alice another password database, also called Database.kdb, to be used for some supplementary purpose. Alice places Bob's database on her machine at C:\BobFiles\Database.kdb. Next, she performs the atypical action of opening this supplementary database, perhaps just to look at it. Alice does not intend for the supplementary database to be a replacement for C:\Files\Database.kdb. Therefore, she does not want ABP to back up the supplementary database onto the backup copies of C:\Files\Database.kdb, thus destroying her backups. And in fact ABP will not back up the supplementary database at this time, not even if Alice modifies and saves the supplementary database. (See next paragraph for the reasons why.) Nevertheless, the stage has been set for Alice's backups of C:\Files\Database.kdb to be overwritten and destroyed by backups of C:\BobFiles\Database.kdb. The next time Alice starts KeePass through her shortcut, Method 1 causes C:\BobFiles\Database.kdb to be automatically opened. Alice may be happy with this, because she may just want to look at this supplementary database again anyway. However, as soon as this open succeeds, the backup copies of Alice's passwords will have been destroyed by backups of the supplementary database. This is why backups are disabled when Method 1 is in effect.
Opening Supplementary Database: The first time Alice opens the supplementary database C:\BobFiles\Database.kdb, it will not be backed up, no matter how she does it. For example, suppose Alice opens C:\BobFiles\Database.kdb is from within a session begun using the shortcut, by selecting the “File” menu “Open…” action. This action causes backups to be disabled. Another way Alice could open C:\BobFiles\Database.kdb is by double-clicking on it in Windows Explorer (assuming the KeePass “create association” option is in effect). In this case no backup paths will have been specified. Thus, backups are disabled.
Summary: ABP assumes that the password database to be backed up resides at some particular fixed place in the PC's file system. When this place is specified as a command line argument (Method 2), no user actions within the KeePass application can change this place. With Method 1, atypical actions by the user could change this place, and possibly cause ABP to copy the wrong database onto backups of the initial database, thereby destroying them.
Atypical Actions after Start-Up
Backups are disabled in each of the following cases. These features ensure that backup copies of the initial database will not be overwritten and destroyed if the user subsequently opens another database having the same file name (but in a different folder).
In order to properly serve the needs of the typical ABP user with respect to backups, ABP was designed to ensure that users can not inadvertently cause backup copies of the initial database to be overwritten and destroyed by backups of other databases, even if they perform atypical actions. A key feature of this design is that backups are disabled if certain atypical actions are performed.