I take that back.  PHP must have been reusing an IMAP resource 
pointing to the old imapproxy connection, because today, without an 
imapproxy, things are working as expected.  Nice to finally be able to 
delete messages again :D

Its not fixed for me :/  No flags are getting updated on messages.   
Seen messages remain unseen when I go back to the mailbox view.  I can 
delete a message but instead of it being hidden, its drawn greyed out 
and with a line through, as if the delete flag is set.  But on a 
refresh, its marked as unseen again.  Makes no difference if I disable 
my imap proxy or not.  Mail server is Cyrus IMAP.

As mentioned before, this is already fixed.
Can't reproduce this.  Anyway, in the past month+ we've cleaned the 
mailbox cache code up a bit and have done some debugging so this most 
likely was fixed somewhere in there.

This should now be fixed in HEAD and 4.1.0.

This request has been moved to a separate ticket (Bug 3278) as it 
doesn't pertain to an issue with Virtual Trash.

Fine by me. :)

Just to follow up on my original note of this ticket:



With the IMAP Cache enabled, I can delete messages using VTrash and 
they are not displayed.  However, I cannot empyt VTrash, because the 
identifier passed by the submission is not the VTrash folder id.



With the IMAP Cache disabled, I can flag messages (i.e. they show as 
deleted) but the flags do not stick after a refresh.  So messages are 
not marked as read, deleted, etc.  When messages are marked as deleted 
without the Cache enabled, they are displayed as deleted (i.e. with a 
line through them and greyed out), even though I'm using VTrash and 
they should be hidden.



With the cache enabled, I'm experiencing random hangs of Apache, which 
require me to HUP it as well.  Haven't identified a pattern yet, nor 
had a change to trace any code, but this is using the file-based Cache 
driver.

Emptying trash is broken again.



The problem appears to be that the mailbox id being passed to the 
emptyMailbox function is **search.  The check for 
IMP_VFolder::isVTrashFolder($mbox) results in a comparison of **search 
to my vtrash id, which returns false, and hence, the proper 
expungeMailbox function doesn't get called.



I can't find where **search is being passed - the empty trash request 
at least is passing the proper vfolder id in the URL.

That would be a really cool idea, but also a huge change to the thread 
view, so I would not like to change this unless we have different 
sorting orders in different folders.

I won't be able to manage my mailing list folders without threaded 
sorting, but such a changed behaviour would be contra productive in my 
regular inbox.

What if we changed thread sorting to be more "conversations"-like, and 
only showed the top-level message in the thread in the mailbox list? 
Then show the whole thread in the message view if using thread 
sorting. Would that make it easier? We could then consider a 
"conversation" deleted only if all of the messages in it were deleted.

I agree, but unfortunately there is no elegant way of working around 
this.  Simple fact is imap_thread() does not support a search 
parameter so you have to do threading on the entire mailbox.  And it's 
not as simple as removing deleted entries from the thread list - those 
deleted entries may radically change the shape/nature of the thread so 
simply trying to do some kind of decrement of the level of child 
messages horribly breaks the threading tree.



Another option would be to build our own thread parsing function using 
IMAP_Client::.  But that would have the disadvantage of requiring us 
to open a second connection to the IMAP server along with all the 
overhead of having to load all code associated with IMAP_Client::.



The last option would be the most radical and that would be to disable 
the thread sorting (and reverting to subject sorting) if not using a 
trash mailbox and hiding deleted messages.

Nope, messages are sorted by date.  I can only delete messages if I 
turn caching on.  I also noticed that if I read a message, with 
caching off, which should mark it seen, if I come back, its marked as 
unseen.  So it seems with caching turned off, something is not getting 
updated properly.
This is still acting up for me.  WIth the fix for emptying vtrash, I 
was able to empty my vtrash and I had no messages in my vtrash.  Then, 
with caching turned on, I deleted one message.  If I go to my vtrash 
folder, I show one message, but the text states " 1 to 2 of 2 
Messages".  Two deleted messages yield "1 to 4 of 4 Messages".  So 
something is getting counted twice.



Also, I've found if I empty trash from the vtrash folder screen, I get 
returned to a search screen with "No messages matched your search.", 
instead of to the vtrash folder I was just in.  I know vtrash is 
technically just a search but it makes more sense to be presented with 
an empty vtrash folder display, than the search screen, if one empties 
vtrash.
This is working now.

Is there really now way to work around that, even if not in an elegant 
way? This is really unintuitive and confusing for the users (including 
myself).

You wouldn't happen to be using 'thread' sorting, are you?  With 
thread sorting, we must always display all deleted messages in the 
folder, no matter if we are using virtual trash or not.
This works correctly for me.
Try what I just committed - the empty trash menu icon was not pointing 
to the correct mailbox name when using virtual trash.

I retract that, partially.  If the cache is turned on and I delete a 
message, it is no longer displayed.  Turn the cache off and delete a 
message and it behaves like I display of deleted messages turned on.

I had a brief window about a month ago, or so, when this worked as 
advertised.  With the cache and other code refactoring, something is 
still broken with vtrash, or I've got a preference or setting mangled.



Symptoms:



If I delete a message, instead of it being hidden, it is displayed in 
the manner that a message that has the IMAP delete flag set (grey with 
line through it).  A page refresh reverts this - the message is no 
longer marked as deleted.



If I click on the virtual trash folder icon,  I'm taken to the screen 
that displays deleted messages, which is fine.  But, the message count 
tells me there are "1 to 20 of 20 messages" and if I count them, among 
the three folders with deleted messages, there are a total of 12.



If I click the Empty Trash icon, I get a message that "The folder 
trash is already emptied".  I don't have a folder named "trash".



Above all happened without the cache code turned on.  Turning it on 
doesn't seem to make a difference.