Syncing with the P1i

[Martin Zoller-2]

Hi all
I tried to sync my SonyEricsson P1i with Horde using WiFi and the
phone's built-in "remote sync" application. For this purpose I installed
*Horde Groupware Webmail Edition* *1.2.4 on a webspace.
At first it didn't work: The phone said the sync was successful, but
there was no data in the Groupware applications. So I created /tmp/sync
and synced again to get logfiles. And this was the error that occurred
at every item:
--
DEBUG:  Handling <Replace> sent from client
ERR:    Item size mismatch. Size reported as 182 but actual size is 180
--
Apparently all the data was discarded because the specified size is
always 2 bytes too big. The easiest workaround was to patch Sync.php so
that this mismatch would only generate a warning and the data would be
kept. And now it works - I can backup all my PIM data on Horde. Here's
the diff:

-- begin Sync.php workaround --
221c221
<                 $item->responseCode = RESPONSE_SIZE_MISMATCH;
---
>                 //$item->responseCode = RESPONSE_SIZE_MISMATCH;
225,227c225,227
<                     __FILE__, __LINE__, PEAR_LOG_ERR);
<                 $this->_errors++;
<                 return false;
---
>                     __FILE__, __LINE__,
PEAR_LOG_WARNING/*PEAR_LOG_ERR*/);
>                 //$this->_errors++;
>                 //return false;
-- end Sync.php workaround --

The following problems persist:

- Contact categories are not synced yet. This should be easy to
implement since Turba has basic support for the "category" field.

- The P1i has a common database for calendar and tasks, even though they
are handled by separate applications on the phone. To backup my data, I
need to sync this DB first with the "calendar", then with the "tasks"
database. Therefore I can only do a one-way backup, since an actual sync
would always destroy half the data on the phone. Maybe Horde could
emulate a "caltask" database and automatically split the data into
appointments and tasks. mobical.net supports this, and it works perfectly.

And here are some logfiles:
http://zoller.tv/temp/log1.txt - a sync with the error (contacts only)
**http://zoller.tv/temp/log2.txt - a successful sync (contacts only)

**Should I add some information to the wiki as well? I think it would be
useful to offer the patched Sync.php for download somewhere - it's
currently at http://zoller.tv/temp/Sync.php.
Sorry for the long mail.
**

Best regards,
Martin
*

--
sync mailing list - Join the hunt: http://horde.org/bounties/#sync
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: sync-unsubscribe@...

[Jan Schneider]

Zitat von Martin Zoller <mailinglists@...>:

> Hi all
> I tried to sync my SonyEricsson P1i with Horde using WiFi and the
> phone's built-in "remote sync" application. For this purpose I installed
> *Horde Groupware Webmail Edition* *1.2.4 on a webspace.
> At first it didn't work: The phone said the sync was successful, but
> there was no data in the Groupware applications. So I created /tmp/sync
> and synced again to get logfiles. And this was the error that occurred
> at every item:
> --
> DEBUG:  Handling <Replace> sent from client
> ERR:    Item size mismatch. Size reported as 182 but actual size is 180
> --
> Apparently all the data was discarded because the specified size is
> always 2 bytes too big. The easiest workaround was to patch Sync.php so
> that this mismatch would only generate a warning and the data would be
> kept. And now it works - I can backup all my PIM data on Horde. Here's
> the diff:
>
> -- begin Sync.php workaround --
> 221c221
> <                 $item->responseCode = RESPONSE_SIZE_MISMATCH;
> ---
>>                //$item->responseCode = RESPONSE_SIZE_MISMATCH;
> 225,227c225,227
> <                     __FILE__, __LINE__, PEAR_LOG_ERR);
> <                 $this->_errors++;
> <                 return false;
> ---
>>                    __FILE__, __LINE__,
> PEAR_LOG_WARNING/*PEAR_LOG_ERR*/);
>>                //$this->_errors++;
>>                //return false;
> -- end Sync.php workaround --

And who is wrong, the phone or Horde? Did you take a look at the  
logged client messages?

