Patrick Ohly changed bug 82863
What Removed Added
Status ASSIGNED RESOLVED
Resolution --- FIXED

Comment # 8 on bug 82863 from
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.


You are receiving this mail because: