Bottom line: there seems to be a line length limit on communications with the IMAP server, and I'm exceeding it. I suspect the limit is on mutt's side, but I don't know that. The server is cyrus. See below for more. On Monday 21 May 2007 10:29, Christoph Berg wrote: > Re: Ross Boylan 2007-05-15 > <[EMAIL PROTECTED]> > > > Version: 1.5.13-3 > > > > I can open and examine the contents of some folders on my Cyrus IMAP > > server, but when I try to exit (either by quitting the program or > > changing to another folder) mutt hangs for awhile (minutes) and then I > > get a timeout message: > > Idle too long, closing connection > > Error saving flags > > The first messages also appears in my cyrus logs, so I assume it was > > generated by the server and reported by mutt. > > Hi Ross, > > thanks for the report. > > We are just trying to update the mutt version in etch to effectively > the version that is now in unstable (1.5.13-1.1etch1 is just a > recompile of 1.5.13-3) and the difference to 1.5.13-1.1 is a fix > concerning IMAP hangs, so it would be very interesting for us to know > if you can reproduce the problem with the etch version too. > > Could you be so kind and give 1.5.13-1.1 a try? > > Concerning your bug, we probably need a debug trace (mutt -d <number>) > and the .muttdebug0 file to be able to say more. > > Christoph I ran it with mutt -d 10. BTW, I don't see the -d option on the man page; is that deliberate? Rather than send all 20MG of somewhat personal info, I think I can give you the good stuff. I opened the folder with mutt -d 10 -f imap://localhost. I have passwords in my .muttrc. The program opened the folder, slowly (23k messages). Then I did o r (order by date received; it was threaded) and went to the bottom. Then I typed q.
The log shows parsing the .muttrc and pulling down all the headers. Then 4< ) 4< a0005 OK Completed (5.580 sec) IMAP queue drained imap_open_mailbox: msgcount is 23177 mail_addr_is_user: no, all failed. mail_addr_is_user: no, all failed. mail_addr_is_user: no, all failed. # repeated many times, probably while threading? mail_addr_is_user: no, all failed. mutt_index_menu[633]: Got op 158 mail_addr_is_user: no, all failed. mail_addr_is_user: no, all failed. mutt_index_menu[633]: Got op 144 4> a0006 UID STORE 194:223,225:269,489,500,513,517,519:521,523:524,526,528,531,541:542,544:545,552:553,555:556,562:563,566:568,570:572,2238:2245,2261:2265,2269:2274,2276,2289:2290,2292:2294,2298,2300:2301,2303:2306,2308:2310,2312:2314,2321:2323,2339:2341,2347:2348,2350,2357,2360:2361,2365,2369:2374,2399:2401,2403,2414,2416:2418,2420:2423,2425:2428,2440:2441,2443,2450:2451,2455:2461,2464,2472,2480:2482,2487:2489,2491,2509:251 # many more UID's ,30851:30859,30861 +FLAGS.SILENT (Old) mutt_socket_write: ERROR: wrote 4091 of 30105 bytes! So it looks as if the UID list is too long. Perhaps I'm not seeing it other cases because a more natural contiguous range (e.g., 1:20000) can cover the messages in a few characters. My INBOX has a lot of out of temporal sequence messages as a result of the way it was populated. It also has a lot of gaps in UIDs as a result of moving messages out of the INBOX. I'm not sure how much energy this is worth to repair. The fundamental problem is that mutt, like almost every other email client, is trying to represent and manipulate every single message in the folder rather than just enough messages to fill the screen. Mulberry, which was recently open-sourced, is the only one I'm aware of that does better. It's possible evolution does too, but it has some other bugs right now. In other words, even if this were fixed, the results would still be quite slow for large boxes. Ross -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