> The following problems persist:
>
> - Contact categories are not synced yet. This should be easy to
> implement since Turba has basic support for the "category" field.
>
> - The P1i has a common database for calendar and tasks, even though they
> are handled by separate applications on the phone. To backup my data, I
> need to sync this DB first with the "calendar", then with the "tasks"
> database. Therefore I can only do a one-way backup, since an actual sync
> would always destroy half the data on the phone. Maybe Horde could
> emulate a "caltask" database and automatically split the data into
> appointments and tasks. mobical.net supports this, and it works perfectly.

Horde does support it too. And the device driver for your phone  
actually has a check for it. Can you post the logged devinf file?

> And here are some logfiles:
> http://zoller.tv/temp/log1.txt - a sync with the error (contacts only)
> **http://zoller.tv/temp/log2.txt - a successful sync (contacts only)
>
> **Should I add some information to the wiki as well? I think it would be
> useful to offer the patched Sync.php for download somewhere - it's
> currently at http://zoller.tv/temp/Sync.php.
> Sorry for the long mail.
> **
>
> Best regards,
> Martin
> *
>
> --
> sync mailing list - Join the hunt: http://horde.org/bounties/#sync
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: sync-unsubscribe@...
>

Jan.

--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/

--
sync mailing list - Join the hunt: http://horde.org/bounties/#sync
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: sync-unsubscribe@...

[Martin Zoller-2]

Jan Schneider wrote:
> And who is wrong, the phone or Horde? Did you take a look at the
> logged client messages?
Looks like the phone is wrong. I've checked a few entries from the
client messages with a binary editor, and they have exactly the length
that Horde claims they have (and two bytes less than the phone says). I
assume you have to count from "BEGIN:VCARD" to "END:VCARD"?

>> The following problems persist:
>>
>> - Contact categories are not synced yet. This should be easy to
>> implement since Turba has basic support for the "category" field.
>>
>> - The P1i has a common database for calendar and tasks, even though they
>> are handled by separate applications on the phone. To backup my data, I
>> need to sync this DB first with the "calendar", then with the "tasks"
>> database. Therefore I can only do a one-way backup, since an actual sync
>> would always destroy half the data on the phone. Maybe Horde could
>> emulate a "caltask" database and automatically split the data into
>> appointments and tasks. mobical.net supports this, and it works
>> perfectly.
> Horde does support it too. And the device driver for your phone
> actually has a check for it. Can you post the logged devinf file?

Oh, now I've found where this is handled. Still, it doesn't seem to work.
Here is my devinf.txt for a calendar backup (which should include tasks):

SyncML_DeviceInfo::__set_state(array(
   'VerDTD' => '1.2',
   'Man' => 'Sony Ericsson',
   'Mod' => 'P1i',
   'OEM' => 'SymbianUK',
   'FwV' => '0',
   'SwV' => 'Z1.0.1',
   'HwV' => '1.0',
   'DevID' => 'IMEI:357033010722247',
   'DevTyp' => 'smartphone',
   'DataStores' =>
  array (
    0 =>
    SyncML_DataStore::__set_state(array(
       'SourceRef' => 'C:Calendar',
       'DisplayName' => 'Agenda',
       'MaxGUIDSize' => NULL,
       'Rx_Pref' =>
      array (
        'text/x-vcalendar' => '1.0',
      ),
       'Rx' =>
      array (
        'text/x-vcalendar' => '1.0',
      ),
       'Tx_Pref' =>
      array (
        'text/x-vcalendar' => '1.0',
      ),
       'Tx' =>
      array (
        'text/x-vcalendar' => '1.0',
      ),
       'DSMem' => NULL,
       'SyncCap' =>
      array (
        1 => true,
        2 => true,
        3 => true,
        5 => true,
        6 => true,
        4 => true,
        7 => true,
      ),
    )),
  ),
   'CTCaps' => NULL,
   'Exts' => NULL,
   'UTC' => true,
   'SupportLargeObjs' => true,
   'SupportNumberOfChanges' => true,
))

So 'CTCaps' apparently isn't set, and this is where Horde checks for the
mixed Calendar/Todo database! If I let the handleTasksInCalendar()
function in P800.php simply return true, the tasks are processed too. :-)
Could this CTCaps thing be a bug in Put.php? I'll send Jan a client
response file to check this.


Cheers
Martin

--
sync mailing list - Join the hunt: http://horde.org/bounties/#sync
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: sync-unsubscribe@...

[Jan Schneider]

Zitat von Martin Zoller <mailinglists@...>:

