User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 If I move a message from one IMAP folder [Origin] (ex. Inbox) to another [Destination] (ex. Personal) It is removed from the Origin and not shown in the Destination. It seems that if the Client sits long enough it does refresh. (I have not timed this but I have noticed after a long time (15mins+) it does refresh). It also refreshes if I File->Exit Moz and restart MozMail. This also occurs when I "watch" MozMail determine a message as Junk and it is moved to the "Junk" folder in my IMAP Store. If I then switch to my "Junk" folder it does not show up. This behavior is the same if I manually mark an item as Junk. Reproducible: Always Steps to Reproduce: 1. Open MozMail and Enter an IMAP Store 2. Click and Drag a Message from your Inbox to A different folder (Junk) 3. Click on the Destination Folder to see if it exists. 4. If it does not show up. File->Exit Moz and restart. It will then show up inside the destination folder. Actual Results: @2 Message was removed or not visible in the original directory @3 Message was not shown in Destination directory Expected Results: @3 Message should be shown and should have kept the same attributes (\Deleted \Seen \Flagged) MailServer: MailMax 5.5 (IMAPMax Ver: 184.108.40.206 -Process that handles IMAP4Rev1 Protocol) I run my own server.
To add to the steps. One condition must be met to reproduce this bug that I just noticed. The destination folder must have already been loaded from the server prior to moving something to it. It seems that the moved message is not refreshed in what has been cached for that folder. I think this also brings to view one important feature which would help workaround issues such as this. Adding a "refresh"/"reload" button to load a fresh copy of a folder from the server and to delete the "cache" from that session would help greatly in the case of new bugs like this one.
this works fine for me, with my imap servers. Can you generate a protocol log that shows the problem? thx. http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap
haven't found anyone that can reproduce. 1.6- for now, until we get some more debugging and a patch
Created attachment 138507 [details] Protocol Log Files (Some Personal Stuff Removed) View first lines in IMAPLOG_mod.log file to see actions performed to produce the log file. Upon going to the "Firewall Log Files" folder a second time you do not see the second moved message.
thx for the log. It looks to me like the server is never telling us about the second message. The first message is uid 2395, as you can see when we fetch its headers: UID fetch 2395 (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To)] then you copy the new message to the firewall log files folder: 15 uid copy 58829 "Firewall Log Files" the new message should have a uid of 2396 or greater (UID's have to be ever-increasing) then, you clicked on the target folder again, which caused us to issue the following protocol: 6 UID fetch 2396:* (FLAGS) 2468[1d11528]: 1f0b370:mail.entrellix.com:S-Firewall Log Files:CreateNewLineFromSocket: * 1323 FETCH (UID 2395 FLAGS (\Seen)) 2468[1d11528]: 1f0b370:mail.entrellix.com:S-Firewall Log Files:CreateNewLineFromSocket: 6 OK UID FETCH complete. i.e., we tried to fetch the flags of all messages with UID 2396 or greater, and the server didn't tell us about any (it did tell us about 2395 again, but we already knew about that one). In short, I think this is a server error.
David-- I've forwarded this bug to the programmer of this particular IMAP server. Actually to see the newest message the client would have to re-select the folder. It seems that command is never sent. I may be a little misty on the IMAP4 spec but I'm almost positive that the spec says (or some comment/best practice) when you select a folder it creates a "state" or something. To see "new" messages ie any newer UID's you would have to re-select that folder which would create a new state for that current mailbox and connection... at which point you would be able to see it.
I think the RFC gives the server implementer a little wiggle room about whether it has to report the new messages w/o reselecting the folder, but every server we've dealt with up til now does report the new message(s).
I agree the RFC gives wiggle room about that in the protocol but its still a best practice to stick the the rfc recommendation and not to assume the server does or does not require as such. Sending the extra Select command would fix both senario's and allow Moz to work correctly (and to the RFC spec).
Actually, I don't think the RFC really gives as much wiggle room as you suggest. I don't see any place in the RFC that suggests we should reselect a folder before using it, which is similar to saying we should never cache connections.
Maybe you can point me at the part of the RFC that says we should re-select an already selected folder before using it. The RFC is vague about a lot of things, but I can't really find any comments about things like this. There are comments about multiple clients accessing the same folder, but that's not happening here.
>There are comments about multiple clients accessing the same folder, but that's not happening here Actually it is. One Connection is coping it into that folder and the other connection is currently selected in that folder. If it was a single connection the copy would occur and then a select on the second folder before the list. I haven't had time to look but it is in an RFC in that context... basically preserving state for each session.
David, I don't know if there is any other conclusion, but Brian hadn't cited supporting section. And your assertion was we are doing the right thing. I'm not sure Brian is still about - no response to ping.
the RFC says that it's up to the server to decide how much to keep different connections in sync, but in general I've found that servers do a decent job at it, decent enough that I wouldn't want to slam them by deselecting and reselecting the folder, which can be expensive.
Bienvenu in comment #13 > the RFC says that it's up to the server to decide how much to keep different > connections in sync, but in general I've found that servers do a decent job at > it, decent enough that I wouldn't want to slam them by deselecting and > reselecting the folder, which can be expensive. Bienvenu is your thinking then WONTFIX?
yes, I'll mark this wontfix.