suggestion: search behavior & "backup" functio

[ar]

Hi Tarek,

I have two suggestions for keepassX:

- Search behavior: the small search box in the toolbar and the CTRL-F full search box don't seem to behave the same in my case. Apparently the small box searches everywhere in the database, whereas the CTRL-F search dialog only searches in the selected database folder. I think it would be more intuitive that the CTRL-F dialog search by default in the whole database (and maybe offering a checkbox to "Search only in the selected folder"

- Backup: Keepass (the windows version) has this "Backup" functionality where it creates a Backup folder and saves old versions of modified entries, which I find useful, it saved my neck a few times already. Also, there is a setting that forces Searches to avoid searching the "backup" folder.

Thanks!
Ar

Keepass on Ubuntu Edgy/Gnome

[tgice]

I second this suggestion. I've just moved from using KeePass on Windows to Ubuntu and I was disappointed to not find that feature in the port (though very happy to of course see a Linux port of this application).

I'm very dependent on KeePass(X) and would love to see the Backup group be supported as a special group as it is in the Windows KeePass.

Any other interest in this?

[AJLobo]

I also just switched from Windows KeePass. Now using keepassx on Ubuntu 7.10. I third the suggestion of excluding backup entries from the auto-type feature. I'm not sure if the original KeePass had/will have this feature, but also the ability to automatically choose an entry by the window title + the URL. Sometimes websites use the same "Login" window title.

Other than that, I've really enjoyed using KeePass, and I'm really glad you've ported it to linux. It's definitely greatly improved my password security and it's very convenient Thanks!

[bdmayes]

I agree that some sort of backup functionality would be an excellent addition to this project. In fact, I agree so much so, that I intend on implementing it! Below is a rough outline of what I'm hoping to accomplish. I will probably start small and then add new features to it as my time permits (lots of projects and papers to work on right now...it's toward the end of my semester so it's crunch time).

Please let me know if you have any comments or suggestions. Like I said, I will probably start with some minimal backup functionality (such as maybe one backup, and it will be in a hard-coded place). Once I am happy with the way it's working, I'll make incremental changes to make it better.



1. Feature Proposal

I would like to create a simple backup mechanism for KeePassX. This backup mechanism should be capable of saving at least one previous version of the database. Backups ensure integrity and availability of the database in the event of unforseen consequences. I do not intend to have automatic merging between multiple databases. The basic functionality of this would be as follows:

i) Pick a certain point (e.g. a function) where the database will be saved (candidates discussed in item 2).
ii) Whenever the action in step (i) is executed, KeePassX will take a "snapshot" of the existing database. This essentially boils down to the application copying the <database>.kdb file to a particular location. This location might initially be hardcoded, but eventually it would be nice for it to be specified by the user.
iii) Allow the user to specify a 'time to live' for the backups. Better yet, allow the user to specify a rolling number of backups to keep on the system. For example, the user may wish to keep K backups. While there are still less than K backups, the application simply copies the database to new .kdb files on the filesystem. Once K backups are contained on the filesystem however, the oldest backup would be deleted whenever a new one was taken leaving the other K-1 backups alone.
iv) If possible, allow the user to specify which databases they wish to apply this to (and assume the rest do not require backups).

2. Proposed Implementation

I believe the OnFileOpen() or OnFileSave() functions would be ideal places to add code. These are both contained in the mainwindow.cpp file. I am leaning more towards the OnFileOpen() function so that a backup would be taken just before a database is opened.

The functionality can be enabled through the settings panel. Like other options, the settings would be written to the .keepassx/config file (which involves new functionality for getting and setting the value in SettingsDlg.h/SettingsDlg.cpp). The new checkbox and associated information (such as how many backups to keep) can be added to the settings dialog by adding new elements in the forms/SettingsDlg.ui file.

3. Testing

There are several steps to testing this feature. For this to be considered a success I need to ensure that:

i) the new options appear in the settings menu.
ii) the getter and setter functions for the option are properly updating the config file.
iii) the application is copying the database to a new file (at the appropriate time, for example when a database is opened).
iv) the application backs up every database (or every specified database if this functionality is added).
v) the backup versions of the database can be opened by KeePassX.
vi) the application does not create more backups than specified by the user.
vii) the patch I create applies cleanly to the latest SVN revision and builds without errors.

