On Tue, 29 Jun 2004, Roland Hill wrote: >Hi Andreas, >* Andreas Aardal Hanssen <[EMAIL PROTECTED]> [29-06-04 06:37]: >> .sent/cur/1084056953.9923_337.rrl03:2,S >Couldn't find any messages with this ID, however I did find this: >[EMAIL PROTECTED]:~/Maildir/.sent/cur> ls -al 1088418091.16326_409.rrl03:2,S >-rw------- 1 roland users 373968431 2003-10-20 18:29 >1088418091.16326_409.rrl03:2,S >I have moved this message to another location and fetching the /.sent >folder now seems to be okay.
Try moving the message in again. If this makes the IMAP server fail again, then we have a concrete way to find the exact bug. Binc does handle huge emails quite fine with no extra memory usage. I tested with a 1GB email - no problem, although it did take some time to parse. If you are able to reproduce your problem, then I hope we can cooperate off-list to find the point where Binc caves in. Andy :-) PS: Hehe, actually I did a profile of the parser using this 1GB test email using calltree/valgrind and kcachegrind, and found a way to make the parser approximately 30% faster ;-). On my machine anyway; and I didn't account for how much of the time was spend in IO operations so the actual parser may have gained more than this. I submitted it to 1.3 (the change is too big for 1.2). PPS: calltree/valgrind and kcachegrind are _invaluable_ tools for C++ programmers who enjoy optimizing code. Just _look_ at those sexy screenshots. I warmly recommend these tools to _every single_ C and C++ programmer out there: http://kcachegrind.sourceforge.net/cgi-bin/show.cgi http://valgrind.kde.org/ -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | "It is better not to do something http://www.bincimap.org/ | than to do it poorly."
