Closed
Bug 183879
Opened 23 years ago
Closed 20 years ago
All mail loaded via POP3 on startup of Mozilla is lost
Categories
(MailNews Core :: Networking: POP, defect)
Tracking
(Not tracked)
RESOLVED
EXPIRED
People
(Reporter: goetz, Assigned: naving)
Details
(Keywords: dataloss)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
I configured Mozilla to start with both browser and Mail-client. On startup
checks the POP3-Mailbox and downlaods all Mail available. Unfortunately this
mail is only added to Inbox.msf but not to Inbox. Hence the all mail content is
lost.
Checking the POP-Mailbox after startup (either automatic and manual) works fine.
Reproducible: Always
Steps to Reproduce:
1. Startup mozilla with browser and mail-client. New Mail must be avialable on
POP3-Server.
2. Automatic mail check performed by Mozilla-mail client on opening the mailwindow.
Actual Results:
Mails are listed in the Inbox-window, but empty. Inspection of the Inbox-file
shows that mails are not appended to Inbox (though added to Inbox.msf)
Expected Results:
Add the mail downloaded correctly to the Inbox-file.
- Mozilla is installed on the central file-server
- Enigmail is systemwide installed (0.63 for Mozilla 1.1 and 0.70 for Mozilla 1.2.1)
- Maildirectory is on $HOME/nsmail rather than on
$HOME/.mozilla/$USER/..../MAIL/... . However there is no permission problem with
that (at least from the Unix side), since getting Mail works fine if its started
after startup (either automatically or manually) or with Mozilla 1.1 on the same
setup (same $HOME/.mozilla and $/HOME/nsmail)
- I use the pinball-theme (though I doubt that this is related here)
| Reporter | ||
Comment 1•23 years ago
|
||
Sorry, for not tracking down all eventuallities. I think I found the origin of
the bug. What happened.
We have here a local mail SMTP-Server (exim). The directory under in which this
Server stores its mail is also available via NFS. Most people get there mail via
'movemail'. Unfortunately movemail ignores the mail filters. Therefore via
decided to add a POP3-Server on the machine running the SMTP-Server and get the
mail from there via POP3.
To test this we first added a new POP3-mail account in Mozilla. This new account
works fine on some test mails. Hence we changed the movemail into POP3 by
editing pref.js. To surprise Mozilla seemed to merge both account (which now are
both POP3 account on the same server with the same username).
However what left in the prefs.js are two almost identical accounts with
different Mail-directories, but only one (the default account, which is the
former movemail-account) is displayed in the mail-client window.
What happens on startup is that the Inbox.msf of the former movemail account and
the Inbox file (and maye the Inbox.msf) of the (shadowed) test-POP3-account is
updated. Since the mail-client displays only the former movemail-account I got
empty mails on this account, but at a different (but invisible in the client)
location the mails are still stored.
Conclusion: This seems not a data loss bug, but a bug of handling two identical
accounts with different directory locations. Alltough it look less severe to me
now, it might be not to unlikely to happen for users switching from movemail to
POP3.
R"udiger Goetz
Comment 2•23 years ago
|
||
You can't have 2 Accounts with the same name if you use the UI.
That means that this bug is possible invalid...
| Reporter | ||
Comment 3•23 years ago
|
||
You may have 2 accounts with the same name if you switch from movemail to POP3
for an account, since you can't do that with UI. Hence you must edit prefs.js.
And than you may have two account with the same name if you created a test POP3
account before (and forgot to delete it). However, if movemail would be an
option in the UI, .... ;-)
Updated•21 years ago
|
Product: MailNews → Core
Comment 4•20 years ago
|
||
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:
Firefox: http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey: http://www.mozilla.org/projects/seamonkey/
Comment 5•20 years ago
|
||
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.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → EXPIRED
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•