moving mail doesn't take affect if there are parallel sessions



14 years ago
10 years ago


(Reporter: bugzilla, Assigned: Bienvenu)



Firefox Tracking Flags

(Not tracked)




14 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.6) Gecko/20040114
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616

In an environment with more than one user per IMAP account it is impossible
really to move or delete messages if there are other sessions open in parallel
with same folders open.
This affects all folders including INBOX.

Reproducible: Always
Steps to Reproduce:
1. Open two mozilla sessions at the same time with the same IMAP-Account. It
doesn't matter if on the same or on different machines.
2. Select same mails (I've tried more than hundred) in same folder in both sessions.
3. Move selected mail into another folder on both machines at the same time.
4. Compare contents of affected folders :-(

Actual Results:  
Moved mail will be duplicated.

Expected Results:  
Moving mail instead of copying.

I've tried many versions of Mozilla and didn't found this bug in 1.42. There's
an excellent behavior of killing the connection to that client who didn't come
first with the move command. Maybe that's not nice to the clients, but much more
better for the integrity of mail folders.

IMAP Server is UW IMAP4rev1 2001.315

Comment 1

14 years ago
that disconnection is a server behaviour, not a client behaviour. And what
happens when you do this is also server-defined. Did you change mailbox formats
on the server?

Comment 2

14 years ago
(In reply to comment #1)
> that disconnection is a server behaviour, not a client behaviour. And what
> happens when you do this is also server-defined. Did you change mailbox formats
> on the server?

No - I didn't change anything on server through all the tests with different
mozillas. The one and only change is the amount of traffic in our IMAP boxes of
100-500 mails per day and box. In order to share work there are about 20 folders
where our service employees like to store their mails.

Nothing else...

Comment 3

14 years ago
Are you saying that the messages are duplicated in the destination folder, or
that they remain in the source folder after being copied to the destination
folder, i.e., the copy happens but the delete does not? I'm guessing it's the
latter. You could try generating an imap protocol log of such a session:

and we can see if the second session killed the first session or not, and if the
delete gets stored or not.

Does your imap server support the IDLE command? If so, you might try turning it
off and see if that affects this.

Comment 4

14 years ago
sorry, to be more specific - make it so the client won't use the IDLE command,
by going into advanced imap server settings and uncheck the "use idle" box.

Comment 5

14 years ago
(In reply to comment #3 and #4)

It's exactly what you guess:
> the copy happens but the delete does not

I tried move-actions with _and_ without activated idle-command but there's no
difference in fact.

You can download my logfiles bzipped from

Thank you

Comment 6

14 years ago
I looked at the logs but couldn't see the client doing anything wrong...I'm not
sure why in one case the server drops the connection and not in the other, but
it could just be a matter of timing and potentially a difference in the command
we send to delete a bunch of messages (it can be shorter in recent builds, which
might mean it executes more quickly)
Product: MailNews → Core
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Last Resolved: 13 years ago
Resolution: --- → EXPIRED
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.