Closed Bug 237880 Opened 20 years ago Closed 12 years ago

when multiple accounts pointing to same pop server share the same local directory, messages from pop-server are merged and scramble (unsupported)

Categories

(MailNews Core :: Backend, defect)

x86
Windows XP
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 218439

People

(Reporter: m, Assigned: Bienvenu)

References

Details

(Keywords: dataloss)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

I have 
- several pop-accounts configured
- for the same pop-server and
- to be placed into the same physical inbox-folder. 
When I manually retrieve the mails concurrently (by choosing "Get Message for
this Account" while another mail is being downloaded) the two messages are quite
likely to be merged an scrambled. 
This is a pitty but I know of the constraint and can avoid it. But once in a
while this also happens, when I have mail retrieved automatically every 10
minutes and that is really bothering me.


Reproducible: Sometimes
Steps to Reproduce:
1. 
2.
3.

Actual Results:  
Messages "merged an scrambled" means that 
- msg A has the header of msg B, msg B doesn't exist.
- msg B's body is merged somewhere into msg A's body, msg B doesn't exist  
It appears that all kind of rubbish may result from the collision.

Expected Results:  
I would expect that message retrieval from different accounts is locked in a way
so this can't happen, at least for those accounts that use the same inbox.


This seems to be a problem for all versions of mozilla that I have been using
sofar: 1.0, 1.1, 1.3, 1.5, 1.6
Unfortunately, this is not supported - in general, we're going to make it so you
can't set up multiple servers to point to the same directory on disk since it
can cause lots of problems. There's an existing RFE to allow accounts to share
inboxes, but that's tricky with our architecture because the folder locking
happens at the in-memory folder object level, not on disk. I'll think about it a
little, though.
Component: Mail Database → Mail Back End
changing summary
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: messages from pop-server are merged and scramble → when multiple accounts share the same local directory, messages from pop-server are merged and scramble
Product: MailNews → Core
(In reply to comment #1)
> Unfortunately, this is not supported - in general, we're going to make it so
> you
> can't set up multiple servers to point to the same directory on disk since it
> can cause lots of problems. There's an existing RFE to allow accounts to share
> inboxes, but that's tricky with our architecture because the folder locking
> happens at the in-memory folder object level, not on disk. I'll think about it
> a
> little, though.
> 

I PROTEST! The problem is arising when people are using multiple accounts *from*
*the* *same* *server* going to the same local Inbox. I'm using multiple accounts
going to the same Inbox and everything is working just fine, but each account
is from a different *server* (ISP), so they are accessed *consecutively*. The
problem *I'm* having, which is hpw I stumbled onto this thread (I was doing a
search for pre-existing bugs having to do with "multiple email accounts" before
reporting a new bug) is that since I started using multiple accounts, the
Mail/News Window Opens with the Folder Email Address having the focus instead
of the Inbox.

Jim H. (aka CuriousJ)
QA Contact: esther → backend
Product: Core → MailNews Core
Keywords: dataloss
Summary: when multiple accounts share the same local directory, messages from pop-server are merged and scramble → when multiple accounts pointing to same pop server share the same local directory, messages from pop-server are merged and scramble (unsupported)
We now allow you to defer one server to an other's inbox, and that's now supported. What's not supported is doing it manually by changing the local directory of an account to be the same as an other's account.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.