> Jan Schneider wrote:
>> And who is wrong, the phone or Horde? Did you take a look at the  
>> logged client messages?
> Looks like the phone is wrong. I've checked a few entries from the
> client messages with a binary editor, and they have exactly the length
> that Horde claims they have (and two bytes less than the phone says). I
> assume you have to count from "BEGIN:VCARD" to "END:VCARD"?

 From the start to the end of the embedding <Data> tag.

>>> The following problems persist:
>>>
>>> - Contact categories are not synced yet. This should be easy to
>>> implement since Turba has basic support for the "category" field.
>>>
>>> - The P1i has a common database for calendar and tasks, even though they
>>> are handled by separate applications on the phone. To backup my data, I
>>> need to sync this DB first with the "calendar", then with the "tasks"
>>> database. Therefore I can only do a one-way backup, since an actual sync
>>> would always destroy half the data on the phone. Maybe Horde could
>>> emulate a "caltask" database and automatically split the data into
>>> appointments and tasks. mobical.net supports this, and it works perfectly.
>> Horde does support it too. And the device driver for your phone  
>> actually has a check for it. Can you post the logged devinf file?
> Oh, now I've found where this is handled. Still, it doesn't seem to work.
> Here is my devinf.txt for a calendar backup (which should include tasks):
>
> SyncML_DeviceInfo::__set_state(array(
>   'VerDTD' => '1.2',
>   'Man' => 'Sony Ericsson',
>   'Mod' => 'P1i',
>   'OEM' => 'SymbianUK',
>   'FwV' => '0',
>   'SwV' => 'Z1.0.1',
>   'HwV' => '1.0',
>   'DevID' => 'IMEI:357033010722247',
>   'DevTyp' => 'smartphone',
>   'DataStores' =>
>  array (
>    0 =>
>    SyncML_DataStore::__set_state(array(
>       'SourceRef' => 'C:Calendar',
>       'DisplayName' => 'Agenda',
>       'MaxGUIDSize' => NULL,
>       'Rx_Pref' =>
>      array (
>        'text/x-vcalendar' => '1.0',
>      ),
>       'Rx' =>
>      array (
>        'text/x-vcalendar' => '1.0',
>      ),
>       'Tx_Pref' =>
>      array (
>        'text/x-vcalendar' => '1.0',
>      ),
>       'Tx' =>
>      array (
>        'text/x-vcalendar' => '1.0',
>      ),
>       'DSMem' => NULL,
>       'SyncCap' =>
>      array (
>        1 => true,
>        2 => true,
>        3 => true,
>        5 => true,
>        6 => true,
>        4 => true,
>        7 => true,
>      ),
>    )),
>  ),
>   'CTCaps' => NULL,
>   'Exts' => NULL,
>   'UTC' => true,
>   'SupportLargeObjs' => true,
>   'SupportNumberOfChanges' => true,
> ))
>
> So 'CTCaps' apparently isn't set, and this is where Horde checks for the
> mixed Calendar/Todo database! If I let the handleTasksInCalendar()
> function in P800.php simply return true, the tasks are processed too. :-)
> Could this CTCaps thing be a bug in Put.php? I'll send Jan a client
> response file to check this.

The SyncML message structure was indeed different from anything that I  
have seen so far. Thus the CTCap information wasn't correctly parsed  
out of the DevInf tag.
Please try if this is fixed with the following patch:
http://cvs.horde.org/diff.php/framework/SyncML/SyncML/Command/Put.php?rt=horde&r1=1.12.10.13&r2=1.12.10.14&ty=u

Jan.

--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/

--
sync mailing list - Join the hunt: http://horde.org/bounties/#sync
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: sync-unsubscribe@...

[Jan Schneider]

Please keep discussions on the list.

Zitat von Martin Zoller <martin@...>:

> Jan Schneider wrote:
>> From the start to the end of the embedding <Data> tag.
> The thing is, I only have the *.wbxml files and they are binary. I  
> think there is no <Data> tag there.

You can decode them with wbxml2xml.

>> The SyncML message structure was indeed different from anything  
>> that I have seen so far. Thus the CTCap information wasn't  
>> correctly parsed out of the DevInf tag.
>> Please try if this is fixed with the following patch:
>> http://cvs.horde.org/diff.php/framework/SyncML/SyncML/Command/Put.php?rt=horde&r1=1.12.10.13&r2=1.12.10.14&ty=u
> Yes, the patch fixes it. Thanks!

