Mozilla fails to detect read-only status of critical files (bookmarks.html)

RESOLVED WORKSFORME

Status

--
critical
RESOLVED WORKSFORME
17 years ago
7 years ago

People

(Reporter: brentboyer, Unassigned)

Tracking

({dataloss, helpwanted})

Trunk
dataloss, helpwanted
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
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.

Comment 1

17 years ago
->apps.
Assignee: asa → pchen
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps
Ever confirmed: true
Keywords: dataloss
QA Contact: doronr → sairuh

Comment 2

17 years ago
->file handling, future/helpwanted
Assignee: pchen → law
Component: XP Apps → File Handling
Keywords: helpwanted
Target Milestone: --- → Future
QA Contact: sairuh → petersen

Comment 3

16 years ago
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.
Severity: normal → critical
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.
Assignee: law → ben
Component: File Handling → Bookmarks
QA Contact: petersen → claudius
Summary: Mozilla fails to detect read-only status of critical files → Mozilla fails to detect read-only status of critical files (bookmarks.html)
Target Milestone: Future → ---

Updated

16 years ago
Blocks: 123929

Updated

16 years ago
Blocks: 203343
Product: Browser → Seamonkey

Comment 5

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

Comment 6

12 years ago
Or well, at least worked on.
Assignee: bugs → nobody
QA Contact: claudius → bookmarks
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.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 257288
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
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 9

10 years ago
(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.
Status: REOPENED → NEW

Updated

10 years ago
No longer blocks: 123929

Comment 10

10 years ago
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.

Comment 11

7 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 10 years ago7 years ago
Resolution: --- → INCOMPLETE

Comment 12

7 years ago
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.

Comment 13

7 years ago
Thanks. Setting resolution to WFM since this is more specific than 257288.
Resolution: INCOMPLETE → WORKSFORME

Updated

7 years ago
Depends on: 257288
You need to log in before you can comment on or make changes to this bug.