#3 Contacts are not saved if a second abook is open

[Denis Briand]

Hello,
see: https://bugs.debian.org/589392
A debian user says:

If a second abook opened in another xterm, add contact not saved, those arent saved on the current abook, when I close all and start a abook session

To reproduce it:
1- open abook into a first xterm window
2- open abook again into a second window
3- In this second window, add a new 'test' contact
4- Close both of windows
5- open again abook... 'test' contact doesn't here

Many thanks

regards

Denis

[Raphaël]

Indeed.
A first step in a race-less abook was started here:
https://sourceforge.net/p/abook/mailman/message/32316897/
[You need to forgive sf.net archives for the lack of email mime support]

The point was to:
1. clearly identify when is the database modified (in memory)
2. and show it in abook's UI
I can push that soon in master.
Next step is:
3. don't rewrite the database if no changes exists (and autosave = on).
It would reduce by a large factor the risks.

Then, later and optionally:
- use inotify to monitor the database and if an external change happened, reload (and if needed merge or abort current changes from the UI if needed)
- or lock the file in some way as soon as unsaved changes exist so that --add would fail
- ... other options are possible

1 and 2 are easy and foolproof, the worst case being that the database is modified but the indicator does not show it.
3 is just about putting a condition over database write according to the database "dirtyness" statut and autosave option.
The only major risk is overlooking one or more code paths modifying the database.
The compatibility with autosave needs to be thought a bit (we would rather make the "save on exit only if needed" mandatory)

[Raphaël]

Somehow fixed in aef4219d2 part of 0.6.2
As long as the long-running interactive instance doesn't make change to the DB, it can be modified externally.

[Raphaël]

I realized the feature was only enabled for DEBUG builds.
I made it the default now, in 7c85eaa