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)

x86
Windows XP
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: brian-roberds, Assigned: Bienvenu)

Details

Attachments

(1 file)

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.
Flags: blocking1.6?
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
haven't found anyone that can reproduce.  1.6- for now, until we get some more
debugging and a patch
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).
Flags: blocking1.6? → blocking1.6-
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.
Product: MailNews → Core
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
Product: Core → MailNews Core
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?
Severity: normal → minor
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.

Attachment

General

Creator:
Created:
Updated:
Size: