Keith Edmunds writes:
I'm trying to investigate why copying mails from one IMAP folder toI see several issues here.
another fails silently about 50% of the time with the sylpheed-claws
MUA (v.0.8.5). By "fails silently" I mean that there are no indications
that the copy has not taken place save for the fact that the mail
concerned does not appear in the destination folder.
Here is my analysis of the IMAPDEBUGFILE output from one such
unsuccessful copy attempt. Have I misinterpreted something
somewhere? Sylpheed-claws issues five commands to implement the
copy; is it contravening the RFC somewhere (I don't think so, but
_something_ isn't right here)?
First command:
READ: NUMBER: 981
READ: ATOM: UID
READ: ATOM: STORE
READ: ATOM: 3501:3501
READ: ATOM: -FLAGS
READ: LPAREN
READ: ATOM: \FLAGGED
READ: RPAREN
READ: EOL
WRITE: 981 OK STORE completed.
This seems to be setting the "\FLAGGED" flag on the message to be moved.
Second command:
READ: NUMBER: 982
READ: ATOM: STATUS
READ: ATOM: INBOX.Scratch
READ: LPAREN
READ: ATOM: MESSAGES
READ: ATOM: RECENT
READ: ATOM: UIDNEXT
READ: ATOM: UIDVALIDITY
READ: ATOM: UNSEEN
READ: RPAREN
READ: EOL
WRITE: * STATUS "INBOX.Scratch" (MESSAGES 3 RECENT 0 UIDNEXT 4
UIDVALIDITY 1035476717 UNSEEN 0) 982 OK STATUS Completed.
This seems to be a STATUS command performed on the intended destination
folder, and indicates that there are currently 3 messages in that
folder.
Third command:
READ: NUMBER: 983
READ: ATOM: UID
READ: ATOM: COPY
READ: NUMBER: 3501
READ: ATOM: INBOX.Scratch
READ: EOL
WRITE: 983 OK COPY completed.
This seems to be the actual UID COPY, and seems to be successful.
Fourth command:
READ: NUMBER: 984
READ: ATOM: SELECT
READ: ATOM: INBOX.Scratch
READ: EOL
WRITE: * FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent)
* OK [PERMANENTFLAGS (\Draft \Answered \Flagged \Deleted \Seen)] Limited
* 3 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1035476717] Ok
984 OK [READ-WRITE] Ok
The destination folder from the UID COPY is selected; note that it still
appears to have 3 messages in it (I would have thought it should have
4 now).
Fifth and final command:
READ: NUMBER: 985
READ: ATOM: UID
READ: ATOM: FETCH
READ: ATOM: 4:4
READ: LPAREN
READ: ATOM: UID
READ: ATOM: FLAGS
READ: ATOM: RFC822.SIZE
READ: ATOM: RFC822.HEADER
READ: RPAREN
READ: EOL
WRITE: 985 OK FETCH completed.
This seems to be a FETCH of what would be the new message (number 4),
but which, as we know from the SELECT command, does not exist. It still
appears to be successful, returning an "OK".
I would be grateful for any pointers to how to progress this issue;
thanks.
First, it looks to me that the original message UID 3501 does not exist. If the original message UID existed, the response from the server would've included the updated flags on message UID 3501. Here's a similar command and reply that provides an example of what should have happened:
a UID STORE 19814:19818 -FLAGS (\Flagged)
* 1 FETCH (UID 19814 FLAGS (\Seen))
a OK STORE completed.
Prior to "OK STORE completed" you should've received the updated flags for message UID 3501, which you didn't. So I suspect that message UID 3501 simply does not exist in the folder.
The second issue is an outright programming bug.
1) The client obtains the number of messages in the destination folder: three messages, with a UIDNEXT of 4.
2) The client uses COPY for the purpose of, supposedly, adding another message to the destination folder.
3) The client assumes that the copied message now has a UID of 4.
Well, heavens to Betsy, at any point in time between step 1 or 2, there is absolutely nothing that prevents any other IMAP client, or the operating system, from adding some other message to the same folder, which will receive UID 4. This message, the one that's just been copied, will now end up receiving UID 5, so in step three the client will retrieve the headers for the wrong message. Complete, and total, fsckup.
Furthermore, the client uses message UIDs, instead of message sequence numbers.
Message UIDs are not guaranteed to be strictly increasing. All that UIDNEXT tells the client is that the next message added to the folder will have a UID of _at least_ 4. It could be 10, 11, or 1735. The client cannot assume that the next message added to the folder will be UID 4.
That's simply because that somewhere between step 1 and 2, there is absolutely nothing that prevents another IMAP client from:
A) Adding another message to this folder,
B) Marking the message as deleted,
C) Expunging the folder,
D) Later, rinse, repeat.
So, if there's some kind of a network delay, or something, the message copied in step 2 can easily end up receiving any random UID greater than 4.
-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
