On Mon, 2019-06-03 at 12:47 +0100, Patrick O'Callaghan wrote:
> In which case I think the argument about how to make sure Evo is
> stopped before doing a backup is pointless. Just don't stop it.
Hi,
it depends on the actual part of the Evolution.
Talking about Mail, then things which can be seen in the message list
are part of an sqlite database, thus there is involved some
transaction-ing, but not everything is there, like the list of folders
for the account can be a binary file (or in case of evolution-ews an
.ini-like file). These do not support transactions. Indexes on the
folder are also not updated in a transaction, they are other binary
files. It depends on the actual account type, the above applies for
IMAP. The POP3 is different, it has in its cache a file with known
UIDs. Terminating the process (or interrupt it) during the download of
the messages could cause that the to-be-downloaded messages were not
shown in Evolution, because the file with known UIDs had been updated
before the messages had been downloaded and transferred into the On
This Computer storage (which is Maildir, which works similarly as IMAP
in this regard). I recall there was such bug long time ago. The fix for
that was (I believe) to update the known UIDs cache for the POP3
account only after those messages are properly propagated into the On
This Computer.
Talking about all the other four parts of Evolution, the main part runs
on the factory side (evolution-addressbook-factory and evolution-
calendar-factory, eventually its ...-subprocess processes). Again,
depending on the type of the backend, some can support transactions,
but some not. For example LDAP and On This Computer (apart of the
Contacts) still do not support it, while all the other do since
~3.26.0, using sqlite database for the local cache. There is currently
no real (and used) API to tell the backends to dump their data to the
disk, to indicate that the calling application wants to do any
operation on the underlying files.
I'd say, generally speaking, that it's the safest to close the
applications/processes which access the files of the interest before
doing anything with them (being it backup or restore or ...), to avoid
conflicts in read/write, applications-side in-memory caching, and so
on. As I mentioned earlier in this thread, it's not always possible
with the calendar factory. The built-in backup/restore just hopes that
the backed up data will be consistent, without closing background
processes. It's different with the restore operation.
Evolution's main "issue" is that it backs up data used by the
evolution-data-server processes, which are shared between more
applications. It has its advantages and disadvantages, in various ways.
The evolution-backup tool surely doesn't want to store the .running
file, because it's not only an exists/does-not-exist file, it contains
also PID of the running evolution. That PID is used within
`evolution --force-shutdown` (in the `killev`). When it exists, it
tries to close evolution gracefully, using 'evolution --quit' and it is
waiting for 5 seconds to have the .running file disappeared. If it's
still there after the timeout, then a SIGTERM is sent to that stored
PID, which can have consequences, when that process is not Evolution.
Remember, these are internal Evolution(-data-server) files (not that an
evolution crash cannot confuse killev).
Bye,
Milan
_______________________________________________
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