Jan.

--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/

--
sync mailing list - Join the hunt: http://horde.org/bounties/#sync
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: sync-unsubscribe@...

[Martin Zoller-2]

Good afternoon

Jan Schneider wrote:
> Please keep discussions on the list.
Sorry, I must have used "reply" instead of "reply all".

>
>> The thing is, I only have the *.wbxml files and they are binary. I
>> think there is no <Data> tag there.
>
> You can decode them with wbxml2xml.
OK. The sizes don't make sense to me yet. Take this item, for example:

<Replace>
    <CmdID>9</CmdID>
    <Meta>
     <Type xmlns="syncml:metinf">text/x-vcard</Type>
     <Size xmlns="syncml:metinf">153</Size>
    </Meta>
    <Item>
     <Source>
      <LocURI>59</LocURI>
     </Source>
     <Meta>
      <Type xmlns="syncml:metinf">text/x-vcard</Type>
     </Meta>
     <Data><![CDATA[BEGIN:VCARD
VERSION:2.1
REV:20090910T144434Z
UID:14ecf97979509240-00e1365b3ef3b7c5-425
N:Westman;Aron;;;
TEL;WORK;VOICE;CELL:0733665130
END:VCARD
]]></Data>
    </Item>
   </Replace>

There are 165 bytes between <Data> and </Data>.
The <Size> tag specifies the size as 153. In log.txt it says:
ERR:    Item size mismatch. Size reported as 153 but actual size is 151
So I guess the <![CDATA[  ]]> tags are not counted? Because if you count
only the actual VCARD data (including BEGIN:VCARD and END:VCARD), you
get exactly 151 bytes.


Cheers
Martin

--
sync mailing list - Join the hunt: http://horde.org/bounties/#sync
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: sync-unsubscribe@...

[Jan Schneider]

Zitat von Martin Zoller <mailinglists@...>:

> Good afternoon
>
> Jan Schneider wrote:
>> Please keep discussions on the list.
> Sorry, I must have used "reply" instead of "reply all".
>
>>
>>> The thing is, I only have the *.wbxml files and they are binary. I  
>>> think there is no <Data> tag there.
>>
>> You can decode them with wbxml2xml.
> OK. The sizes don't make sense to me yet. Take this item, for example:
>
> <Replace>
>    <CmdID>9</CmdID>
>    <Meta>
>     <Type xmlns="syncml:metinf">text/x-vcard</Type>
>     <Size xmlns="syncml:metinf">153</Size>
>    </Meta>
>    <Item>
>     <Source>
>      <LocURI>59</LocURI>
>     </Source>
>     <Meta>
>      <Type xmlns="syncml:metinf">text/x-vcard</Type>
>     </Meta>
>     <Data><![CDATA[BEGIN:VCARD
> VERSION:2.1
> REV:20090910T144434Z
> UID:14ecf97979509240-00e1365b3ef3b7c5-425
> N:Westman;Aron;;;
> TEL;WORK;VOICE;CELL:0733665130
> END:VCARD
> ]]></Data>
>    </Item>
>   </Replace>
>
> There are 165 bytes between <Data> and </Data>.
> The <Size> tag specifies the size as 153. In log.txt it says:
> ERR:    Item size mismatch. Size reported as 153 but actual size is 151
> So I guess the <![CDATA[  ]]> tags are not counted? Because if you count
> only the actual VCARD data (including BEGIN:VCARD and END:VCARD), you
> get exactly 151 bytes.

The CDATA is part of the XML markup, so 153 is correct. My guess is  
that the phone doesn't count the trailing line break. Trimming the  
<Data> content would probably fix that, but I'm afraid that might  
break other clients.

Jan.

--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/

--
sync mailing list - Join the hunt: http://horde.org/bounties/#sync
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: sync-unsubscribe@...

[Martin Zoller-2]

Hello

