Hi all,
I'm pretty sure that this bug raises due to asynchronous http requests. But maybe not only because of this. What I mean: When dragging messages to another mailbox or deleting them from folder (thus either moving them to trash or deleting), we do following (in a backend part triggered by move_messages() and delete_messages() JS functions):
- (if not an immediate delete) copy messages to another folder
- mark original messages with \Deleted flag
- Expunge them
This is not an atomic operation, and if one polls folder state between second and third operations are run, (s)he will get list with messages marked for deletion too. And, original messages will be shown in a source folder if this happen between first and second operations. IMAP logs show following: == First login, select, etc. Let's call this session SESS_1 (SESS_1) C: cpy1 UID COPY 846,848,853,852,847,851,849,838,839,860,858,859,857,856,855,854,864,840,843,845,844,842,841,863,865,867,861,86 2,866,872,873,874,869,870,871,868,850,875,879,876,877,878,880,890,891,892,893,894,895,896,901,900,898,899,897,889,888,886,887,885,884,883,882,881,902 "Tests/ a" == Here is an another login, select, etc. (SESS_2) (SESS_2) C: thrd1 THREAD REFERENCES UTF-8 ALL (SESS_1) S: cpy1 OK [COPYUID 1252415407 838:902 1074:1138] Completed (SESS_1) C: flg UID STORE 846,848,853,852,847,851,849,838,839,860,858,859,857,856,855,854,864,840,843,845,844,842,841,863,865,867,861,86 2,866,872,873,874,869,870,871,868,850,875,879,876,877,878,880,890,891,892,893,894,895,896,901,900,898,899,897,889,888,886,887,885,884,883,882,881,902 +FLAGS (\Deleted) (SESS_1) S: * 1 FETCH (FLAGS (\Answered \Deleted \Seen $MDNSent) UID 838) ... (SESS_1) S: * 24 FETCH (FLAGS (\Deleted \Seen NonJunk) UID 861) (SESS_2) S: * THREAD (66)(70)(69)(68)(67)(65)(44)(45)(46)(47)(48)(50)(49)(51)(52)(60)(61 62)(63)(64)(43 53 (54 55 56 57 58)(59))(38 (42 39 40)(41))(13)(31)(32 33 34)(35 36 37)((24 (25)(29))(30))(3 (6 (8 7 5)(4))(26)(28))(27)(17)(18)(19)((20)(22))((21)(23))(1 2)((12)(14))((10)(15)(16)(11))(9) (SESS_2) S: thrd1 OK Completed (70 msgs in 0.000 secs) (SESS_2) C: FH12 FETCH 9,11,16,15,10,14,12,1,2,23,21,22,20,19,18,17,27,3,6,8,7,5,4,26,28,30,24,25,29,35,36,37,32,33,34,31,13,38,42,39,40 ,41,43,53,54,55,56,57,58,59,64,63,61,62,60,52,51,49,50,48,47,46,45,44,65,67 (UID RFC822.SIZE FLAGS INTERNALDATE BODY.PEEK[HEADER.FIELDS (DATE FROM TO SUBJECT REPLY-TO IN-REPLY-TO CC BCC CONTENT-TRANSFER-ENCODING CONTENT-TYPE MESSAGE-ID REFERENCES DISPOSITION-NOTIFICATION-TO X-PRIORITY)]) (SESS_1) S: * 25 FETCH (FLAGS (\Deleted \Seen NonJunk) UID 862) ... (SESS_1) S: * 65 FETCH (FLAGS (\Deleted \Seen) UID 902) (SESS_1) S: flg OK Completed (SESS_1) C: exp1 UID EXPUNGE 846,848,853,852,847,851,849,838,839,860,858,859,857,856,855,854,864,840,843,845,844,842,841,863,865,867,861 ,862,866,872,873,874,869,870,871,868,850,875,879,876,877,878,880,890,891,892,893,894,895,896,901,900,898,899,897,889,888,886,887,885,884,883,882,881,902 (SESS_2) S: * 1 FETCH (FLAGS (\Answered \Deleted \Seen $MDNSent) UID 838 INTERNALDATE "13-Jul-2009 18:19:26 +0200" RFC822.SIZE 6526 BODY [HEADER.FIELDS (DATE FROM TO SUBJECT REPLY-TO IN-REPLY-TO CC BCC CONTENT-TRANSFER-ENCODING CONTENT-TYPE MESSAGE-ID REFERENCES DISPOSITION-NOTIFICATION-TO X-P RIORITY)] {436} ... (All requested headers are printed) (SESS_2) ==(All messages are printed) (SESS_1) S: * 1 EXPUNGE ... (SESS_1) S: * 1 EXPUNGE (SESS_1) S: * 5 EXISTS (SESS_1) S: * 0 RECENT (SESS_1) S: exp1 OK Completed
Bug do not appear when moving/deleting a small amount of messages, probably because of high speed of all operations in that case.
Do anybody knows, how to avoid such asynchronous behavior when doing non-atomic IMAP operations?
Best, Vladislav _______________________________________________ List info: http://lists.roundcube.net/dev/