Closed
Bug 228898
Opened 21 years ago
Closed 15 years ago
IMAP Move IMAP Folder TO IMAP Folder Destination Folder Not Refreshed until restart
Categories
(MailNews Core :: Networking: IMAP, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: brian-roberds, Assigned: Bienvenu)
Details
Attachments
(1 file)
34.72 KB,
text/plain
|
Details |
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: 5.5.3.1 -Process that handles IMAP4Rev1 Protocol) I run my own server.
Reporter | ||
Updated•21 years ago
|
Flags: blocking1.6?
Reporter | ||
Comment 1•21 years ago
|
||
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.
Assignee | ||
Comment 2•21 years ago
|
||
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•21 years ago
|
||
haven't found anyone that can reproduce. 1.6- for now, until we get some more debugging and a patch
Reporter | ||
Comment 4•21 years ago
|
||
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.
Assignee | ||
Comment 5•21 years ago
|
||
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.
Reporter | ||
Comment 6•21 years ago
|
||
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.
Assignee | ||
Comment 7•21 years ago
|
||
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).
Reporter | ||
Comment 8•21 years ago
|
||
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).
Updated•21 years ago
|
Flags: blocking1.6? → blocking1.6-
Assignee | ||
Comment 9•21 years ago
|
||
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.
Assignee | ||
Comment 10•21 years ago
|
||
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.
Reporter | ||
Comment 11•21 years ago
|
||
>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.
Updated•20 years ago
|
Product: MailNews → Core
Comment 12•16 years ago
|
||
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.
QA Contact: grylchan → networking.imap
Updated•15 years ago
|
Product: Core → MailNews Core
Assignee | ||
Comment 13•15 years ago
|
||
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.
Comment 14•15 years ago
|
||
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?
Severity: normal → minor
Assignee | ||
Comment 15•15 years ago
|
||
yes, I'll mark this wontfix.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•