User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040714 MultiZilla/1.6.4.0b Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040714 MultiZilla/1.6.4.0b If bookmarks.html exists but cannot by read by Mozilla (e.g. owned by a different user, no read permissions) then Mozilla currently re-writes a new 'empty' bookmark file in it's place. The result is data loss, as the contents of the original bookmarks file is lost. This has implications when Mozilla is run via sudo to install extensions - a user can lose all bookmarks. Reproducible: Always Steps to Reproduce: 1. Set ownership of non-root user's bookmarks.html to root:root 2. Set permissions to u=rw (600 -rw-------) 3. Run Mozilla as the non-root user Actual Results: bookmarks.html is replaced by 'emtpy' 272 byte file. Any existing bookmarks are lost. Expected Results: If Mozilla fails to read an existing bookmarks.html, then it should not attempt to write a replacement file. Data loss.

your suggestion is fairly looney, you also picked a fairly poor component for this bug. if I can't read bookmarks and proceed to bookmark a bunch of pages, i shouldn't loose my newly bookmarked content just because you did something silly and want to be protected from that. come up w/ a better solution. warning: this requires some user interface design, and you never want to have to do that. stay away from dialogs.

Sigh, I give up. See http://bugzilla.mozilla.org/show_bug.cgi?id=205053#c40

if you install an extension as root with false $HOME ... why the hell will the bookmarks change there owner if already one exists?

(In reply to comment #3) > if you install an extension as root with false $HOME ... why the hell will the > bookmarks change there owner if already one exists? This is explained *at length* here: http://bugzilla.mozilla.org/show_bug.cgi?id=205053#c32 and beyond. Your question is the basis for this bug report. Follow the links, people!

Don't piss on me, explain/help me on following: 1st) When does mozilla change bookmarks.html permission to root (I know on first install as root with false $home it is set to root. I know it seems do it if you upgrade with false $home). 2nd) Does it this also when you start mozilla with false $home? (For example if you update an extension system wide). Is the bookmark on every start recreated? Cause normaly root can read bookmarks.html so no need to change priviliges. And it this happens, then we need first find out, why this happens. But anyway, why the hell someone starts mozilla with false $home directory? If initial read fails, it should recreate bookmarks.html but it shouldn't change owner to root (in this example).

(In reply to comment #5) > 1st) When does mozilla change bookmarks.html permission to root (I know on > first install as root with false $home it is set to root. I know it seems do > it if you upgrade with false $home). If you run Mozilla via 'sudo' (therefore as root but maintaining user environment, including $HOME) then due to the way Mozilla maintains bookmarks.html (rename to backup, create new file) the new bookmarks.html ends up owned by root, since Mozilla is running as UID root at that point. > 2nd) Does it this also when you start mozilla with false $home? (For example > if you update an extension system wide). Is the bookmark on every start > recreated? Cause normaly root can read bookmarks.html so no need to change > priviliges. And it this happens, then we need first find out, why this > happens. It's when you run Mozilla the second time (as non-root user) after running it the first time with 'sudo', that it is unable to read bookmarks.html (since root owns it and it's permissions are u=rw) and it creates a new bookmarks.html with nothing in it. > But anyway, why the hell someone starts mozilla with false $home directory? sudo. > If initial read fails, it should recreate bookmarks.html but it shouldn't > change owner to root (in this example). It's not quite as simple as this - please read my other posts for this bug and the ones referenced.

So the change of bookmarks.html to user root only happens after mozilla installer on the so called first start. --> You should read the installation nodes first. So it haven't to do with installing a new extension system wide cause there isn't mozilla first start not called (IMHO). So the bookmarks.html don't chown to root. And so the bookmarks.html is readable afte you change back to normal user.

Please, can we avoid losing this bug to back-and-forth error propagation like we did 205053? I think a dialog for this case is fine, especially if we defer touching the bookmarks file until we've actually made a change to it. We don't have to give the user a choice, just an alert that says "your bookmarks were unreadable by &product.shortName; we've moved the old file to <path>/bookmarks.save-1.html for your later use". This problem is exacerbated by the fact that we write bookmarks whenever we exit, even if nothing has changed, of course.

If we can't read the bookmarks.html, then we also can't rename/move the file. But that we always resave the bookmarks file on shutdown is the thing I missed.

(In reply to comment #9) >If we can't read the bookmarks.html, then we also can't rename/move the file. At least on Unix, then yes, we can remove an unreadable file.

(In reply to comment #9) > If we can't read the bookmarks.html, then we also can't rename/move the file. As comment #10 mentioned, yes we can remove or rename the file, since the user has write access to the container directory. If the user does not, then the move will fail, but this does not happen with *this* bug.

Changing status to NEW.

(In reply to comment #8) >This problem is exacerbated by the fact that we write bookmarks whenever we >exit, even if nothing has changed, of course. This is fixable, we just need to fix nsBookmarksService::Observe to wrap its calls to Flush() in an if (mDirty) as per FireTimer.

Nominating for blocking-aviary1.0 and blocking1.7.x. Someone was just on IRC saying this happened to them. While I agree that running mozilla as root is not a smart thing to do, it should not delete your bookmarks every time you install an xpi as root.

*** Bug 231792 has been marked as a duplicate of this bug. ***

*** Bug 261185 has been marked as a duplicate of this bug. ***

Yes, I know i duped an older bug to this one, but this one had more information in it than the older one.

Minusing for 1.0; no time to add the dialog UI, and we're already past localization freeze.

This bug seems to be fixed. Can someone please confirm. Using nightly build: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20041212

Ok, I haven't read everything here. Sorry. But here are the results of my experience with the bookmarks.html file using Mozilla 1.4.3 and a workaround: 1.) I tried copying over the bookmarks.html file in the ~/.mozilla/defaults/whatever directory. I also copied the desired bookmarks.html file to ALL bookmarks.html files in any other versions of mozilla on my computer (i.e. /usr/lib/mozilla /usr/lib/mozilla-1.4.3 ......) Every time I reloaded mozilla bookmarks.html in the .mozilla directory was overwritten with the default file. I changed permissions even to r-------- !! it change it back to rw------- and the default file. 2.) Workaround: I simply went to Bookmarks-->Manage Bookmarks... and DELETED every bookmark and folder I could. I also renamed the "personal toolbar" folder to something else ("blah" in my case). Copied over the ./mozilla/../../bookmarks.html file again and this time it wasn't rewritten. The End Sorry again for my newbiness, please feel free to explain to me how I should have made this report. Thanks.

Vlad: Since this missed 1.0 and 1.0.1, any idea if we can get this in for 1.0.2 or 1.1? It seems as if this particular issue is leading to dataloss for many different cases.

See also bug 251692, same bug for Firefox.

No comments in 2½ years. (In reply to comment #22) > See also bug 251692, same bug for Firefox. Firefox 3, and maybe (but it's less certain) SeaMonkey 2, will get a brand-new bookmarks storage system, not in HTML anymore but in sqlite format. If they go their separate ways, the fix to bug 251692 will probably not apply here.

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.