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+ The file mentioned in the summary is open for a very long time while Mozilla is running, even though it may not be used often. If Mozilla or the OS crashes (or the computer locks up even on a ultra stable OS), this file may get corrupted. When this happens, data in this file is lost (partly because Mozilla recreates corrupt files from scratch). And users may not able to access their profile (data) anymore. The point of this bug is a request to close the file after each usage. Ideally the file should be closed immediatelly, when the operation is done. For performance, it would be better to close it only after several seconds, but that may be difficult to code. Maybe it can be left on the OS cache to handle the frequent opening and closing of the file. We can try it now in the 1.7 alpha stage. See bug 231606 for further details on the general problem. Reproducible: Always Steps to Reproduce:

After several years of using mozilla i've never had a broken history file. Anyway - isn't the history file used very often? For instance every time the URL changes, or urlbar is used? That file can be pretty big - is it really a gain to close and open it almost continously?

Dup of bug 63292, which has plenty of discussion on this issue already. *** This bug has been marked as a duplicate of 63292 ***

Comment 1: there are many bug filed about lost history. You may be lucky but other are not. You are right that the file may be used often. That's why the mentioned timeout would be useful. But if you don't use Mozilla for 2 hours (but have it open) and you computer crashes, would you take it for normal that your history file gets corrupted? Your history should have been saved, flushed and safe 2 hours ago. Comment 2 supports my claims.

This was filed because of the problems bug 63292 describes, but proposed a solution. Therefore it shouldn't be a duplicate. Anyway, this solution is not needed anymore, because bug 221797 fixed it in a similar way. Closing.