On Mo, 2011-08-29 at 17:22 +0200, Mikel Astiz wrote: > Hi all, > > I am trying to synchronize a Nokia phone (6303i Classic) over Bluetooth > with SyncEvolution, and I'm experiencing problems when > "refresh-from-client" is used.
First, are you aware that the phone is the client in that context? So you are asking for your local data on the desktop to be replaced with the data on the phone. > The synchronization process starts but > then stalls indefinitely until timeouted or manually cancelled. > > The output I get is the following: > obex_parse_connect_header(): requested MTU=32767, used MTU=32767 > [INFO] Server sending SAN > obex_data_request(): len = 104 bytes > fdobex_write(): sending 104 bytes > obex_data_indication(): Got 0 bytes msg len=3 > obex_data_request(): len = 40 bytes > fdobex_write(): sending 40 bytes > obex_data_indication(): Got 1005 bytes msg len=1008 > obex_data_indication(): Got 971 bytes msg len=1979 > obex_data_request(): len = 4821 bytes > fdobex_write(): sending 4821 bytes > obex_data_indication(): Got 0 bytes msg len=3 > obex_data_request(): len = 40 bytes > fdobex_write(): sending 40 bytes I suspect that the phone simply doesn't support this mode of operation. > With the same phone and configuration, it works fine with both "--sync > slow" and "--sync one-way-from-client". > > Is there any specific configuration regarding the mode > "refresh-from-client"? No. > Any ideas on how to debug this issue? If the output above is all you get, then I can't think of anything. There may be a workaround: delete all local data, then ask for a slow sync. That could even be implemented as default in SyncEvolution when the server initiates the sync. Either do it before sending the SAN message (has the drawback that the data is definitely gone, even if the sync never starts), or do it as part of the initialization in the server after the client has started the sync. I think SyncContext::getConfigXML() might be a good place. It already contains some logic for server-initiated syncs, see m_serverMode and m_remoteInitiated. I don't know of the top of my head whether the "SyncSource *source" there was already opened(). If it is, then adding a new method deleteAllItems() to the SyncSource API would make sense, with a default implementation that uses the startDataWrite/readNextItem/deleteItem/endDataWrite Operations. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
