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/
