Almost positive this was the culprit:

http://lists.horde.org/archives/cvs/Week-of-Mon-20060522/058202.html



Closing ticket.

Seems also to work now here

I haven's seen this happening anymore during the last few days.

OK - think I finally figured this out.  Try latest HEAD.

Then I am going to need you to trace the code in IMP_Message::delete() 
and/or IMP_Message::expunge() to figure out why the messages aren't 
being removed.  Because evidently I am never going to be able to 
reproduce this locally.

Didn't fix my problem either.

I'm afraid no...

Deleted messages still do not always get moved to the trash folder and 
suddenly reappear in the mailboxlist marked as deleted.

Yes I'm running PHP4

Whoops - also need this patch:

http://lists.horde.org/archives/cvs/Week-of-Mon-20060522/058156.html

Did this, by chance, help:

http://lists.horde.org/archives/cvs/Week-of-Mon-20060522/058151.html

Are you using PHP 4?  Seeing as how I believe Jan uses PHP 4 and has 
seen this, and I use PHP 5 and have never seen this (I can't reproduce 
this given either of your scenarios) - this may be an issue with 
references somewhere.  In fact I'm hoping this is the issue or else 
I'm stumped.

I have just seen this again. I saw new messages in the virtual inbox 
from the real inbox, deleted some of them, went to the inbox and 
didn't see any new messages. The status was correct though.

When I tried to track this down, another message arrived to inbox and 
all unread messages appeared.

Here is a reproduceable scenario:



This is with "use Trash folder" on.

Open a mailbox -> delete some messages -> open a message -> report it as SPAM

Now the message gets reported as SPAM and deleted, the mailbox list 
now shows the previously deleted messages again, but marked as 
deleted. They should no show up, because the should have been moved to 
the trash folder before.

Now they are in the trash folder and in the mailbox.

Never mind.  $_arrival doesn't exist in that file anymore - that's why 
the error was being thrown.  Duh, me.

It doesn't complain about unsetting the array key, the whole array, 
the property doesn't even exist at that point.

Does it make sense at all that the search (virtual inbox) returns 
something different than the regular mailbox view? If so, I can try to 
track down where IMP is fetching the (incomplete) mailbox list from if 
I see it the next time.

That sounds very unlikely, especially since I use PHP 4.

100% agreed.  But my issue is I have not been able to reproduce an 
incorrect cache update once in the last 2 weeks, with mailbox caching 
both on and off.  So I haven't ignored this ticket - I just don't even 
know where to begin.

Fixed.  Seems that unset(), as of PHP 5, now throws undefined errors 
if you try to unset an array key that doesn't exist.

I'm still seeing this sometimes on some accounts.

When deleting a folder:

Notice: Undefined property: _arrival in 
/home/jan/headhorde/imp/lib/IMAP/MailboxCache.php on line 571

And more important: it shouldn't matter if Idisable the cache.

No.

Jan - do you have concurrent clients accessing your IMAP system?

I have the mailbox cache *disabled* and usual the virtual inbox 
opened. Arriving message are displayed fine in the vinbox view. But 
sometimes, if go to a folder with some new messages, the messages are 
not displayed. The new mail count in the header is correct, but I see 
an old mailbox view. Also, sometimes the (thread) sorting is broken. 
Both can only be fixed by logging out and in again.

I think my fixes last night cleared this last set of issues up.

After CVS update an hour ago, this one went away.



In next couple of days I will see how things are going here and let 
you know if I'll find something.

Emptying mailboxes still doesn't work for me, cache disabled.

I must note, that 95% of my users does not use any other mail client. 
They are using IMP only. But they see some issues too. The most 
annoying reproducable here like 9 times from 10 is this:



1. User logins to his account. He has 1 new message.

2. He checks the checkbox in message list and clicks Delete in navbar.

3. The message is marked as deleted.

4. User clicks on Purge Deleted and _all_ messages in INBOX are gone.

5. He clicks on Mail entry in sidebar, and all messages are back 
except for deleted message.



I can give you a test account on my webmail if you want.

Looking through here, there doesn't appear to be anything left open.   
This ticket may be reopened if new issues arise with the current 
mailbox list caching code.  Resolving for now.

This has nothing to do with mailbox list caching - this has to do with 
message caching.  This is a known limitation of our current caching 
system - it was designed so that IMP was the only MUA to access the 
mailbox.  If you can't handle that IMP may not always catch a 
non-destructive flag on a message done by a foreign MUA, then you 
should disable message caching in conf.php.

Unfortunately, looking at the code, adding these debug statements 
won't get us very far since we will still throw a fatal error in 
mailbox.php or message.php if the data doesn't exists and there is 
really no way around this outside of "making-up" data to pass back.   
But I personally haven't seen any of these errors for several days now 
so I think Phase 1 of the caching code is pretty close.

Since a cvs update this morning the deleting of messages which were 
opened from within the "Virtual Inbox" seems to work again. I do not 
see the "Fatal Error" logs.

I think it'd be great to log these at a DEBUG level for now - once 
it's not happening anymore, we can either remove the logMessage calls, 
or leave them to make sure they don't recur. :)

These errors aren't really helpful.  They occur anytime we incorrectly 
update the current mailbox list - and this could be for a variety of 
reasons.  That's why Bug 3889 is marked as a duplicate.



