https://bugs.freedesktop.org/show_bug.cgi?id=72112
Patrick Ohly <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Patrick Ohly <[email protected]> --- SyncEvolution 1.4.99.1 also uses Bluez >= 5.15 Suspend/Resume to really freeze the transfer. By default, the new API freezes a sync by stopping to consume data on the local side of the sync. In addition, the information that the sync is freezing is now also handed down to the transport and all sources. In the case of PBAP caching, the local transport notifies the child where the PBAP source then uses Bluez 5.15 Transfer1.Suspend/Resume to freeze/thaw the actual OBEX transfer. If that fails (for example, not implemented because Bluez is too old or the transfer is still queueing), then the transfer gets cancelled and the entire sync fails. This is desirable for PBAP caching and Bluetooth because a failed sync can easily be recovered from (just start it again) and the overall goal is to free up Bluetooth bandwidth quickly. -- You are receiving this mail because: You are on the CC list for the bug.
_______________________________________________ Syncevolution-issues mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution-issues
