Closed Bug 231606 Opened 21 years ago Closed 8 years ago

Mozilla keeps profile files open all the time (are not closed and therefore lost on a crash)

Categories

(Core Graveyard :: Tracking, defect)

Product:
Core Graveyard
Component:
Tracking
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: aceman, Assigned: chofmann)

References

(Depends on 1 open bug)

Details

(Keywords: dataloss, meta)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031216 Firebird/0.7+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031216 Firebird/0.7+ Many of the problems reported in bugs about corrupted profiles are caused by files kept open by Mozilla, when the OS crashes. I don't know why Mozilla does this. Files like history.dat, *.msf, *.db are always open. This probably means they are not flushed after each write. They are not in a consistent state after an OS crash. On boot, they are often truncated to zero (or scandisk fixes them this way). I lost my panacea.dat with 1.5 during a complete computer freeze. I lose *.msf files permanently, but fortunately, these can be recreated. I think all files should be closed after each write to prevent these problems. Yes, it would be slower, but safer. Mozilla is the only program that has problems with Windows crashes here. That is sad. Here is a list of files |Handle| |Name| |File Pos||Full Path| 1C : mozlog-2004-01-19-19_18_07 334 058 C:\WINDOWS\Profiles\aceman\Application Data\Mozilla\mozlog-2004-01-19-19_18_07 74 : index.dat 0 C:\WINDOWS\Temporary Internet Files\Content.IE5\index.dat 80 : index.dat 0 C:\WINDOWS\Profiles\aceman\Cookies\index.dat 8C : index.dat 0 C:\WINDOWS\Profiles\aceman\History\History.IE5\index.dat BC : parent.lock 0 F:\Mozilla\Profiles\aceman\xxxxxxxx.slt\parent.lock E4 : cert8.db 32 768 F:\Mozilla\Profiles\aceman\xxxxxxxx.slt\cert8.db F8 : en-US.jar 745 912 C:\Program Files\Mozilla\chrome\en-US.jar FC : modern.jar 590 837 C:\Program Files\Mozilla\chrome\modern.jar 100 : toolkit.jar 221 412 C:\Program Files\Mozilla\chrome\toolkit.jar 104 : comm.jar 969 319 C:\Program Files\Mozilla\chrome\comm.jar 108 : MESSENGER.JAR 540 359 C:\Program Files\Mozilla\chrome\MESSENGER.JAR 10C : US.jar 22 571 C:\Program Files\Mozilla\chrome\US.jar 110 : history.mab 19 313 F:\Mozilla\Profiles\aceman\xxxxxxxx.slt\history.mab 114 : CHATZILLA.JAR 185 852 C:\Program Files\Mozilla\chrome\CHATZILLA.JAR 118 : en-win.jar 7 329 C:\Program Files\Mozilla\chrome\en-win.jar 11C : panacea.dat 36 205 F:\Mozilla\Profiles\aceman\xxxxxxxx.slt\panacea.dat 124 : key3.db 12 288 F:\Mozilla\Profiles\aceman\xxxxxxxx.slt\key3.db 148 : Local Folders.msf 0 C:\Email\Local Folders.msf 160 : abook.mab 11 158 F:\Mozilla\Profiles\aceman\xxxxxxxx.slt\abook.mab 168 : filterlog.html 250 074 F:\Email\pop3.server.sk\filterlog.html 190 : junklog.html 33 599 F:\Email\pop3.server.sk\junklog.html The .jar files are probably safe, because they are not written to. But all others can be corrupted on a crash. Look at IE. It has only its history, cache and cookie indexes open all the time. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Keywords: dataloss, meta
OS: Windows 2000 → All
Hardware: PC → All
Blocks: profile-corrupt
Depends on: 193749, 230450
Depends on: 205120
Not a networking issue; the consumers need to close files as needed. This should be split up into one bug per file involved, since the code belongs to different components.
Assignee: darin → chofmann
Component: Networking: File → Tracking
QA Contact: benc → chofmann
Confirming. This metabug tracks bugs where we keep profile files open too long. Additional bugs could be opened. Each bug would specify a profile file that is kept open longer than necessary, and under what conditions. Each such bug would block this bug.
Status: UNCONFIRMED → NEW
No longer depends on: 193749, 205120, 230450
Ever confirmed: true
Confirming. This metabug tracks bugs where we keep profile files open too long. Additional bugs could be opened. Each bug would specify a profile file that is kept open longer than necessary, and under what conditions. Each such bug would block this bug.
Depends on: 193749, 205120
Those bugs probably exists but their reporters may not be aware that some open file is the cause of their problem. Should we find them, or create specific bugs saying "Close file ______ after write" ?
I would create specific bugs. As Boris said, those specific bugs belong to the component where the problem arises. If global history vanishes after a crash, that would prove consistent with the global history component keeping the history.dat file open too long. We could then file a bug describing as much,. The summary of the bug could be "Close ___ file after write" or some variation on that. When the developer looks at the bug, he can look at the appropriate code and figure out in detail how the problem manifests itself.
Depends on: 231919
Depends on: 231921
Depends on: 231923
Depends on: 231924
Depends on: 231938
Bug 221797 might be the solution, that helps us all.
Depends on: 221797
No longer depends on: 231938
Depends on: 231938
I still didn't get my hands on 1.6. Did anybody test this bug in it so far? I just have a Firebird based on 1.7a which doesn't seem any slow or thrashing the disk due to the new approach from Bug 221797.
I now got 1.6 and am testing it. I have already seen the effects of the fix for bug 221797. It is nice. The problem this tries to solve is mostly apparent in Win9x and other OSes on a FAT filesystem. Could somebody else try it? Then we can close the dependent bugs it obsoletes - the patch doesn't do exactly what is requested here, but solves the same problem in a similar (maybe better) way.
I made some tests in MailNews. I created some new folders, moved messages, moved focu/selection of folders. After about 3 seconds (so that Win9x has time to flush files to disk), I hit cold reboot. NO MOZILLA FILES WERE REPORTED BY SCANDISK (others were - in lost clusters). I also checked the profile forder by hand to look for errors (empty files, mork db files without tails, etc.). Everything seemed ok. Then I started Moz and checked the accounts. Everything was fine. No ??? as folder sizes, no rebuilds of msf files. Great :) Could someone confirm this? Someone should stop this monologue :)
Blocks: failsafe
What about C fflush, C++ std::ostream::flush or whatever fits however Mozilla works in this respect?
Recently, I have been hit by this bug too during the last few weeks, running WinXP SP1 with successive trunk nightlies each day. The bug started for me around 20040609, but I can't verify that. Mozilla would hang (meaning, Moz would take 10-20 minutes to "process" new mail after an initial start of the program and downloading new messages off the server). Mozilla would also hang (again, taking 10-20 minutes to close completely and release the parent.lock file) after closing the program. During the "hangs," Mozilla would eat 90-99% of system resources and make the whole system sluggish or unresponsive. Simply waiting until Moz or the OS was finished with the process would return the system's responsiveness. Just today I discovered that renaming junklog.html to junklog.old solved my problem. Moz and/or the OS remains responsive once again after downloading mail and after closing the program. I do not have filter logging enabled, so my filterlog.html file is 0kb. My (old) junklog file is 11,791kb. I would be happy to zip my old (corrupted?) junklog and mail it to anyone if it could help resolve this issue for others.
comment 10: Yes, that's the approach in bug 221797. The solution must not cause slowness or disk thrashing and must cause FAT filesystem to update the filesize so that it is visible to external programs while Mozilla is running. comment 11: this may be bug 231923, and I have replied to you there.
I notice if I click a url in gnome-terminal when I already have a browser open, gnome-terminal tries to open a new browser and I get a dialog complaining that my profile is already in use. This is Moz 1.7 and Red Hat 9 GNU/Linux. Is this the same bug? I don't see this happen with Firefox 1.0pre and Fedora Core 3.
That is completelly unrelated. You try to open 2 instances of firefox on 1 profile. This bug says, that 1 instance opens profile files and keeps them open until the program is closed.
Blocks: 239282
Depends on: 723248
Marking all tracking bugs which haven't been updated since 2014 as INCOMPLETE. If this bug is still relevant, please reopen it and move it into a bugzilla component related to the work being tracked. The Core: Tracking component will no longer be used.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.