I think you're right about the linebreak, Jan. But that would mean that
*Horde* doesn't count it, because the higher number (153 bytes) comes
from the *phone*. That's because the data already gets trimmed: In
Command/Sync.php on line 225.
Now that we have this explanation for the size mismatch, it wouldn't be
too elegant to just accept "wrong" size specifications as in Arvid's
patch. Maybe we should store the 'trimmed' and the 'untrimmed' length of
the data and accept both of them? Because removing the trim() commands
might break other clients.

Have a nice weekend.
Martin

Jan Schneider wrote:

> Zitat von Martin Zoller <mailinglists@...>:
>
>> Good afternoon
>>
>> Jan Schneider wrote:
>>> Please keep discussions on the list.
>> Sorry, I must have used "reply" instead of "reply all".
>>
>>>
>>>> The thing is, I only have the *.wbxml files and they are binary. I
>>>> think there is no <Data> tag there.
>>>
>>> You can decode them with wbxml2xml.
>> OK. The sizes don't make sense to me yet. Take this item, for example:
>>
>> <Replace>
>>    <CmdID>9</CmdID>
>>    <Meta>
>>     <Type xmlns="syncml:metinf">text/x-vcard</Type>
>>     <Size xmlns="syncml:metinf">153</Size>
>>    </Meta>
>>    <Item>
>>     <Source>
>>      <LocURI>59</LocURI>
>>     </Source>
>>     <Meta>
>>      <Type xmlns="syncml:metinf">text/x-vcard</Type>
>>     </Meta>
>>     <Data><![CDATA[BEGIN:VCARD
>> VERSION:2.1
>> REV:20090910T144434Z
>> UID:14ecf97979509240-00e1365b3ef3b7c5-425
>> N:Westman;Aron;;;
>> TEL;WORK;VOICE;CELL:0733665130
>> END:VCARD
>> ]]></Data>
>>    </Item>
>>   </Replace>
>>
>> There are 165 bytes between <Data> and </Data>.
>> The <Size> tag specifies the size as 153. In log.txt it says:
>> ERR:    Item size mismatch. Size reported as 153 but actual size is 151
>> So I guess the <![CDATA[  ]]> tags are not counted? Because if you count
>> only the actual VCARD data (including BEGIN:VCARD and END:VCARD), you
>> get exactly 151 bytes.
>
> The CDATA is part of the XML markup, so 153 is correct. My guess is
> that the phone doesn't count the trailing line break. Trimming the
> <Data> content would probably fix that, but I'm afraid that might
> break other clients.
>
> Jan.
>

--
sync mailing list - Join the hunt: http://horde.org/bounties/#sync
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: sync-unsubscribe@...

[Jan Schneider]

Zitat von Martin Zoller <mailinglists@...>:

> Hello
>
> I think you're right about the linebreak, Jan. But that would mean that
> *Horde* doesn't count it, because the higher number (153 bytes) comes
> from the *phone*. That's because the data already gets trimmed: In
> Command/Sync.php on line 225.

Gotcha! I got the numbers wrong, so this seems to be a bug in Horde.

> Now that we have this explanation for the size mismatch, it wouldn't be
> too elegant to just accept "wrong" size specifications as in Arvid's
> patch. Maybe we should store the 'trimmed' and the 'untrimmed' length of
> the data and accept both of them? Because removing the trim() commands
> might break other clients.

Well, if it does, then *those* clients are broken, and we have to find  
a workaround for it. I guess it works for most clients, because they  
don't include a trailing CRLF.

