I'm trying to investigate why copying mails from one IMAP folder to 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. Keith ------------------------------------------------------- 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
