Fixed in the following commit (not merged into master yet, commit hash will change): commit a4ab216aff40aab6685f369dd13bb05993dbfd47 Author: Patrick Ohly <firstname.lastname@example.org> Date: Tue Aug 26 17:03:23 2014 +0200 PIM: handle SuspendPeer() before and after transfer (FDO #82863) A SuspendPeer() only succeeded while the underlying Bluetooth transfer was active. Outside of that, Bluez errors caused SyncEvolution to attempt a cancelation of the transfer and stopped the sync. When the transfer was still queueing, obexd returns org.bluez.obex.Error.NotInProgress. This is difficult to handle for SyncEvolution: it cannot prevent the transfer from starting and has to let it become active before it can suspend the transfer. Canceling would lead to difficult to handle error cases (like partially parsed data) and therefore is not done. The Bluez team was asked to implement suspending of queued transfers (see "org.bluez.obex.Transfer1 Suspend/Resume in queued state" on email@example.com), so this case might not happen anymore with future Bluez. When the transfer completes before obexd processes the Suspend(), org.freedesktop.DBus.Error.UnknownObject gets returned by obexd. SyncEvolution can ignore errors which occur after the active transfer completed. In addition, it should prevent starting the next one. This may be relevant for transfer in chunks, although the sync engine will also stop asking for data and thus typically no new transfer gets triggered anyway. Also note that sync.py can now be used to test this: commit 9423ffea53252350dc8c1c835f2e56107b6bef8b Author: Patrick Ohly <firstname.lastname@example.org> Date: Tue Aug 26 16:46:21 2014 +0200 PIM: add suspend/resume/abort to sync.py CTRL-C while waiting for the end of a sync causes an interactive prompt to appear where one can choose been suspend/resume/abort and continuing to wait. CTRL-C again in the prompt aborts the script. I was not able to come up with reliable automated testing for the different situations.