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)

x86
Linux
defect
Not set
critical

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)
Severity: major → critical
Keywords: dataloss
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
You can't have 2 Accounts with the same name if you use the UI. That means that this bug is possible invalid...
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, .... ;-)
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: 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/
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
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.