Comment # 8
on bug 82863
from Patrick Ohly
Fixed in the following commit (not merged into master yet, commit hash will
change):
commit a4ab216aff40aab6685f369dd13bb05993dbfd47
Author: Patrick Ohly <patrick.ohly@intel.com>
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
linux-bluetooth@vger.kernel.org), 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 <patrick.ohly@intel.com>
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.