In situation when we are running low on free space rewriting prefs.js file leads to corruption of the file (it gets truncated) or total loss of preferences (we get 0KB prefs.js). Safer way to do it would be to move prefs.js to backup file before creating new prefs.js or save the new copy of the prefs to a temporary file in the same directory as prefs.js. If creation of the new file is successful, then rid of the old file.
Am I wrong or is this a dupe of #86501 where exactly this behaviour and solution are described? If then I suggest closing this to get rid of an open bug :)
Not that I'm against dupes :) but bug 86501 references multiple files which are corrupted in this situation. If there were some sort of "safe save" convention in Mozilla, it could potentially be fixed via one bug. If this exists, I'm not aware of it. Since the files in question cross multiple components (bookmarks, for example, is Ben's area) I would leave them both open as the work will probably have to be done per component.
This will be fixed by the patch in bug 98476.
Status: NEW → ASSIGNED
Depends on: 98476
OS: Windows NT → All
Hardware: PC → All
This was fixed by the checkin for bug 98476.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
should this be reopened in light of bug 98476 being reopened?
Re opening as per previous comment.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
nsbeta1+ per ADT triage team
Keywords: nsbeta1 → nsbeta1+
*** Bug 129579 has been marked as a duplicate of this bug. ***
Resolving as duplicate. The exact same symptoms are reported in bug 86501. *** This bug has been marked as a duplicate of 86501 ***
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago → 17 years ago
No longer depends on: 98476
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
*** Bug 142222 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.