Closed Bug 52205 Opened 24 years ago Closed 12 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: 12 years ago
Resolution: --- → INVALID
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.