[horde] AS email not current
Simon Wilson
simon at simonandkate.net
Tue Apr 23 03:31:20 UTC 2013
>>>>>>>>>>>>>>>>>>>>>>>> But if I delete emails in Imp, the deleted messages
>>>>>>>>>>>>>>>>>>>>>>>> are not
>>>>>>>>>>>>>>>>>>>>>>>> sync'ed, and those emails continue to show in the
>>>>>>>>>>>>>>>>>>>>>>>> iOS devices
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> http://wiki.horde.org/ActiveSync
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> "Deleting from a MUA: If the MUA is not configured
>>>>>>>>>>>>>>>>>>>>>>> to move
>>>>>>>>>>>>>>>>>>>>>>> messages to the trash, and instead just flags them as
>>>>>>>>>>>>>>>>>>>>>>> deleted, these message deletions will NOT be synched
>>>>>>>>>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>>>>>>>>>> ActiveSync client, as there is no equivalent command
>>>>>>>>>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>>>>>>>>>> protocol. These messages will only be removed from
>> the
>>>>>>>>>>>>>>>>>>>>>>> ActiveSync client once expunged from the mailbox.
>>>>>>>>>>>>>>>>>>>>>>> This is in
>>>>>>>>>>>>>>>>>>>>>>> accordance with the ActiveSync protocol specs.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> *If you wish to ensure all message deletions are
>>>>>>>>>>>>>>>>>>>>>>> synched
>>>>>>>>>>>>>>>>>>>>>>> quickly to the device, you should configure the use
>>>>>>>>>>>>>>>>>>>>>>> of a
>>>>>>>>>>>>>>>>>>>>>>> Trash folder.*"
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> Horde mailing list
>>>>>>>>>>>>>>>>>>>>>>> Frequently Asked Questions: http://horde.org/faq/
>>>>>>>>>>>>>>>>>>>>>>> To unsubscribe, mail:
>>>>>>>>>>>>>>>>>>>>>>> horde-unsubscribe at lists.horde.org
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> As per my other reply, Imp is configured to move to
>>>>>>>>>>>>>>>>>>>>>> trash
>>>>>>>>>>>>>>>>>>>>>> folder, and purge from Inbox.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It does not just flag as deleted.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Simon
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> OK - did an experiment... deleting an email on the
>>>>>>>>>>>>>>>>>>>>> same iOS
>>>>>>>>>>>>>>>>>>>>> device in Apple Mail (via a direct IMAP connection),
>>>>>>>>>>>>>>>>>>>>> and the
>>>>>>>>>>>>>>>>>>>>> resultant sync back to the AS email connection removes
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> deleted email correctly.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Delete an email in Imp and it does not.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> My Imp's mail deletion prefs are set as per following
>>>>>>>>>>>>>>>>>>>>> screen shot:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> http://www.simonandkate.net/impprefs.png
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> So what is happening in Imp that it is not flagging
>>>>>>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>>>>>> deletions back through AS?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Not sure. Those settings are correct.
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> mike
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> :( troubleshooting suggestions?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If I empty the AS log, delete an email in Imp, and post
>>>>>>>>>>>>>>>>>>> the sync
>>>>>>>>>>>>>>>>>>> log will that help?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I doubt it, though I'll look at it if you send it me. The
>>>>>>>>>>>>>>>>>> device
>>>>>>>>>>>>>>>>>> is not being told to remove the email, so it won't be in
>>>>>>>>>>>>>>>>>> the log.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> What about Imap log for the delete transaction?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Not really. The email is obviously being removed from
>>>>>>>>>>>>>>>>>> your INBOX
>>>>>>>>>>>>>>>>>> since you no longer see it in IMP (or other MUA).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> What is the process that a delete triggers?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This happens in one of two ways depending on the features
>>>>>>>>>>>>>>>>>> of your
>>>>>>>>>>>>>>>>>> IMAP server. If you don't support CONDSTORE or
>>>>>>>>>>>>>>>>>> per-mailbox MODSEQ
>>>>>>>>>>>>>>>>>> values (which, if I remember right from looking at your
>>>>>>>>>>>>>>>>>> log, is
>>>>>>>>>>>>>>>>>> your case) - we basically compare the UID list that we
>> have
>>>>>>>>>>>>>>>>>> cached in the ActiveSync state with what the IMAP server
>>>>>>>>>>>>>>>>>> returns
>>>>>>>>>>>>>>>>>> as being present in the mailbox. Anything not listed in
>>>>>>>>>>>>>>>>>> the IMAP
>>>>>>>>>>>>>>>>>> server's list of UIDs, but present in the ActiveSync list
>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>> removed from the device.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Does AS care WHERE the email is deleted to? I have Cyrus
>>>>>>>>>>>>>>>>>>> IMAP
>>>>>>>>>>>>>>>>>>> with a "Deleted Items" folder that Imp calls Trash,
>>>>>>>>>>>>>>>>>>> seems to
>>>>>>>>>>>>>>>>>>> function fine. Should I be using virtual trash in Imp?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It doesn't matter. From the point of view of ActiveSync,
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> message is just vanished from the INBOX (or whatever
>>>>>>>>>>>>>>>>>> folder we
>>>>>>>>>>>>>>>>>> are talking about). Adding it to the Deleted
>>>>>>>>>>>>>>>>>> Items/Trash/Whatever
>>>>>>>>>>>>>>>>>> folder is a separate operation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> mike
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks Mike. You know how much I hate it when things start
>>>>>>>>>>>>>>>>> working
>>>>>>>>>>>>>>>>> by themselves with no change????? Lots.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I tried today in Outlook with an IMAP connection to my
>>>>>>>>>>>>>>>>> mailbox.
>>>>>>>>>>>>>>>>> Deleted some emails. When my iOS devices next connected,
>> the
>>>>>>>>>>>>>>>>> mailbox changes (deletions) were correctly sent through.
>>>>>>>>>>>>>>>>> So that
>>>>>>>>>>>>>>>>> is with both Apple Mail and MS Outlook 2010 that deletions
>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>> other MUAs are correctly sync'ed through AS.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Then tried in Imp again. And it updated. :-O
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Man I hate that.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I haven't changed ANYTHING.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Anyway, apologies for the noise, I'll monitor and see if
>>>>>>>>>>>>>>>>> it reoccurs.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Simon.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I spoke too soon. It was updating automatically for a
>>>>>>>>>>>>>>>> while, then
>>>>>>>>>>>>>>>> stopped again.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> At this stage I have one email that ActiveSync thinks is
>>>>>>>>>>>>>>>> there but
>>>>>>>>>>>>>>>> that isn't.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I have confirmed that the email does NOT exist in the Cyrus
>>>>>>>>>>>>>>>> partition, so the IMAP delete has successfully completed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Is there any way to see what UIDs ActiveSync has cached,
>>>>>>>>>>>>>>>> and what
>>>>>>>>>>>>>>>> it is getting from IMAP to compare?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I then deleted a second email from Imp, and it also hung
>>>>>>>>>>>>>>>> up...
>>>>>>>>>>>>>>>> deleted OK on the Cyrus partition, but AS still thinks it's
>>>>>>>>>>>>>>>> there.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Third email deleted then from Outlook - and it also hung
>>>>>>>>>>>>>>>> up... as
>>>>>>>>>>>>>>>> per last one, gone in Cyrus, AS still thinks it's there.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sounding to me like AS caching something incorrectly
>>>>>>>>>>>>>>>> reading the
>>>>>>>>>>>>>>>> Cyrus list. Could it be related to bug 11115?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Simon
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have the following set in backends.local.php. Cache was
>>>>>>>>>>>>>>> set to
>>>>>>>>>>>>>>> true, but setting to false hasn't changed anything. :
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <?php
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> $servers['imap'] = array(
>>>>>>>>>>>>>>> 'disabled' => false,
>>>>>>>>>>>>>>> 'name' => 'Cyrus IMAP Server',
>>>>>>>>>>>>>>> 'hostspec' => 'server04.simonandkate.lan',
>>>>>>>>>>>>>>> 'hordeauth' => true,
>>>>>>>>>>>>>>> 'protocol' => 'imap',
>>>>>>>>>>>>>>> 'secure' => 'tls',
>>>>>>>>>>>>>>> 'port' => 143,
>>>>>>>>>>>>>>> 'quota' => array(
>>>>>>>>>>>>>>> 'driver' => 'imap',
>>>>>>>>>>>>>>> 'params' => array(
>>>>>>>>>>>>>>> 'hide_quota_when_unlimited' => true,
>>>>>>>>>>>>>>> 'unit' => 'MB'
>>>>>>>>>>>>>>> )
>>>>>>>>>>>>>>> ),
>>>>>>>>>>>>>>> 'maildomain' => 'simonandkate.net',
>>>>>>>>>>>>>>> 'acl' => true,
>>>>>>>>>>>>>>> 'cache' => false,
>>>>>>>>>>>>>>> // 'debug' => ($GLOBALS['registry']->getAuth() ==
>>>>>>>>>>>>>>> 'simon') ?
>>>>>>>>>>>>>>> '/var/log/hordeas/impdebug' : false,
>>>>>>>>>>>>>>> 'debug' => '/var/log/hordeas/impdebug',
>>>>>>>>>>>>>>> 'debug_raw' => false,
>>>>>>>>>>>>>>> );
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Setting Impdebug gives some info...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Initial connection:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Snip
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Doing an update on the iPhone's AS Inbox generates this IMAP
>>>>>>>>>>>>>>> debug log:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://www.simonandkate.net/imaplog.txt
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That UID list returned from Cyrus is correct - 46072 is the
>>>>>>>>>>>>>>> last
>>>>>>>>>>>>>>> (newest) email that is actually in the mailbox. It appears
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> Cyrus is sending the correct info. Imp shows this correctly.
>>>>>>>>>>>>>>> Yet AS
>>>>>>>>>>>>>>> into iOS is not showing this, with four emails showing that
>>>>>>>>>>>>>>> are newer.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The AS log for this is as follows:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://www.simonandkate.net/asimap.txt
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That also shows the correct UID sequence. Yet iPhone
>>>>>>>>>>>>>>> continues to
>>>>>>>>>>>>>>> show the old list of emails - not being told to update?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Actually, this log was very helpful. It doesn't contain *any*
>>>>>>>>>>>>>> UID
>>>>>>>>>>>>>> Sequences at all. I'm not talking about just the UIDNEXT
>>>>>>>>>>>>>> value, but
>>>>>>>>>>>>>> the entire sequence of message UIDs that ActiveSync thinks is
>>>>>>>>>>>>>> on the
>>>>>>>>>>>>>> device. This should be visible in the 'm' parameter of the
>>>>>>>>>>>>>> state that
>>>>>>>>>>>>>> is saved (and would basically look like a large array of
>>>>>>>>>>>>>> integers).
>>>>>>>>>>>>>> Yours is showing an empty array. This would definitely cause
>>>>>>>>>>>>>> deleted
>>>>>>>>>>>>>> emails from not being detected since we perform an array_diff
>>>>>>>>>>>>>> on the
>>>>>>>>>>>>>> list we have and the list the IMAP server has. The question
>>>>>>>>>>>>>> is, *why*
>>>>>>>>>>>>>> you don't have a valid list of UIDs. Something must be wiping
>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>> code somewhere, I'll have to dig further on that during my
>>>>>>>>>>>>>> next coding
>>>>>>>>>>>>>> sprint later this week.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yay!! I was starting to get a bit disheartened, but that's
>>>>>>>>>>>>> great news that the log gives you something useful.
>>>>>>>>>>>>
>>>>>>>>>>>> I've spent about an hour trying to reproduce this and can't.
>>>>>>>>>>>> I've disabled features on my IMAP server to emulate not having
>>>>>>>>>>>> per-mailbox MODSEQ values like your IMAP server, tried IMAP
>>>>>>>>>>>> caching on/off, performed dozens of mailbox operations from
>>>>>>>>>>>> various MUAs and activesync clients. I'm not able to lose
>>>>>>>>>>>> ActiveSync's internal message cache nor am I able to see any
>>>>>>>>>>>> code path where the message state would be reset.
>>>>>>>>>>>>
>>>>>>>>>>>> You are going to need to start from a fresh account,
>>>>>>>>>>>> synchronize it, and find the point where your log goes from
>>>>>>>>>>>> having the proper state to an empty state.
>>>>>>>>>>>>
>>>>>>>>>>>> 2013-03-05T20:39:14-05:00 DEBUG: [8689] Saving state: Array
>>>>>>>>>>>> (
>>>>>>>>>>>> [0] => {51369e16-4154-423a-bcf7-21f2c0a8015f}25
>>>>>>>>>>>> [1] => Horde_Db_Value_Binary Object
>>>>>>>>>>>> (
>>>>>>>>>>>> [_value:protected] =>
>> C:28:"Horde_ActiveSync_Folder_Imap":1184:{a:5:{s:1:"s";a:3:{s:7:"uidnext";s:6:"168028";s:11:"uidvalidity";s:10:"1292457115";s:13:"highestmodseq";i:0;}s:1:"m";a:21:{i:167587;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:167604;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:167612;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:167638;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:167642;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:167643;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:167648;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:167665;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:167666;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:167672;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:167679;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:167712;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:167721;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:167753;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:167758;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:168018;a:2:{s:4:"read";i:0;s:7:"flagged";i:0;}i:168019;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}
>>>
>>> i
>>>> :
>>>>> 1
>>>>>> 6
>>>>>>> 8
>>>>>>>>> 2
>>>>>>>>>> 4;a
>>>>>>>>>>>> :2:{s:4:
>> "read";i:1;s:7:"flagged";i:0;}i:168025;a:2:{s:4:"read";i:0;s:7:"flagged";i:0;}i:168026;a:2:{s:4:"read";i:0;s:7:"flagged";i:0;}i:168027;a:2:{s:4:"read";i:0;s:7:"flagged";i:0;}}s:1:"f";s:5:"INBOX";s:1:"c";s:5:"Email";s:1:"v";i:1;}}
>>>>>>>>>>>> )
>>>>>>>>>>>>
>>>>>>>>>>>> [2] => ApplGB024LGPZ3A
>>>>>>>>>>>> [3] => 1362533954
>>>>>>>>>>>> [4] => INBOX
>>>>>>>>>>>> [5] => mike
>>>>>>>>>>>> [6] => 0
>>>>>>>>>>>> )
>>>>>>>>>>>> Note the entries after the "m" value. This is the message state
>>>>>>>>>>>> for this folder. Now, YOUR log looks like this:
>>>>>>>>>>>>
>>>>>>>>>>>> 2013-03-04T11:30:07+00:00 DEBUG: [14497] Saving state: Array
>>>>>>>>>>>> (
>>>>>>>>>>>> [0] => {51347830-a744-4382-b47a-214dc0a801e6}110
>>>>>>>>>>>> [1] => Horde_Db_Value_Binary Object
>>>>>>>>>>>> (
>>>>>>>>>>>> [_value:protected] =>
>> C:28:"Horde_ActiveSync_Folder_Imap":174:{a:5:{s:1:"s";a:3:{s:13:"highestmodseq";i:0;s:7:"uidnext";s:5:"46217";s:11:"uidvalidity";s:10:"1238677126";}s:1:"m";a:0:{}s:1:"f";s:5:"INBOX";s:1:"c";s:5:"Email";s:1:"v";i:1;}}
>>>>>>>>>>>> )
>>>>>>>>>>>>
>>>>>>>>>>>> [2] => Appl79030T3BA4S
>>>>>>>>>>>> [3] => 1362396607
>>>>>>>>>>>> [4] => INBOX
>>>>>>>>>>>> [5] => simon
>>>>>>>>>>>> [6] => 0
>>>>>>>>>>>> )
>>>>>>>>>>>>
>>>>>>>>>>>> Note the "m";a:0: value. This means your internal message state
>>>>>>>>>>>> is empty. I.e., the ActiveSync state cache thinks the INBOX on
>>>>>>>>>>>> your device is empty - so we have no context to pass to
>>>>>>>>>>>> Horde_Imap_Client when asking for the list of vanished
>>>>>>>>>>>> messages. (This will always return an empty list).
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> mike
>>>>>>>>>>>>
>>>>>>>>>>>> The Horde Project (www.horde.org[1])
>>>>>>>>>>>> mrubinsk at horde.org
>>>>>>>>>>>
>>>>>>>>>>> Ok. I'll remove the device from AS in horde, remove its log
>>>>>>>>>>> file, and connect as my test account, that only has about 3
>>>>>>>>>>> emails in it and 2 appts. Will the horde inline debug function
>>>>>>>>>>> that can be thrown into the php help me anywhere?
>>>>>>>>>>
>>>>>>>>>> Possibly, though since I have no idea where this is being
>>>>>>>>>> cleared, I don't know where to tell you to put it yet.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Finally got some time to test this some more.
>>>>>>>>>
>>>>>>>>> I took my iPad, deleted the account on it, restarted it. Removed
>>>>>>>>> the Horde AS device log file, and removed from the AS device list
>>>>>>>>> in Horde.
>>>>>>>>>
>>>>>>>>> Added as my test account on the iPad, and added ONLY mail.
>>>>>>>>> Interestingly, the autodiscover redirect failed to strip the
>>>>>>>>> @domain name, and I had to manually configure.
>>>>>>>>>
>>>>>>>>> Immediately sync'ed up, and iPad showed no emails (3 in the
>>>>>>>>> account but too old, so were filtered out).
>>>>>>>>>
>>>>>>>>> Sent an email to the account, and it appeared fine on the iPad.
>>>>>>>>> Read it in Imp, and the flag change worked and synced to iPad.
>>>>>>>>>
>>>>>>>>> Deleted it in Imp, and it disappeared in iPad. The log shows
>>>>>>>>> "m";a:1.
>>>>>>>
>>>>>>> And this is *still* wrong. That is actually not even a valid
>>>>>>> serialized value.
>>>>>>>
>>>>>>> According to your earlier logs, your IMAP server does not support
>>>>>>> per-mailbox MODSEQ values. In this case, the messages array (which
>>>>>>> is what "m" represents) contains both the message uids AND the flag
>>>>>>> data (see my example posted earlier in the thread above). Unless
>>>>>>> *this* account, for some reason, has MODSEQ support enabled, this
>>>>>>> makes absolutely no sense to me whatsoever.
>>>>>>>
>>>>>>> --
>>>>>>> mike
>>>>>>
>>>>>> The whole line from when using my test account is in the link I
>> posted:
>>>>>>
>>>>>> [_value:protected] =>
>> C:28:"Horde_ActiveSync_Folder_Imap":215:{a:5:{s:1:"s";a:3:{s:13:"highestmodseq";i:0;s:7:"uidnext";s:2:"19";s:11:"uidvalidity";s:10:"1238677130";}s:1:"m";a:1:{i:18;a:2:{s:4:"read";i:0;s:7:"flagged";i:0;}}s:1:"f";s:5:"INBOX";s:1:"c";s:5:"Email";s:1:"v";i:1;}}
>>>>>>
>>>>>> Simon.
>>>>>
>>>>> Hmmm, I just checked my iPhone, and an email that I had deleted
>>>>> earlier in Imp disappeared when it refreshed.
>>>>>
>>>>> The relevant entry in the AS Device log included this:
>>>>>
>>>>> 2013-04-13T08:31:00+00:00 DEBUG: [26909] Saving state: Array
>>>>> (
>>>>> [0] => {516496a4-8660-4650-a643-673dc0a801e6}207
>>>>> [1] => Horde_Db_Value_Binary Object
>>>>> (
>>>>> [_value:protected] =>
>> C:28:"Horde_ActiveSync_Folder_Imap":1162:{a:5:{s:1:"s";a:3:{s:13:"highestmodseq";i:0;s:7:"uidnext";s:5:"47532";s:11:"uidvalidity";s:10:"1238677126";}s:1:"m";a:21:{i:47408;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47410;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47417;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47419;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47423;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47424;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47428;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47435;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47436;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47440;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47442;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47464;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47465;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47466;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47467;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47468;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47481;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47489;a:2:{s:4:"read";i
>>>
>>> :
>>>> 1;
>>>>> s:7:"fla
>> gged";i:0;}i:47499;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47508;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47521;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}}s:1:"f";s:5:"INBOX";s:1:"c";s:5:"Email";s:1:"v";i:1;}}
>>>>> )
>>>>>
>>>>> [2] => APPL79030T3BA4S
>>>>> [3] => 1365841859
>>>>> [4] => INBOX
>>>>> [5] => simon
>>>>> [6] => 0
>>>>> )
>>>>>
>>>>> 2013-04-13T08:31:00+00:00 DEBUG: [26909] O <Folder/>
>>>>>
>>>>> THAT is working OK for a while.
>>>>>
>>>>> iPad with the same deleted email is not showing it - still 0 and an
>>>>> empty array.
>>>>>
>>>>> :-/
>>>>>
>>>>> I'm lost.
>>>>>
>>>>> Simon
>>>>
>>>> It's all fallen over again...
>>>>
>>>> As connecting a 'clean' device with a nearly empty account and the logs
>>>> hasn't helped with troubleshooting I'm running up a CentOS 6 server
>>>> with newer Cyrus to see if that makes any difference, but that's going
>>>> to take a while... that's Cyrus 2.3.16 instead of 2.3.7. There have to
>>>> be people out there with this working on Cyrus?
>>>
>>> Regardless of the cause of your current issue, to get the best
>>> performance from ActiveSync you will want an IMAP server that supports
>>> CONDSTORE and per-mailbox MODSEQ values. IIRC, Cyrus supports both, but
>>> disables per-mailbox MODSEQ by default. It might not help your case
>>> though, since you seem to have some issue with storing the message UIDs
>>> that are stored on the device.
>>> --
>>> mike
>> I just noticed this in the Horde log:
>>
>> 2013-04-21T07:28:40+00:00 ERR: HORDE [horde] SQL QUERY FAILED: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '{516921a8-a2f8-4288-9f9e-6921c0a801e6}573' for key 'PRIMARY'
>> INSERT INTO horde_activesync_state (sync_key, sync_data, sync_devid,
>> sync_time, sync_folderid, sync_user, sync_pending) VALUES
>> ('{516921a8-a2f8-4288-9f9e-6921c0a801e6}573',
>> 'C:28:"Horde_ActiveSync_Folder_Imap":1350:{a:5:{s:1:"s";a:3:{s:13:"hig
>> hestmodseq";i:0;s:7:"uidnext";s:5:"47780";s:11:"uidvalidity";s:10:"123
>> 8677126";}s:1:"m";a:25:{i:47546;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;
>> }i:47559;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47563;a:2:{s:4:"read
>> ";i:1;s:7:"flagged";i:0;}i:47612;a:2:{s:4:"read";i:1;s:7:"flagged";i:0
>> ;}i:47626;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47643;a:2:{s:4:"rea
>> d";i:1;s:7:"flagged";i:0;}i:47652;a:2:{s:4:"read";i:1;s:7:"flagged";i:
>> 0;}i:47673;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47677;a:2:{s:4:"re
>> ad";i:1;s:7:"flagged";i:0;}i:47690;a:2:{s:4:"read";i:1;s:7:"flagged";i
>> :0;}i:47718;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47719;a:2:{s:4:"r
>> ead";i:1;s:7:"flagged";i:0;}i:47722;a:2:{s:4:"read";i:1;s:7:"flagged";
>> i:0;}i:47727;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47734;a:2:{s:4:"
>> read";i:1;s:7:"flagged";i:0;}i:47743;a:2:{s:4:"read";i:1;s:7:"flagged"
>> ;i:0;}i:47751;a:2:{s:4:"read";i:0;s:7:"flagged";i:0;}i:47752;a:2:{s:4:
>> "read";i:1;s:7:"flagged";i:0;}i:47755;a:2:{s:4:"read";i:0;s:7:"flagged
>> ";i:0;}i:47756;a:2:{s:4:"read";i:1;s:7:"flagged";i:0;}i:47757;a:2:{s:4
>> :"read";i:1;s:7:"flagged";i:0;}i:47774;a:2:{s:4:"read";i:1;s:7:"flagge
>> d";i:0;}i:47775;a:2:{s:4:"read";i:0;s:7:"flagged";i:0;}i:47776;a:2:{s:
>> 4:"read";i:0;s:7:"flagged";i:0;}i:47779;a:2:{s:4:"read";i:0;s:7:"flagg
>> ed";i:0;}}s:1:"f";s:5:"INBOX";s:1:"c";s:5:"Email";s:1:"v";i:1;}}',
>> 'APPL79030T3BA4S', '1366529313', 'INBOX', 'simon', 'a:0:{}') [pid 6759 on line 815 of "/usr/share/pear/Horde/Db/Adapter/Base.php"]
>>
>> Relevant? I notice that it seems to have the full array variables...
>
> The latest package fixed the issue that was causing the empty 'm' element for certain mail servers. You can try to recreate the account and see if that fixes things now.
>
>
> --
> mike
>
Mike
Sounds promising... :)
Can you tell me please which package - AS? Which version do I need to be at? Which mail servers does it affect?
And would love to get a brief explanation of what the issue / fix was - this has been driving me nuts for a while now... :)
Thanks
Simon.
More information about the horde
mailing list