Closed Bug 52205 Opened 25 years ago Closed 13 years ago

Bookmarks.html is created read-only - bookmarks aren't saved

Categories

(Core Graveyard :: Profile: BackEnd, defect, P3)

Product:
Core Graveyard
Component:
Profile: BackEnd
Platform:
x86
OS/2
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INVALID
Milestone:
Future

People

(Reporter: jesup, Assigned: ccarlen)

References

Details

(Keywords: dataloss, Whiteboard: [nsbeta3-][rtm-])

FreeBSD 20000910xx pull/build Rename/delete ~/.mozilla Start mozilla (creates ~/.mozilla, ~/.mozilla/default/bookmarks.html, etc) Note that bookmarks.html is read-only - so the browser can't save bookmarks.
Losing bookmarks (or making it impossible to save them) is BAD. nominating for nsbeta3. Probably this is unix-only (might be more though)
Keywords: dataloss, nsbeta3
Note: reassigning to profile backend, since I assume that's what creates the default profile, and I suspect Asa is overloaded.
Assignee: asa → putterman
Component: Browser-General → Profile Manager BackEnd
QA Contact: doronr → gbush
reassigning to browser group.
Assignee: putterman → don
nav triage team: [NEED INFO] not sure if this works the way you think, since Bkmks are actually saved in rdf - this read only file is just for the default (we think) - please confirm that the user truly can not save new bookmarks. This bug might be invalid
Whiteboard: [NEED INFO]
After creating or importing a bookmark(s), the bookmarks.html file remains 0 bytes, (read-only), and I get messages every so often (15 sec) that say it can't open the bookmarks file. If I quit and restart, I have no bookmarks. Opening file bookmarks.html failed BrowserAddBookmark: ISO-8859-1 Opening file bookmarks.html failed Removing [NEED INFO]
Whiteboard: [NEED INFO]
nsbeta3+ if it happens as reported. Claudius, could you try to reproduce?
QA Contact: gbush → claudius
Whiteboard: [nsbeta3+]
Claudius, if this DOES happen on Linux, then make it P1 and re-assign it to mcafee.
Priority: P3 → P2
Claudius, if this DOES happen on Linux, then make it P1 and re-assign it to mcafee.
question: Is the only way to reach this state to manually delete your bookmarks file? Is there another way tha we might reach this state? Although it is MUCH nicer to be robust, surely there are file deletion activities that we won't respond "well" to :-/. For now, I'm pushing this down to P3, and marking PDTP3
Priority: P2 → P3
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP3]
This is not a "delete the bookmarks file", it's a "new profile" bug. I.e. start with no profile (no .mozilla) and let one (.mozilla/default) be created for you, and you can't save bookmarks. This is intensely bad. Please P1 if this is repeatable on Linux as per Don's comment. Adding qawanted
Keywords: qawanted
Nominating for RTM is we can't get this in beta 3.
Keywords: rtm
Whiteboard: [nsbeta3+][PDTP3]
removing nsbeta3+ and PDTP1 for re-evaluation. This bug is absolutely not reproducible on RH6 linux. I tried every conceivable scenario and in no case was I presented with any results leading me to believe my bookmarks weren't being written. As far as Linux is concerned (and Mac and Win for that matter) this bug is a WFM.
Woo hoo! Thanks Claudius! OK, I'm gonna mark this "nsbeta3-" then and re-assign to mcafee, since he's the only person I know who might actually be able to build on FreeBSD. Chris, should we attempt to fix this for RTM? Feel free to mark this "rtm-" if you think not.
Assignee: don → mcafee
Whiteboard: [nsbeta3-]
Eric Pollmann has a freebsd system that other people can use as well. Adding him to the CC list. Contact him to find out how to get to his machine. I think I have an answer. Here's the contents of mozilla/profile/defaults: total 44 drwxr-xr-x 2 jesup jesup 512 Sep 8 13:22 CVS/ -r--r--r-- 1 jesup jesup 66 Sep 5 11:42 MANIFEST -rw-r--r-- 1 jesup jesup 1141 Sep 5 12:01 Makefile -r--r--r-- 1 jesup jesup 1162 Sep 5 11:42 Makefile.in -r--r--r-- 1 jesup jesup 5954 Sep 8 13:22 bookmarks.html -r--r--r-- 1 jesup jesup 2974 Sep 1 17:53 localstore.rdf -r--r--r-- 1 jesup jesup 1187 Sep 5 11:42 makefile.win -r--r--r-- 1 jesup jesup 1218 Aug 8 14:33 mimeTypes.rdf -rw-r--r-- 1 jesup jesup 1764 Jun 6 20:39 panels.rdf -r-xr-xr-x 1 jesup jesup 3456 Jul 2 03:19 search.rdf* Note that (as you'd expect because of CVS) all except Makefile (and for some reason panels.rdf) are read-only. The files mozilla/dist/bin/defaults/profile/* are all symlinks to the above directory.... Comments?
So you're saying this won't be a problem for folks who use the installer or unpack the tarball? Only for those checking out the tree using CVS?
Whiteboard: [nsbeta3-] → [nsbeta3-][NEED INFO]
I believe so - if the installer/tarball versions have the correct permissions. If the tools that take those take them from a dist/bin directory from a build, they might be write protected. This would be a separate issue, however. I'd leave this open but lower priority and list it somewhere as a known bug.
OK, why don't you send this information to the maintainer of the build instructions on mozilla.org (is that dawn?) 'cause this seems most important for developers. Can you also reduce the severity of this sucker from critical to normal?
Assignee: mcafee → don
Whiteboard: [nsbeta3-][NEED INFO] → [nsbeta3-]
-> minor Removing qawanted Adding Dawn to CC list: Dawn, this bug is about creation of bookmarks/etc files from defaults when you use mozilla for the first time from a build (mozilla/dist/bin) directory. ~/.mozilla/bookmarks.html gets created as read-only (under Unix) because mozilla/dist/bin/defaults/profile/bookmarks.html is a link to CVS-controlled source, which is normally read-only. You might want to add something in the Unix build directions to warn people about this (best would be to "chmod o+w mozilla/profile/default/bookmarks.html" I think; then profiles will get created with the correct permissions.) I'm going to double-check that the chmod is a workable workaround as soon as I submit this, and kill and restart mozilla. If there's any problem with it, I'll add another note here - if the chmod works, I won't add anything.
Severity: critical → minor
Keywords: qawanted
Looks like we are inheriting umask for file creation. I can create all sorts of problems for mozilla with a umask of 222, read-only, on linux.
This won't hold up RTM.
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm-]
Target Milestone: --- → Future
On checking the permissions to the variious files under mozilla/profile, we noticed that most of the files here have 664 (rw-rw-r--) permissions set. So, this bug should have been WFM some where since it is filed. Adding Conrad & myself to the cc list.
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy
Assignee: don → vishy
nav triage team: Not a beta stopper, marking nsbeta1-
Keywords: nsbeta1-
I'm pretty sure this bug is fixed since long. I create a new profile several times a day (on Linux), and the bookmark file always has write permissions. With the checkin for bug 86501 there is no longer a dataloss when the bookmark file is read-only, because mozilla sets the write permissions on it automatically. That checkin resolved bug 111782.
Reassigning to a real person.
Assignee: vishy → ccarlen
QA Contact: claudius → ktrina
This happened to me with Mozilla 1.0 on NT4 SP6. With profiles created on a Samba share and even on the local disk.
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: minor → critical
Changing attribute to archive does not fix the problem with Windows 98SE.
Blocks: bookmark-loss
Happens with all Mozillas from at least 1.4 through 1.6b under OS/2 when the Profile is on a Samba share. If the file doesn't exist, it is created, however no further changes will be saved.
*** Bug 216460 has been marked as a duplicate of this bug. ***
does places make this irrelevent?
QA Contact: ktrina → profile-manager-backend
The BSD issue here was with cvs when you had CVSREAD=1 in your environment. We don't use cvs anymore. Since Thomas long ago noted that OS/2 had a bug with this, retargeting the bug as OS/2.
OS: FreeBSD → OS/2
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.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.