There are several files that Mozilla uses to store information that often need to be updated. For example, your bookmarks.html file is likely to get updated very often. If somehow a file in this category gets marked as read-only -- and this could easily be thru some agent OTHER than Mozilla -- then changes that Mozilla would like to make to file will not hold, and this is a bug. For instance, if the bookmarks.html file gets marked by the Operating System as read-only, then Mozilla will happily let the user add new bookmarks, and they appear on the drop down list while the program is still running, but when you quit the program and later restart it they are GONE! This is very dismaying for the user!!! Here is how the problem arose with me: I saved my bookmarks.html file to a burned cd disk (as part of a backup since I was totally reformatting my drive as part of an OS upgrade), and for some bizarre reason, the cd burner program marked my bookmarks.html file as read-only unbeknownst to me. When I attempted to use that file with Mozilla later on, it was not preserving new additions as described above. It took me a while to figure out the problem, and I confess I was cussing at you guys for a bit till I realized that it was sorta my fault. What Mozilla OUGHT to do is to detect whether or not a file that it needs to modify has been accidentally set to read-only. If Moz can change it's status, then it should do so, but if it can't, should at least warn the user so that the user can go in and modify it's status.

->apps.

->file handling, future/helpwanted

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.

This has nothing to do with file handling; the bookmarks.html-munging code lives completely in bookmarks. If other files have similar problems, file separate bugs on them, please.... Note that people commonly mark such files as read-only precisely to prevent Mozilla from mucking with them; just changing the permissions should not be done under any circumstances.

Sounds like this have been fixed for ff in bug 257288.

Or well, at least worked on.

In reply to comment #5 and comment #6: bug 257288 is a Core bug so it ought to apply to both Fx & Sm; however it is not clear to me whether that bug and this one are for the same issue -- and if yes, which one should be duped to the other.

S**t -- I thought it was a dupe, then on closer look wasn't sure but forgor to clear the dupe. Set it again (but in which direction?) if it really is one

(In reply to comment #0) > What Mozilla OUGHT to do is to detect whether or not a file that it > needs to modify has been accidentally set to read-only. If Moz can > change it's status, then it should do so, but if it can't, should > at least warn the user so that the user can go in and modify it's > status. Mozilla absolutely must not alter the read-only status of the file. Chances are it hasn't been _accidentally_ set to read-only. The whole point of making a file read-only is to prevent accidental changes; it is the job of every application to honour this. Here's how it should behave. The first time in a session that the user tries to add a bookmark, if the bookmarks file is read-only, it would display a warning message The file bookmarks.html is read-only. Therefore, bookmarks will not be saved. Even better, on exit it would prompt the user to save the bookmarks to a new file.

I haven't tried locking places.sqlite, but 3.0.x detects my cookies.sqlite permissions, it just doesn't communicate to the user that changes won't be saved. (It also doesn't use read-only data, but that seems to be bug 257288 ). I think the solution is the dialog box. If places.sqlite is locked, attempting to bookmark a page should throw up a dialog. If cookies.sqlite is locked and FF preferences are set to save cookies, the first page of a session that writes a cookie should throw up a dialog. Etc. I agree that FF must not alter file permissions.

This bug concerns the old bookmarks.html code in XPFE. Both Firefox and SeaMonkey have been using the (new) Places implementation for some time now. Closing this obsolete bug. Please file *new* bugs in the Toolkit/Places component for any current issues.

This is a duplicate of bug #257288. Although that bug report is still open, my recent experience with read-only files in my profiles indicates it has been fixed.

Thanks. Setting resolution to WFM since this is more specific than 257288.