Closed Bug 392956 Opened 18 years ago Closed 15 years ago

Thunderbird occasionally forgets about profile and runs new account wizard for default profile

Categories

(Thunderbird :: Account Manager, defect)

Product:
Thunderbird
Component:
Account Manager
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: emoore, Unassigned)

References

Details

(Keywords: dataloss)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Build Identifier: Thunderbird 2.0.0.6 I don't have this problem but it is reported almost daily in the Thunderbird forums at MozillaZine. I know it has existed since version 0.3 and still occurs with 2.0.0.6. Once in a great while when you start Thunderbird it forgets about the existence of an existing profile and runs the new account wizard. Exiting and starting again doesn't workaround the problem - it looks like you lost your profile even though all of the files are still there. Lots of users who run into this problem panic since they haven't backed up their profile and think they might have lost everything. This problem only occurs if you used the default name for the profile (which most users do). The workaround is to move the profile per http://kb.mozillazine.org/Moving_your_profile_folder . The problem can be prevented by renaming the profile to use a unique name. See http://kb.mozillazine.org/Recovering_a_profile_that_suddenly_disappeared and http://kb.mozillazine.org/Keep_it_working_(Thunderbird) for more information. I would normally expect the same bug to occur in Firefox or SeaMonkey since they supposedly share the profile manager code but it doesn't appear to be a problem with those applications. I could be mistaken though as I mainly moderate the Thunderbird forums. This problem doesn't appear to be operating system specific. Reproducible: Sometimes Steps to Reproduce: 1. 2. 3.
Please don't confuse this bug report with https://bugzilla.mozilla.org/show_bug.cgi?id=205120 which reports similar problems after windows or the application crashes (see comments 1 and 6), or if prefs.js was corrupted (see comment 12). Ditto for https://bugzilla.mozilla.org/show_bug.cgi?id=139562 which describes lost profiles if they're stored on network drives. The problem I'm reporting doesn't require a crash, the profile is stored locally (usually in the default location), and none of the files in the profile are modified.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
No it isn't. I am attempting to report a problem that occurs without any type of crash, and no corruption of the profile. A power failure is a crash.
Severity: normal → critical
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
I misread bug 343851 comment 0 - he states only the profile names/.slt are there ... and that the data in those profiles is indeed gone. In your scenario, is it known whether profiles.ini and registry.dat are intact and correct? It would be helpful a) to list the forum posting URL(s) where this is mentioned and b) if those who posted and see this problem sign on to the bug and comment (it appears none have so far), or create their own bug. Failing that, i.e. not having corroborating information or steps to reproduce, it will be difficult to confirm the bug and thus make progress.
I have no information about registry.dat, its been so long since it mattered that nobody pays attention to it. For example, I deleted my registry.dat and had no problems. I don't have good information about what profiles.ini looks like after this occurs. I can only make guesses based on people being able to workaround their problem by modifying an existing profiles.ini file. Now that http://kb.mozillazine.org/Moving_your_profile_folder has a simpler way to move your profile using just profile manager commands it might be easier to get the information you asked for. Are you a developer?
no, not a developer. are you "tanstaafl of the kb" world?
Yes.
The only good examples I find are http://forums.mozillazine.org/viewtopic.php?p=3037916&highlight= and http://forums.mozillazine.org/viewtopic.php?p=3056529&sid=555a367db9184c3394b9edc6d0226203 and one of dubious quality http://forums.mozillazine.org/viewtopic.php?t=579216 if you see others please list them
Summary: Thunderbird occasionally forgets about profile and runs new account wizard → Thunderbird occasionally forgets about profile and runs new account wizard for default profile
Confirming this bug with current TRUNK debug build (suite): Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007112921 SeaMonkey/2.0a1pre I use seamonkey-1.1.6 normally, but for testing I compiled now TRUNK version. It has created ~/.mozilla/seamonkey/ instead of picking up ~/.mozilla/default/ tree. mokrejs@vrapenec$ ls -la .mozilla total 32 drwx------ 4 mmokrejs mmokrejs 4096 Nov 29 22:34 . drwx--x--x 92 mmokrejs mmokrejs 4096 Nov 29 23:38 .. -rw------- 1 mmokrejs mmokrejs 1046 Nov 29 22:56 appreg drwx------ 4 mmokrejs mmokrejs 4096 Nov 9 01:02 default -rw------- 1 mmokrejs mmokrejs 4286 Nov 9 10:39 mozver.dat -rw------- 1 mmokrejs mmokrejs 1074 Nov 29 22:33 pluginreg.dat drwx------ 3 mmokrejs mmokrejs 4096 Nov 29 22:37 seamonkey mokrejs@vrapenec$ ls -la .mozilla/seamonkey/ total 16 drwx------ 3 mmokrejs mmokrejs 4096 Nov 29 22:37 . drwx------ 4 mmokrejs mmokrejs 4096 Nov 29 22:34 .. -rw------- 1 mmokrejs mmokrejs 0 Nov 29 22:37 console.log drwx------ 5 mmokrejs mmokrejs 4096 Nov 29 23:36 oi54tv41.default -rw------- 1 mmokrejs mmokrejs 94 Nov 29 22:37 profiles.ini mokrejs@vrapenec$ ls -la .mozilla/seamonkey/oi54tv41.default/ total 3592 drwx------ 5 mmokrejs mmokrejs 4096 Nov 29 23:36 . drwx------ 3 mmokrejs mmokrejs 4096 Nov 29 22:37 .. -rw------- 1 mmokrejs mmokrejs 0 Nov 29 23:18 .parentlock drwx------ 2 mmokrejs mmokrejs 4096 Nov 29 23:18 Cache -rw------- 1 mmokrejs mmokrejs 0 Nov 29 22:56 Invalid.mfasl -rw------- 1 mmokrejs mmokrejs 1184779 Nov 29 22:51 XPC.mfasl -rw------- 1 mmokrejs mmokrejs 1940517 Nov 29 23:00 XUL.mfasl -rw------- 1 mmokrejs mmokrejs 1774 Nov 29 22:37 bookmarks.html -rw------- 1 mmokrejs mmokrejs 65536 Nov 29 23:01 cert8.db drwx------ 2 mmokrejs mmokrejs 4096 Nov 29 22:37 chrome -rw------- 1 mmokrejs mmokrejs 185 Nov 29 22:37 compatibility.ini -rw------- 1 mmokrejs mmokrejs 193284 Nov 29 22:51 compreg.dat -rw------- 1 mmokrejs mmokrejs 2048 Nov 29 23:36 cookies.sqlite drwx------ 2 mmokrejs mmokrejs 4096 Nov 29 22:37 extensions -rw------- 1 mmokrejs mmokrejs 538 Nov 29 22:50 extensions.cache -rw------- 1 mmokrejs mmokrejs 575 Nov 29 22:50 extensions.ini -rw------- 1 mmokrejs mmokrejs 9535 Nov 29 22:50 extensions.rdf -rw------- 1 mmokrejs mmokrejs 4096 Nov 29 23:30 formhistory.sqlite -rw------- 1 mmokrejs mmokrejs 13593 Nov 29 23:36 history.dat -rw------- 1 mmokrejs mmokrejs 16384 Nov 29 22:51 key3.db -rw------- 1 mmokrejs mmokrejs 5698 Nov 29 23:00 localstore.rdf lrwxrwxrwx 1 mmokrejs mmokrejs 18 Nov 29 23:18 lock -> 192.168.0.2:+13726 -rw------- 1 mmokrejs mmokrejs 477 Nov 29 23:00 mailViews.dat -rw------- 1 mmokrejs mmokrejs 3939 Nov 29 22:37 mimeTypes.rdf -rw------- 1 mmokrejs mmokrejs 1613 Nov 29 22:37 panels.rdf -rw------- 1 mmokrejs mmokrejs 604 Nov 29 23:02 pluginreg.dat -rw------- 1 mmokrejs mmokrejs 518 Nov 29 22:50 prefs.js -rw------- 1 mmokrejs mmokrejs 2787 Nov 29 22:37 search.rdf -rw------- 1 mmokrejs mmokrejs 16384 Nov 29 22:51 secmod.db -rw------- 1 mmokrejs mmokrejs 2048 Nov 29 23:18 urlbarhistory.sqlite -rw------- 1 mmokrejs mmokrejs 119635 Nov 29 22:51 xpti.dat mokrejs@vrapenec$ less .mozilla/seamonkey/oi54tv41.default/bookmarks.html [default, newly created bookmarks] mokrejs@vrapenec$ less .mozilla/default/9o1z0pti.slt/bookmarks.html [my old boomarks contents] mokrejs@vrapenec$ less .mozilla/seamonkey/oi54tv41.default/ .parentlock bookmarks.html cookies.sqlite formhistory.sqlite mailViews.dat search.rdf Cache/ cert8.db extensions/ history.dat mimeTypes.rdf secmod.db Invalid.mfasl chrome/ extensions.cache key3.db panels.rdf urlbarhistory.sqlite XPC.mfasl compatibility.ini extensions.ini localstore.rdf pluginreg.dat xpti.dat XUL.mfasl compreg.dat extensions.rdf lock prefs.js mokrejs@vrapenec$ less .mozilla/seamonkey/oi54tv41.default/ mokrejs@vrapenec$ ls .mozilla/default/9o1z0pti.slt/Mail/ Local Folders a pf-i400.natur.cuni-1.cz primus.gsf.de ribosome.natur.cuni.cz Local Folders.msf mail.natur.cuni.cz pf-i400.natur.cuni.cz ribosome.natur.cuni-1.cz mokrejs@vrapenec$ ls .mozilla/seamonkey/oi54tv41.default/Mail ls: cannot access .mozilla/seamonkey/oi54tv41.default/Mail: No such file or directory mokrejs@vrapenec$ ls .mozilla/seamonkey/oi54tv41.default/ Cache bookmarks.html compreg.dat extensions.ini key3.db mimeTypes.rdf search.rdf Invalid.mfasl cert8.db cookies.sqlite extensions.rdf localstore.rdf panels.rdf secmod.db XPC.mfasl chrome extensions formhistory.sqlite lock pluginreg.dat urlbarhistory.sqlite XUL.mfasl compatibility.ini extensions.cache history.dat mailViews.dat prefs.js xpti.dat mokrejs@vrapenec$ ls .mozilla/default/9o1z0pti.slt/ 75716314.s abook.mab chrome history.dat install.log mailViews.dat panels.rdf search.rdf virtualFolders.dat ImapMail bookmarks.html cookies.txt history.mab key3.db mimeTypes.rdf pgprules.xml secmod.db Mail cert8.db downloads.rdf hostperm.1 localstore.rdf panacea.dat prefs.js training.dat mokrejs@vrapenec$
Martin: this bug is reported for thunderbird. SM has moved around their profile a few times the last couple of months -- what you see it probably a bug in the migration process.
(In reply to comment #3) > I am attempting to report a problem that occurs without any type of crash, > and no corruption of the profile. A power failure is a crash. Really "no corruption of profile"? Because access to profile consists of (A) profiles.ini(registry.dat when Sm 1.x or former) -> (B) Profile Dirctory -> (C) prefs.js -> (D) Files/Directories in Profile Directory, and because account definition is held in (C) prefs.js, both of "loss of whole prefs.js file" and "loss of account definition entries in prefs.js" cause Account Wizard after restart. See Bug 422447 Comment #6 for bugs which can cause the "loss/corruption of prefs.js". (Bug 422447 is Seamonkey version of your bug report.) As I wrote in Bug 422447 Comment #6, Bug 212316 really exists (Product=Moz App Suite, not set to Core yet. It's simply because old bug). I think Bug 212316 can cause prefs.js corruption, because "final update process & final write-back process of prefs.js during non-normal termination" can be interrupted/canceled due to the bug. This is never "Crash", but this situation can be produced by "logoff of user"/"shutdown of OS"/"Kill Tb's process" while Tb is running. I think frequency/probability that problem occurs on single person was reduced very much by other changes. But, even if "probability for a person" is sufficiently low, "probability that problem occurs on some persons in many many persons" is usually not negligible. I guess that this is the reason why "many reports at forums" even though you never met the problem. > I would normally expect the same bug to occur in Firefox or SeaMonkey > since they supposedly share the profile manager code but it doesn't appear > to be a problem with those applications. As I previously wrote, Bug 422447 exists, because Seamonkey has Mail&News component. When Firefox, user's complaint seems to have been "corruption of bookmarks.html". "Update of bookmarks.html" is frequent when Firefox, and impact of "loss of bookmarks.html" for a user is far bigger than impact of "loss of pres.js" when Firefox. And loss of bookmarks.html was probably reported many times even after changes such as "safe file saving" logic. So Mozilla Corporation introduced "bookmarkbackups directory in profile directory of Firefox" and created a feature of Firefox that keeps backup of bookmarks.html on start up of Firefox.
I have had reports of this bug, and also that it could be cured simply by running the Profile Manager and reselecting the default profile. If I recall correctly there may also have been a new default (default + Default?), presumably an empty profile created when the bug was manifested. Whatever the nature of the corruption is, therefore, it isn't enough to cause any obvious permanent information loss following this recovery.
A user report (edited) clarifying the doubled default profile, and providing other clues: The problem seemed to begin when I tried to open an email attachment. I had previously opened this attachment, and I have opened it again since, so it was not a problem with the attachment per se. After double-clicking on the name of the attachment a dialogue box appeared. Just as I clicked on the OK button in the dialogue box I noticed that the name of the document it was trying to open was not the same as the name of the attachment - but too late to stop the process. I have a visual image of the letters imi appearing in the dialogue box, but can't be sure of that. Immediately afterwards, everything went blank. By "blank" I mean that all the listings in the Inbox, which is what I was working on at the time, disappeared, along with the words Inbox, Trash, Unsent Messages, etc. at the left of the screen. When I closed Thunderbird and then reopened it, it put me into a New User sequence. The Profile Manager (then) had "default" and "Default User" options. The "default" one was the right one.
(In reply to comment #14) > The Profile Manager (then) had "default" and "Default User" options. > The "default" one was the right one. This is also an already reported problem. It seems as follows. (1) "default"(only one) is being used (2) "Don't ask at startup"(StartWithLastProfile=1) is somehow set. (I don't know other way than "Don't ask at startup" of Profile Manager's UI) (3) Somehow new profile is created("Default User" in this case), and used, then Default=1 is set in "Default User" entry in profiles.ini. (-CreateProfile XXX won't set Default=1. So I guess it's internally used) (4) Thus, "thunderbird.exe" always starts with "Default User". (5) To recover form it, "thunderbird.exe -p(or -ProfileManager)" is required. Note: Installer/migrator creates "default". Profile Manager's default string of profile creation is "Default User". (Brief summary) There are three kinds of issue, which are already reported by other bugs. (A) Loss of prefs.js file (B) Corruption(partial data) of prefs.js file (C) Doubled default profile (fortunately, not real data loss)
Severity: critical → enhancement
Bug 193638 is meta bug(tracking bug) for lost/corrupted/missing prefs.js. > Bug 193638 corrupt or lost pref.js / startup configuration error (tracking bug) When you find a bug for specific problem, add the bug to Dependency tree for Bug 193638, please.
Blocks: 193638
No longer depends on: 193638
In response to comment #15, note that in the case reported to me (comment #13 and comment #14) there is no indication of corruption or loss of prefs.js, but something causes the (only correct) default profile to become deselected. So under your (C) there is still the possibility of corruption or loss of profiles.ini.
(In reply to comment #17) > there is still the possibility of corruption or loss of profiles.ini. You are right. Bug 205120 really exists for registry.dat case(Mozilla & Fx/Tb 1.0.x used. Seamonky 1.x is using), and someone has closed Bug 451683(Tb 2. profiles.ini case) as DUP of Bug 205120.
(In reply to comment #19) > *** Bug 448785 has been marked as a duplicate of this bug. *** To rsx11m.pub@gmail.com: This bug is not for resolving specific problem. This bug can be called a "pseudo meta bug", because this bug is not a real meta bug(Bug 193638 is the real meta bug for the problems, I think). I believe duping a bug for specific problem to this bug is not appropriate action. What do you think?
WADA, I'm a bit uncertain how to deal with this myself. I agree with Eric that a surprisingly large amount of lost-profile cases are reported in the forums which do not appear to have any specific reason. If you don't want the specific cases to be duped to this more general bug, please feel free to suggest an alternate procedure and we can modify those dupes. I think though that those cases should be kept track of somewhere.
I see. Duping (In reply to comment #21) > WADA, I'm a bit uncertain how to deal with this myself. > I agree with Eric that a surprisingly large amount of lost-profile cases are reported in the forums > which do not appear to have any specific reason. Me too. It's the reason why I continue to post commnet to this bug, and reason why I keep this bug as "pseudo meta bug" status instead of DUPing to other bug. Putting Bug 448785 in Dependency tree for real meta Bug 193638. By the way, I think Bug 448785 is better to be closed as INCOMPLETE, because no response from bug opener. So I close it as INCOMPLETE again, after set dependency.
Thanks and agreed. I proceeded the same way with bug 432438 marked as duplicate here in comment #11, since there was no report back from the reporter either.
Why was the importance reduced to enhancement? Who did it? Why didn't they record that in a comment? I'll try to change it to major.
Severity: enhancement → major
(In reply to comment #24) > Why was the importance reduced to enhancement? Who did it? Why didn't they > record that in a comment? click the history link will show what changed and when > I'll try to change it to major. perhaps it was an accident, wada could say. (ref comment 15, 16, 20) My guess is wada has taken comment 0 to be a general comment about profile loss, and not a report of a specific testcase that can be usefully pursued to a solution. but whether this is a meta bug or not, critical+dataloss is appropriate.
Severity: major → critical
Keywords: dataloss
(In reply to comment #15) > (Brief summary) > There are three kinds of issue, which are already reported by other bugs. > (A) Loss of prefs.js file > (B) Corruption(partial data) of prefs.js file > (C) Doubled default profile (fortunately, not real data loss) wada, what exactly is "doubled default profile"? Do you mean overlaid?
(In reply to comment #12) > (In reply to comment #3) > > I am attempting to report a problem that occurs without any type of crash, > > and no corruption of the profile. A power failure is a crash. > > Really "no corruption of profile"? > > Because access to profile consists of (A) profiles.ini(registry.dat when Sm 1.x > or former) -> (B) Profile Dirctory -> (C) prefs.js -> (D) Files/Directories in > Profile Directory, and because account definition is held in (C) prefs.js, both > of "loss of whole prefs.js file" and "loss of account definition entries in > prefs.js" cause Account Wizard after restart. > See Bug 422447 Comment #6 for bugs which can cause the "loss/corruption of > prefs.js". (Bug 422447 is Seamonkey version of your bug report.) > > As I wrote in Bug 422447 Comment #6, Bug 212316 really exists (Product=Moz App > Suite, not set to Core yet. It's simply because old bug). > I think Bug 212316 can cause prefs.js corruption, because "final update process > & final write-back process of prefs.js during non-normal termination" can be > interrupted/canceled due to the bug. This is never "Crash", but this situation > can be produced by "logoff of user"/"shutdown of OS"/"Kill Tb's process" while > Tb is running. David, Dan, relative to the above comment ... what is your impression of whether 212316 is likely to have any impact on Thunderbird profile dataloss, partial of any kind, or full? And, would clicking windows' "X" instead of usiing file+quit ever cause profile issues? (ref Bug 403837 Closing last window with the window close button does not invoke the shutdown service [but not Mac])
(In reply to comment #26) > wada, what exactly is "doubled default profile"? Do you mean overlaid? No. "default" and "Default User". Installer/migrator creates "default", but default profile name of profile manager is "Default User". It seems that "Default User" is somehow created, and it seems to be a result of internal/accidental -createprofile.
Wayne: it's plausible, but I don't know that code well enough to really say. Perhaps Standard8 or bsmedberg does, though...
OK, Now I am more confused than ever. Thunderbird is pretending that I do not have an account. I learned how to create a new profile, but I did not learn how to -find my old profile- and put those files where they need to be so Thunderbird finds them and opens my account. Is there some kind of place where I can go and learn how to do this step-by-step? And don't send me here: http://kb.mozillazine.org/Profile_Manager#Custom_profile_location because it does not resolve this problem. Thanks..
OK, I followed these instructions: http://kb.mozillazine.org/Moving_your_profile_folder To try to get my Thunderbird program to find my account instead of behaving as though I do not have one and it did not work. I learned how to create a new profile and I learned how to find my old profile folder, but am having trouble making this work. Is there some kind of place where I can go and learn how to do this step-by-step, all in one place? I really have to get into my account or I am going to be in trouble. I think there should be an obvious warning about this sort of thing possibly happening. Thanks..
If it's the actual mail files you want, those and a lot of the other files you can just copy over to the new profile, to the corresponding place. However, this is not a support channel - Thunderbird support forums are here: <http://forums.mozillazine.org/viewforum.php?f=39>
I've found meta Bug 123929. > Bug 123929 (profile-corrupt) Prevent and repair profile corruption (tracking bug)
I found Eudora
perhaps might get resolved by patch in bug 477934 – nsSafeFileOutputStream (prefs.js) not safe from system crashes which landed on 1.9.1 on 2009-05-12
FYI. Bug 420358 is possibly one of causes on Linux and/or in special environment. See Bug 420358 Comment #5 & Bug 420358 Comment #6.
Component: General → Account Manager
QA Contact: general → account-manager
tanstaafl suggests in dev.planning this bug may be going nowhere, and I'm inclined to agree. Rob is the only recent first person report, and there are no steps. There's not enough here to reproduce or shoot, and it's anyone's guess whether the problem is gone. No one's fault, just that second person bug reports often don't have enough info to get results. So I suggest that anyone with a first person report to file a new bug report with just their problem - make it blocking relevant meta bugs: \193638 and/or 123929. => incomplete
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago → 15 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.