4. Dependencies

None really.

5. Estimated Time to Complete

Roughly 2 weeks from today for reasonable functionality (at least one backup, and a user-specified location). Thus, the estimated date this would be ready is April 21, 2008.

[Tarek]

I also already thought about a backup function, so let me add two points to the implementation requirements:

1. There should be an abstraction layer between the backup function itself and the filessystem, so that it is easy to extent the backup module for example for a remote backup functionality via FTP or SCP.
2. The backup should happen asynchronously, i.e. in an extra thread.
3. The backup should be job based, because in case of remote backups the server or the internet connection could be slow or busy which should not block anything. A backup job queue would allow to open another database even if the backup of the last one is still in process.

[bdmayes]

Tarek you make some good points. I thought about making it a thread because I certainly don't want it to block the entire application in case some resource was unavailable (i.e. an external hard drive). A few questions/comments:

1. Do you think it's necessary to allow a user to store more than one backup? I can either add a checkbox to SettingsDlg.ui (which means true or false it is going to take a backup when the database is opened), or I can add in a QSpinBox so that the user can specify some rolling number of backups to keep (which allows a "history" of the database in some sense). Perhaps some of the users here can voice their opinion, but I'm starting to wonder whether or not multiple backups are really necessary. I'm leaning towards allowing only one backup at the moment.

2. In regard to the abstraction layer, I'm thinking that in order to implement this I would create a "Backup" class that would be the parent (actually...I believe Backup would be a child of QThread). Then we could define new children for each implementation of backups. I was not planning on offering more than a simple filesystem backup, though perhaps later it would be possible to say something like

Code: Select all

SCPBackup : Backup {

// run method here would call the scp command instead

}


Then a new option can be added later to the SettingsDlg.ui which specifies how the backup will actually be done. Selecting this new option would cause a new child of Backup (such as SCPBackup) to call their unique run() method which does the backup via scp. Does this sound reasonable then?

3. As far a queue of backups to be run, I was thinking of having the thread sleep while the resource it was waiting on is unavailable. For example, if it were waiting on some network resource (such as a mount point to become available) it would just sleep. So something like:

Code: Select all

while (!mountPointAvailable()) {
    sleep(5000);
}

// once it gets here then the thread saves


I suppose in this case it would be possible for the second thread to obtain and write the resource first. For example, it's possible that we open database1.kdb. While it's waiting for a network drive, we open database2.kdb. The thread to write database2.kdb finds the resource and makes a backup, and then the thread to write database1.kdb finds the resource and makes a backup. So order is not necessarily preserved, but since it's a new thread it should not be blocking the keepassx process from going about its business. So I'm not entirely sure if a queue is necessary..???

[Tarek]

As far a queue of backups to be run, I was thinking of having the thread sleep while the resource it was waiting on is unavailable. For example, if it were waiting on some network resource (such as a mount point to become available) it would just sleep. So something like:

You are probably right, sending the thread to sleep should be sufficient... nobody opens 100 databases in 5 seconds or so...

[bdmayes]

Hi Tarek,

I have completed a patch that works for making backups. I have a few issues with it that I'm not quite sure how to handle, and I'm hoping that someone else on here might offer some advice on how to improve things. As it stands right now, I can patch revision 196 (the latest in SVN right now) and it works fine.

I have started a new thread in the "code discussion" section, as I believe it's a more appropriate place for such a discussion. Please go have a look. Thanks!

http://www.keepassx.org/forum/viewtopic.php?t=1622

[Tomfille]

Hi Tarek,

I have completed a patch that works for making backups. I have a few issues with it that I'm not quite sure how to handle, and I'm hoping that someone else on here might offer some advice on how to improve things. As it stands right now, I can patch revision 196 (the latest in SVN right now) and it works fine.

I have started a new thread in the "code discussion" section, as I believe it's a more appropriate place for such a discussion. Please go have a look. Thanks!

http://www.keepassx.org/forum/viewtopic.php?t=1622

Good job, is there still any progress on further fixes?