81355 - Changing the local directory setting for an account creates a new account directory

Status: NEW

(SeaMonkey :: MailNews: Account Configuration, defect)

Description

[phoenixreads]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9) Gecko/20010505
BuildID:    2001050515

After an account is created changing the local directory setting results in a
separate and new account being created leaving the old account intact but with
the previous directory name.

Reproducible: Always
Steps to Reproduce:
1. Create a pop email account
2. Create a dummy email in the new account and save it (used for verification of
new account)
3. Change email account's directory name.  (e.g. pop.account.domain to
pop2.account.domain)
4. Reset email and navigator.
5. Look under above account and dummy email disappears.

Actual Results:  A complete new empty account is created and referenced. 
Checking the directory structure the a new account directory is created with the
previous one remaining intact.

Expected Results:  To move the account directory to the new location deleting
the old directory and/or prompting the user to keep the old files intact (allows
for option of creating a copy of a current account).

Comment 1

[Keyser Sose]

Marking NEW.

Comment 2

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 3

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 4

[Max Spicer]

*** Bug 84952 has been marked as a duplicate of this bug. ***

Comment 5

[Alan Karna]

This bug does not require creating a new directory. Any custom directory has
this bug, including previously existing ones. (I suspect that part of the
condition may be having the custom directory on another drive?)

I store my accounts in "F:\Netscape Mail\accountname" and this was working in a
previous mozilla build (1.7RC2). Upon upgrading I found that 1.8a was
interpreting this as "\\.\F:\Netscape Mail\accountname" the \\.\ in front making
it an invalid entry. I used the "Browse..." button to change the directory to
the proper location, clicked OK, then restarted Mozilla. My messages were still
not showing, I went back to the settings, and the box again read
"\\.\F:\Netscape Mail\accountname"

I thought maybe my preferences had been corrupted, so I renamed the prefs.js
file and started over with the Mail/News Wizard. It worked properly in the
default setup "C:\Windows\Application Data\Mozilla\ ...etc, etc" I used the
"Browse..." button to change it back to "F:\Netscape Mail\accountname" and
clicked OK and restarted Mozilla. Mail stopped functioning again, I went to the
settings and the "local directory" box once again read "\\.\F:\Netscape
Mail\accountname" 

Checking the prefs.js file with Notepad, it had the proper string "F:\\Netscape
Mail\\accountname" it seems Mozilla is having a problem reading the prefs.js
file properly under this circumstance

I also noted the line:
user_pref("mail.server.server2.directory-rel",
"[ProfD]../../../../../../../F:/Netscape Mail/accountname");

in prefs.js

it may also be reading this improperly (it matches a backed up copy I have from
a previous version, so the settings are being written to prefs.js properly)

Comment 7

[Serge Gautherie (:sgautherie)]

(In reply to comment #5)
> I also noted the line:
> user_pref("mail.server.server2.directory-rel",
> "[ProfD]../../../../../../../F:/Netscape Mail/accountname");
> in prefs.js

If I remember correctly:
I have seen this with SeaMonkey v1.1.x on Win2000,
when I tried to change the preferences directly in the .js file,
SeaMonkey would take the new location on next startup,
but mess it up on quitting/saving the preferences.

But a separate bug should be filed, as this is not the same issue as comment 0.