I think I will try to add some error catching code in MailboxCache to 
prevent these ugly PHP errors.  However, once we get the mailbox 
caching sorted out, we should never hit these error messages ever.

When deleting a message which was opened from the "Virtual Inbox" 
mailboxlist I get the following errors:



[Sat May  6 21:27:52 2006] [error] PHP Notice:  Undefined property:   
seen in /usr/local/apache/htdocs/cvs_dev/horde/imp/message.php on line 
206

[Sat May  6 21:27:52 2006] [error] PHP Notice:  Undefined property:   
seen in /usr/local/apache/htdocs/cvs_dev/horde/imp/message.php on line 
214

[Sat May  6 21:27:52 2006] [error] PHP Fatal error:  Call to undefined 
function:  setstriplink() in 
/usr/local/apache/htdocs/cvs_dev/horde/imp/message.php on line 223



When deleting it directly from the "Virtual Inbox" mailboxlist without 
opening it first everything is fine.

I already reported this in bug #3889 which was marked as duplicate of 
this bug report. But I forgot to mention the two "Undefined property" 
errors above the "Fatal error"

This issue has been fixed.

OK - the important part about this issue is that you are having 
concurrent accesses to the IMAP server other than IMP.  Very 
important, and the reason I am not seeing this issue.  Now that I know 
where to look, this should be easier to track down.

I spent debugging my IMAP server all morning trough telnet and it 
seems that my other IMAP client deleted messages and after that 
automatically expunged. So everything that is seen in IMP as marked as 
deleted is just not updated mailbox cache. This needs to be fixed.



More on this later.

Also after update from CVS couple of hours ago, I see some new errors:



PHP Warning:  array_diff(): Argument #1 is not an array in 
/var/www/html/horde/imp/lib/Message.php on line 669



It seems that imap_search not always succeed and returns false.

Ok this one is reproducable 100% here:



1. Login to your account from other client and mark some messages as 
deleted. Logout.

2. Login to IMP. You can see deleted messages. If you try to hit 
expunge they are not deleted at all. (I think this is because of these 
messages are not stored in Horde cache, and expungeMailbox() somehow 
deletes only those messages that are on server AND in cache.).



3. Check couple of those marked as deleted messages and mark them as 
deleted from IMP.



4. Click Expunge and only marked messages are deleted.

fogot to mention: this was with using trash folder and caching on

I can also run into the described problems:



e.g.

I had one folder with 5 messages in total. All of them were unseen. I 
was deleting the first 4 from within the mailboxlist without opening 
them first. Then I was opening the remaining message and deleting it 
from the message view. After a logout and a relogin I opened the 
folder and the first 4 messages reappared but now marked as deleted 
(They should have gone into the trash folder)

I should also note I have tested this with mailbox caching on/off, 
hide deleted on/off, and trash folder on/off, and in normal and search 
mailboxes.

I see none of this behavior.  I will need your help tracing through 
IMP_Message:: to figure out why expungeMailbox() is not being called 
correctly.



Bumping down as I can't reproduce this at all.

One more strange issue.



When there is only one message in a folder and you try to delete it 
from folder list screen, sometimes message is not deleted from server 
only from the cache. After relogin you can see the message.

Errors are gone, but I see other strange things.



I'm using Trash folder and for example if I detele messages from Spam 
folder in bunched of 20 from mailbox screen. They are deleted from a 
cache. But after logging out and logging in back I can still see them 
in spam folder marked as deleted, and no messages are moved to Trash.



Also, when you are in INBOX folder and new mail arrives, new message 
count near folder name in header increases, but you can't see them in 
the list. After relogin messages shows up.

Are you still seeing this after today's commits?

Some more errors after related delete actions:



PHP Fatal error:  Call to undefined function:  findbody() in 
/var/www/html/horde/imp/lib/IMAP/MailboxCache.php on line 585

I'm almost positive the issue is as follows (I've known about this for 
a week, but haven't gotten aroudn to it yet):

In IMP_Message, when performing actions on message(s) everywhere but 
the message screen, we are passing IMP_Mailbox::updateMailbox() an 
array of indices.  updateMailbox() was originally designed to only 
update the mailbox when given a single index.  I've hackishly "fixed" 
updateMailbox() to silence errors in the former case, but it isn't 
updating the mailbox status correctly.  This needs to be fixed.

YES: Return to the mailbox listing after deleting, moving, or copying 
a message?

YES: When deleting messages, move them to your Trash folder instead of 
marking them as deleted?

NO: Use Virtual Trash Folder?

INBOX.Trash: Trash folder.



However my users are using:



YES: Return to the mailbox listing after deleting, moving, or copying 
a message?

NO: When deleting messages, move them to your Trash folder instead of 
marking them as deleted?

NO: Use Virtual Trash Folder?



And they see this behaviour sometimes when expunging too.



I tried clearing all cache* files without a result.

I am almost positive this is due to the new mailbox list caching code.

I'm not using a trash folder (or hide_deleted) or anything, and I 
don't get this when marking messages as deleted. I do get some notices 
somewhat randomly on expunge, but nothing on mark. What set of 
relevant prefs are you using?

When I try to empy Trash, or users withouth trash folders a trying to 
flag messages as deleted, we get:



Notice: Undefined property: msgno in 
/var/www/html/horde/imp/mailbox.php on line 915