> Jan Schneider wrote:
>> Zitat von Martin Zoller <mailinglists@...>:
>>
>>> Good afternoon
>>>
>>> Jan Schneider wrote:
>>>> Please keep discussions on the list.
>>> Sorry, I must have used "reply" instead of "reply all".
>>>
>>>>
>>>>> The thing is, I only have the *.wbxml files and they are binary.  
>>>>> I think there is no <Data> tag there.
>>>>
>>>> You can decode them with wbxml2xml.
>>> OK. The sizes don't make sense to me yet. Take this item, for example:
>>>
>>> <Replace>
>>>   <CmdID>9</CmdID>
>>>   <Meta>
>>>    <Type xmlns="syncml:metinf">text/x-vcard</Type>
>>>    <Size xmlns="syncml:metinf">153</Size>
>>>   </Meta>
>>>   <Item>
>>>    <Source>
>>>     <LocURI>59</LocURI>
>>>    </Source>
>>>    <Meta>
>>>     <Type xmlns="syncml:metinf">text/x-vcard</Type>
>>>    </Meta>
>>>    <Data><![CDATA[BEGIN:VCARD
>>> VERSION:2.1
>>> REV:20090910T144434Z
>>> UID:14ecf97979509240-00e1365b3ef3b7c5-425
>>> N:Westman;Aron;;;
>>> TEL;WORK;VOICE;CELL:0733665130
>>> END:VCARD
>>> ]]></Data>
>>>   </Item>
>>>  </Replace>
>>>
>>> There are 165 bytes between <Data> and </Data>.
>>> The <Size> tag specifies the size as 153. In log.txt it says:
>>> ERR:    Item size mismatch. Size reported as 153 but actual size is 151
>>> So I guess the <![CDATA[  ]]> tags are not counted? Because if you count
>>> only the actual VCARD data (including BEGIN:VCARD and END:VCARD), you
>>> get exactly 151 bytes.
>>
>> The CDATA is part of the XML markup, so 153 is correct. My guess is  
>> that the phone doesn't count the trailing line break. Trimming the  
>> <Data> content would probably fix that, but I'm afraid that might  
>> break other clients.
>>
>> Jan.
>>
>
>
> --
> sync mailing list - Join the hunt: http://horde.org/bounties/#sync
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: sync-unsubscribe@...
>

Jan.

--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/

--
sync mailing list - Join the hunt: http://horde.org/bounties/#sync
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: sync-unsubscribe@...

[Jan Schneider]

Zitat von Jan Schneider <jan@...>:

> Zitat von Martin Zoller <mailinglists@...>:
>
>> Hello
>>
>> I think you're right about the linebreak, Jan. But that would mean that
>> *Horde* doesn't count it, because the higher number (153 bytes) comes
>> from the *phone*. That's because the data already gets trimmed: In
>> Command/Sync.php on line 225.
>
> Gotcha! I got the numbers wrong, so this seems to be a bug in Horde.
>
>> Now that we have this explanation for the size mismatch, it wouldn't be
>> too elegant to just accept "wrong" size specifications as in Arvid's
>> patch. Maybe we should store the 'trimmed' and the 'untrimmed' length of
>> the data and accept both of them? Because removing the trim() commands
>> might break other clients.
>
> Well, if it does, then *those* clients are broken, and we have to  
> find a workaround for it. I guess it works for most clients, because  
> they don't include a trailing CRLF.

Try this:
http://cvs.horde.org/diff.php/framework/SyncML/SyncML/Command/Sync.php?rt=horde&r1=1.17.10.18&r2=1.17.10.19&ty=u

Jan.

--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/

--
sync mailing list - Join the hunt: http://horde.org/bounties/#sync
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: sync-unsubscribe@...

[Martin Zoller-2]

Jan Schneider wrote:

> Zitat von Jan Schneider <jan@...>:
>
>> Zitat von Martin Zoller <mailinglists@...>:
>>
>>> Hello
>>>
>>> I think you're right about the linebreak, Jan. But that would mean that
>>> *Horde* doesn't count it, because the higher number (153 bytes) comes
>>> from the *phone*. That's because the data already gets trimmed: In
>>> Command/Sync.php on line 225.
>>
>> Gotcha! I got the numbers wrong, so this seems to be a bug in Horde.
>>
>>> Now that we have this explanation for the size mismatch, it wouldn't be
>>> too elegant to just accept "wrong" size specifications as in Arvid's
>>> patch. Maybe we should store the 'trimmed' and the 'untrimmed'
>>> length of
>>> the data and accept both of them? Because removing the trim() commands
>>> might break other clients.
>>
>> Well, if it does, then *those* clients are broken, and we have to
>> find a workaround for it. I guess it works for most clients, because
>> they don't include a trailing CRLF.
>
> Try this:
> http://cvs.horde.org/diff.php/framework/SyncML/SyncML/Command/Sync.php?rt=horde&r1=1.17.10.18&r2=1.17.10.19&ty=u 
>
>
> Jan.
>

Hi again
I've applied your patch and the length is recognized correctly now. (Not
a single warning/error in the log.)


Best regards,
Martin

--
sync mailing list - Join the hunt: http://horde.org/bounties/#sync
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: sync-unsubscribe@...