Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I am not sure if this a bug or a feature request. ...... when I sync via SFTP its a fairly slow process. It takes a few minutes. If Keepass hasn't locked itself after completion of the sync I see a message in the status bar at the bottom 'Sync completed successfully' However, if I walk away while the sync is running and return sometime later after Keepass has locked itself automatically, then when I unlock Keepass the status bar now just shows ready and I cannot tell if the sync did complete successfully or not.
Is there a sync log somewhere or some way a sync successful message could remain after the unlock?
There is no log. However, KeePass will not lock while sub window is open so you can assume the sync completed.
I have never seen a failed sync message, but if it were a sub window it would prevent KeePass from locking.
I wasn't going to mention it because it only happened once. I did have sync fail badly. It deleted my local database. I found out when I tried to open keepass after a sync and my database was gone. When I checked in the folder only a tmp was there.
Now I use DBbackup which automatically creates a backup at some point during the sync process; after a save I think. I hope this saves me the if the problem happens again.
If this does happen again could I also recover the database from the tmp file left in the same folder ?
The tmp file is your new database, waiting to be renamed "kdbx". You can rename it manually, or open it as a tmp file.
Same thing happened for me just now.
Recovered it from Dropbox that showed that I deleted it!!!
I tried to rename the tmp to kdb as Paul says, it did work, thank you Paul.
But can someone explain why this happens?
What I did to provoke it was creating a new entry, and when click on the save database it came with an error, something like can´t save an existing file.
After that it was changed to tmp !!!
Have a great day
KeePass writes the new database by deleting the old database the writing a new one. By default it uses file transactions so that the new db is first written to a tmp file, the old db deleted, and tmp db rename to the original name. Failures are very rare, but something went wrong in your case.
In the usual Dropbox configuration, KeePass writes to a local Dropbox managed folder, and Dropbox manages the cloud file replication process separately. I speculate that it might be possible for Dropbox replication operations to very occasionally disrupt one or more of the KeePass save operations. Or it may have just been an unfortunate hiccup.
Implementing the Dropbox sync trigger, rather than saving the active database directly to the Dropbox folder, may not eliminate the issue. But it should increase the likelihood that you have the current version of your database saved as your local working database. This could be useful if you encounter the problem again immediately after making a significant change in KeePass.