I cannot reproduce it anymore. Cool! I'll reopen the ticket if I see 
it again, but now I have to get some sleep :)

Huh - I never saw this.  Try this change.

Changes have been made in Git for this ticket:

Bug #9796: Make sure messages is always defined

  1 files changed, 1 insertions(+), 3 deletions(-)
http://git.horde.org/horde-git/-/commit/c2a2ec543eeb5514c4883682a563d91c6f267668

But there's also been a bunch of changes in IMP since RC2, so 
installing a new version if Imap_Client doesn't really tell me anything.

I can verify that I was able to reproduce your issue before this fix, 
and I can no longer reproduce after this fix.

I've spotted these new messages in the logs:

2011-04-06T00:07:29+03:00 WARN: HORDE [imp] PHP ERROR: 
array_combine(): Both parameters should have an equal number of 
elements [pid 13172 on line 2953 of 
"/usr/share/pear/Horde/Imap/Client/Base.php"]
2011-04-06T00:07:29+03:00 NOTICE: HORDE [imp] PHP ERROR: Undefined 
index: messages [pid 13172 on line 2623 of 
"/usr/share/pear/Horde/Imap/Client/Base.php"]

I've pulled a whole Imap_Client package and reinstalled it. Still no 
luck. The strange thing is that this problem tend to appear on larger 
mailboxes when deletion is slower.

I have no idea if this would work properly by patching on RC2.  But 
you most definitely need to purge your cache.

Does this suppose to work on RC2? I just applied the patch on stock 
RC2, deleted the cache and now the issue is a little bit different. I 
still get ghost messages but instead of "Unknown date"/"No subject" I 
get old real subject/date/from from deleted message. It is marked as 
unread. If I logout/login it disappears.

Changes have been made in Git for this ticket:

Bug #9796: CONDSTORE fixes when MODSEQ is not available in mailbox
RFC 4551 [3.1] - CONDSTORE server MUST return HIGHESTMODSEQ info.
If not, assume server is broken and ignore.

Don't need to delete cache if MODSEQ is not available - we just won't be
able to cache flag results.

Correctly handle cache data if MODSEQ isn't available.  Namely - avoid
all flag caching when MODSEQ is not available in a mailbox.

  3 files changed, 33 insertions(+), 47 deletions(-)
http://git.horde.org/horde-git/-/commit/ce223be3fd4550b2dd60c1be88d6db404b7f8e29

Yup - it was a no MODSEQ issue in CONDSTORE enabled servers.  Should be fixed.

Has the side benefit of allowing caching on everything else in the 
mailbox but flags (for whatever reason, we were deleting the cached 
results on every page access if MODSEQs weren't available.  This isn't 
correct.  UIDs aren't changing - that's the point of UIDVALIDITY - so 
this data is all still valid.  It's just the flag data that is 
affected by the absence of MODSEQs).

At least on Cyrus this is the default behaviour. CONDSTORE is enabled 
globally, but to actually work user (or admin) must enable it on the 
mailboxes he wants. Don't ask why :)

There's a good chance your issue might be that your server indicates 
in multiple places it supports CONDSTORE, and then when you select a 
mailbox you get:

(1301911804,0642) S: * OK [NOMODSEQ] Sorry, modsequences have not been 
enabled on this mailbox

Well, I have uploaded IMAP logs. If there is anything more that I 
could do, I would gladly help.

No.  Especially since I can't reproduce.

Any chance this gets fixed before the release? This is really a 
showstopper for me.

Here you go. The actions I've performed.

1. Login to Horde/IMP.
2. Go to INBOX (INBOX page has 1 newest messages which is read, 3 
messages marked as deleted from another client, 16 read older 
messages. Everything is ordered by Date, Descending).
3. Mark checkbox and delete first message.
4. Mark checkboxes and delete 3 messages which were marked as deleted.
5. Three ghost messages appear.

To further debug this issue, we need details of the IMP -> IMAP/POP 
communication.

To enable debugging, see instructions contained in 
imp/config/backends.php (the 'debug' config parameter).

Debugging should not be enabled on a production server,   Attach/post 
only the portion of the log that directly deals with the problem 
reported (it may be simplest to clear the log file and then perform 
the event that causes the error).

Sometimes when deleting messages from INBOX I get this ghost message 
(see screenshot). The count of ghost messages are equal to count of 
deleted messages.

I'm using IMAP Trash instead of ordinary delete/purge settings.