Actually, this is broken - see Bug 3338.

Yes, fixed for me also.  Thanks!

Verified.  It's working for me as well.



Thanks Mike!

WELL DONE!! This is working for me now.



One quick question, just to make sure it's working correctly...In the 
Virtual Inbox, when I delete the last message in a folder from the 
message view, I had expected to see the message view of the first 
unread message in the next folder. Instead, I'm taken back to the 
mailbox view (of the Virtual Inbox). I can see, though, that this 
might be the expected behavior; I just want to make sure it isn't a 
bug or misconfiguration at my end.



Thanks for the great work!

Rick

Think I figured this out.  We weren't setting the imap stream to 
readonly access in IMAP_Search:: and UW-IMAP doesn't handle concurrent 
access as well as other servers.  Additionally, we now simply use the 
currently open stream in IMP anyway (instead of opening a new stream) 
so this shouldn't be an issue.

Bumping - showstopper for 4.1.0.

If this is really this issue, then UW-imap and/or c-client is really 
hosed.  No other IMAP clients I know of have an issue with two 
connections to the server at the same time (this may be why I am not 
seeing this issue - I use dovecot).  Why should losing mailbox lock on 
the server cause a segfault on the client end?



If someone could point to the area where the code is segfaulting - or 
at least the last area of code which will run before segfaulting - 
that would be helpful.

I see the same thing.  UW-IMAP, CVS FRAMEWORK_3.  When I try to do 
some operation

on the last message in the virtual mailbox (delete it, undelete it, 
mark it as important, etc)

then I get a segfault in the web browser.  The UW-IMAP server shows 
that a second imap

connection is made while the first imap connection is still active.   
This causes UW-IMAP

to kill the first imap process since it lost the mailbox lock, and 
that causes the segfault

in the web server.  Note if you use the browser back button to return 
to the previous page,

the message will show the new state of the message in question; that 
is, the message

really does get deleted/undeleted/changed as you wanted.  So the error 
is not in the

operation itself, but it seems to be in the failure to terminate the 
imap process after the

operation is done.



It might be relevent that I have the option set to return to the 
mailbox view after deleting

the last message in a mailbox, etc.  In other words, it may be that 
setting which is causing

it to create the second imap connection.  I've not tried disabling 
that yet though.

Then someone that is experiencing these problems will need to debug 
this issue.

It is for me :-(

Now that we rewrote the IMP_Search:: code, is this still happening?

No change for me either (upgraded to PHP 4.4.1 this morning).



I was thinking of changing IMAP servers over the Thanksgiving weekend 
(probably to Courier), but will be unable to troubleshoot this further 
if I do. Is it worth sticking with UW, or is this an isolated problem 
(since it seems not many are having it) that I probably won't be able 
to fix?

I am still seeing this when connecting to UW-IMAP.

Has this been fixed with the implementation of the imap search code 
that determines whether the IMAP server supports UTF-8?

FWIW, the only difference in this call between just viewing the search 
(or virtual folder) and returning to it after a deletion is that $imap 
points to a different resource id.  No idea if this is helpful to you 
or not...I'll continue to try to track down more info.

I get the same; no error messages and no change. The Apache child 
process is killed due to a segmentation fault every time, though.

Also, not sure why I thought this wasn't happening in IE, but I just 
checked again and I am getting similar problems with both IE and 
Firefox.  Not sure if that's relevent for you or not.

Sorry MIchael,  no error messages produced and problem still occurs 
when $this->_charset is removed.

Can you go to line 164 of framework/IMAP/IMAP/Search.php and change this line:

             return @imap_search($imap, $criteria, SE_UID, $this->_charset);

to:

             return imap_search($imap, $criteria, SE_UID, $this->_charset);

and report any error messages.  If no error messages are output, try 
removing the $this->_charset parameter and see how that works.

I suppose it's worth mentioning this is with apache 1.3.33 / php 4.4.0 
/ imap-2004g

Now that I got to the root of Bug 2828 and got a quick and dirty fix 
(just hard-coded the 8859-1 charset in) I was able to test this issue 
against Courier.  Everything works as expected when using Courier IMAP.



If I switch back to UW-IMAP (most recent version 2004g I believe), I 
see this behaviour again.  Apache log shows:



[Wed Oct 26 01:35:27 2005] [info] [client 192.168.1.1] (32)Broken 
pipe: client stopped connection before rwrite completed



[Wed Oct 26 01:54:39 2005] [notice] child pid 3907 exit signal 
Segmentation fault (11)



This only happens when communicating with UW-IMAP server...

FWIW, I'm seeing very similar results. UW-IMAP v.2004g (just upgraded, 
but was seeing this behavior with the old version as well).



When I view Virtual INBOX, I see all of the new messages grouped by 
the folders containing them. If I select the checkbox of a message and 
click the delete link, the browser spins for a minute, then stops with 
no refresh. If I open the first message in one of the folders (viewing 
from inside Virtual INBOX), everything works as expected (deleting or 
moving to the next message) until I get to the last message in the 
particular folder. Trying to delete it nets the same results; the 
browser spins for a minute, but the screen never refreshes. It 
appears, though, that the message is deleted.



When this happens, the apache logs show segfaults. Unfortunately, I 
don't have the knowledge to find out what's causing it to segfault. 
I'm happy to troubleshoot, if somebody can help me with the "how" :-)

FYI - the problem in 2828 only occurs when I am using the Courier IMAP 
server.  Searching and *viewing*  items in virtual folders work fine 
when using UW-IMAP - it's just deleting them that is giving me the 
problem.



Not sure if it's relevant or not though ;)

Related to Bug 2828 (??)

Maybe another dev can reproduce this, but for now I am stumped as this 
works fine no matter what browser I use.

I just -



- updated to HEAD again and killed all my prefs just for good measure.

- cleared all browser cache files on my local box.

-  cleared out the php-accelerator cache files on my server and disabled.

-  cleared all old session caches.

-  upgraded to most recent FireFox (1.07)



I am still seeing this behaviour.  I see it on multiple windows and 
linux machines - all using FireFox.  IE works fine for me though.  I 
will try to trouble shoot this the best that I can, but I am not 
really all that familiar with the IMP code base.  Is there any other 
information I can provide to help?

Viewing that page does not produce any sort of javascript output for 
me - I see the expected results of a search page.  Are you sure you do 
not have a cache file or something that is causing the output to be 
invalid on your system?

I just update to HEAD again, and still have the problem.



FWIW, in IE this works fine, but in Firefox (using 1.04 on a windows 
box at the moment), I get a screen full of javascript code returned.   
Javascript console shows no errors. I've attached the source of the 
returned page...

I can't reproduce this.  Deleting messages in the virtual inbox screen 
correctly updates the mailbox for me.

On a related note, deleting messages from the message view works fine, 
*except* for when you try to delete the only remaining message in the 
virtual INBOX.  In this case, the message is deleted from the server 
but the screen does not update and continues to display the same 
message view.



Using latest CVS, UW IMAP, Firefox 104

When trying to delete a message from the virtual INBOX view (checking 
the checkbox on one or more messages, then clicking the delete 
action), it appears that the message is deleted, but the screen does 
not refresh to reflect this.



Not sure if this is related to ticket 2305 or not.