Closed Bug 203343 (bookmark-loss) Opened 21 years ago Closed 12 years ago

[META] Tracking Bookmarks dataloss bugs (Bookmarks gone, lost, corrupted, wiped)

Categories

(SeaMonkey :: Bookmarks & History, defect)

defect
Not set
critical

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: bugzillamozilla, Unassigned)

References

Details

(Keywords: dataloss, meta, Whiteboard: For support, see http://www.mozilla.org/support)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312

Recently, I have witnessed too many cases of users losing their bookmarks (on
various machines and with several versions of Mozilla).

Here's a list of all related bugs that I had managed to find:

Bug 159642 - Lost bookmarks while organizing into folders
Bug 163899 - Empty bookmarks written, if some error in bookmarks file
Bug 193749 - bookmarks and personal preferences are lost after system crash due
to power failure
Bug 164244 - Bookmarks become intermittently corrupted, revert to the defaults.
Bug 109377 - Mozilla fails to detect read-only status of critical files
(bookmarks.html)
Bug 190136 - Full hard drive causes Mozilla to lose its prefs and bookmarks
Bug 52205 - Bookmarks.html is created read-only - bookmarks aren't saved
Bug 131105 - crash causes loss of bookmarks added during current session
Bug 193749 - bookmarks and personal preferences are lost after system crash due
to power failure

Unconfirmed bugs:

Bug 200217 - Browser Window insisted I upgrade to version 1.3 from 1.3a. Upon
completion all bookmarks, mail , and mail settings are gone.
Bug 199050 - bookmarks lost on restart
Bug 188401 - newly added bookmarks will not save (ie. they are not there when
browser is reopened.)
Bug 193963 - large bookmarks.html file wiped out after crash
Bug 201027 - bookmarks disappeared without any prior problem over the weekend
Bug 149022 - Dragging proxy icon onto bookmarks icon causes bookmark to diappear.
Bug 166358 - Painfully slow file saves and loss of bookmarks when Netscape 7.0
is present

Just fixed for 1.3.1:

Bug 196834 - all bookmarks lost when using "browser.bookmarks.file" pref and
switching profile

As Andrew Hagen (xah@myrealbox.com) suggested to me in email, this bug should
include any/all bookmarks bugs from Bug 123929. It should then block 123929.

Prog.

Reproducible: Sometimes

Steps to Reproduce:
Confirming.
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: dataloss, meta
No longer blocks: profile-corrupt
I added some other ones, too.
Bug 190136 was duped to bug 192425.  Replacing in depends.
Depends on: 192425
No longer depends on: 190136
Depends on: 176131
Depends on: 192011
I'm not sure, but I think bug 159642 was fixed when pch's robust bookmark
handling landed.
Bug 44507 has nothing to do with bookmarks.  Removing depend.

If this was a typo, please check which bug you intended to add.
No longer depends on: 44507
Depends on: 44057
8 users here are experiencing the 'vanishing bookmarks.html' consistantly and
reproducibly.  

OS: MacOS X 10.2.[3|5|6] (same behaviour on all, currently using .6)
Hardware:  G4 Dual 1.25GHz w/1.75G RAM, PowerBook 12" w/867M RAM (several of each)
Third-party UI shareware hacks: NONE

Mozilla Version:  The G4 workstations have home directories and other volumes
NFS-mounted.  The PowerBooks have local (HFS+) home directories.  I've been
testing Conrad's patches in bug 196487 since April, so I build & patch almost
nightly out of CVS so that Mozilla works on NFS. My .mozconfig for building is
as follows:
ac_add_options --enable-ldap-experimental
ac_add_options --enable-prebinding
ac_add_options --enable-crypto
ac_add_options --enable-extensions=all
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --enable-optimize=-O2
ac_add_options --without-system-nspr
ac_add_options --without-system-zlib
ac_add_options --without-system-jpeg
ac_add_options --without-system-png
ac_add_options --without-system-mng
ac_add_options --disable-shared
ac_add_options --enable-static

Steps to reproduce with the profile on an NFS home directory:

1.  Launch Mozilla & Check bookmarks menu - it's empty.  
2.  Look in <whatever>.slt - no bookmarks.html
3.  Add a bookmark.
4.  Quit Mozilla.
5.  Look in <whatever>.slt - no bookmarks.html

OR

1. Launch - no bookmarks.html
2. Add a bookmark - no bookmarks.html
3. Close Navigator window without quitting Mozilla - bookmarks.html appears
4. Open Navigator window - bookmarks.html DISAPPEARS
5. Close Navigator window - bookmarks.html appears again
6. Quit Mozilla - bookmarks.html DISAPPEARS (again)

...and so on.  In some cases, the bookmarks.html file may not be 'eaten' on
close for one or two times, but within 5 sequential launch/quit/launch/quit/etc.
it WILL be eaten.

Steps to reproduce with the profile on an HFS+ home directory:
Unable to provoke or reproduce in this configuration (same machine)


Also, Personal Toolbar Folder functionality is lost when a new bookmarks.html is
created or a backup bookmarks.html file is used.  Even if the folder is created
and named appropriately, it doesn't function as intended.  There is no option in
any menu (right-click or otherwise) to 'set' a folder as the PT.

I believe bookmarks dataloss should block 1.4.

Thanks for your help.  I'm willing to test any patches, please contact me
directly for that.


Flags: blocking1.4?
This is still consistant and repeatable as of the 19 June RC_3 build.  Please,
please consider this critical enough to block 1.4 (the new icons are nice, but
this is serious...)   It only occurs with profiles on NFS home directories.

I'm willing to work with you to test any patches at my site.  Thanks,
The following bugs appear to be related, but are not listed in the 'depends' above:

203583
204581
205053
205200
205231
205591
205664
209975
210661
210856
211050

...and there doesn't seem to be any activity on any of them.  I can confirm that
it's happened with CVS since at least 9 May, RC[1|2|3] and 1.4-final.  I have at
least 8 users here experiencing the problem.  
Flags: blocking1.5a?
Flags: blocking1.4?
Flags: blocking1.4.x?
metabugs don't block releases.
Flags: blocking1.5a?
Flags: blocking1.5a-
Flags: blocking1.4.x?
Flags: blocking1.4.x-
Happens quite randomly over here, 20030425
I believe the bug 221037 "Dataloss:Bookmarks will sometimes (but not always)
disappear when Mozilla is launched." should be included in this meta bug.
Anybody can add dependencies.  But since nobody else can seem to be bothered,
I'm going to add the ones that people seem to be talking about but not adding to
the list:

Bug 203583 - bookmarks.html suddenly has zero size
Bug 204581 - lost bookmarks. system did not crash.
Bug 205053 - Bookmarks lost when installing Mozilla 1.4b
Bug 205200 - When installing Mozilla 1.4b, all my bookmarks were lost. Never saw
this with other Mozilla-install's!
Bug 205231 - Bookmarks lost when I upgraded to 1.31
Bug 205591 - Upon upgrading to this build, all my bookmarks were deleted, except
for one small subset of a personal directory entry.
Bug 209975 - mozilla1.4 rc2 deleted my bookmarks!
Bug 210661 - I've been using Mozilla mail for weeks. TodayI had to set up my
mail account, lost all existing mail , lost all bookmarksBug 210856 - Data loss:
Bookmarks are missing!
Bug 211050 - After updating all my bookmarks were erased
Bug 221037 - Dataloss:Bookmarks will sometimes (but not always) disappear when
Mozilla is launched.

Not sure how many of the various "bookmark file updated OK, but disappeared out
of the blue on restart" and "bookmarks lost when I upgrade" bugs should count as
dupes of each other....

And by the way, although comment 8 mentions it, bug 205664 has nothing to do
with bookmark dataloss AFAICS.
Adding a 'me too' to the pile. Using MacOS 10.1.5 and Mozilla 1.5 Release.
Bug 223384 - Bookmarks file overwriten when running Mozilla 1.5 for the first time.

Yet another case of bookmarks lost on upgrade.  We have seven now:
- Linux - bug 205053, bug 205200, bug 209975, bug 223384
- Windows - bug 205231, bug 205591, bug 211050

Not sure if some of these should be dupes....
Alias: bookmark-loss
Depends on: 223384
A BRUTE FORCE APPROACH:

The problem of losing all bookmarks has been around and unsolved for a long time
(I didn't know about it until it happened to me with 1.3, and I haven't used
Mozilla since). Since it is obviously difficult to fix (or reproduce),I wish
someone would at least code a repair routine for when it happens. Possibilities:

Simplest: Automatically maintain a running backup of the bookmarks file (perhaps
even two generations of it), and in an FAQ/Help file, instruct the user where to
go to retrieve that backup if he discovers that his bookmarks have disappeared.

Better: Include a "Restore lost bookmarks" item in the Bookmarks menu, which
will reconstruct the bookmark menu from an automatically maintained backup
(after presenting an explanation dialog).

Better still: Have the program check to see if it is displaying the default
Bookmarks menu, and if it is, and there is a backup file indicating that there
used to be user bookmarks there, automatically rebuild the menu.

In all cases, it would be best if the backup file were copied/updated after
every change to the "real" file (whether add, remove, move, or rename), but for
now, even a backup after each add function (or after every so many minutes)
would go a long way,

IMO, releasing a non-alpha program with a known bug that causes the user to
irretrievably lose data is unacceptable. Creating a way to un-do the damage
(until such time as the underlying bug is actually found, if ever) I think
should be a very high priority, and is necessary to make the product "fit for
public consumption".
Good idea, I reckon.  Feel free to file a new bug report to suggest this.  But a
few more notes I'll say here before I forget....

I reckon the "better still" is particularly important.  Otherwise someone might
start Mozilla, go to a site and bookmark it by pressing Ctrl+D/Cmd+D, remaining
unaware that all his/her bookmarks from the last session have vanished.  Then
the backup would be overwritten again.

I'm also inclined that there should be a backup of the bookmarks at the
beginning of the session, not just after each operation.
No longer depends on: 193963
Summary: Meta bug for tracking Bookmarks dataloss bugs (Bookmarks gone, lost, corrupted, wiped) → [META] Tracking Bookmarks dataloss bugs (Bookmarks gone, lost, corrupted, wiped)
Depends on: 221843
Adding 227331 - Abnormal shutdown truncates (large) bookmarks.html
Depends on: 227331
Depends on: 222339, 227258, 227968
No longer depends on: 227968
Hi,

I have lost my bookmarks several times as well. I also lost history and
cookies... It happens when mozilla is running and the computer crashes. I am
under windows2000 professional and mozilla is 1.4 or 1.5. I usually don't swich
of the computer, it seems the computer crashes when mozilla has been running for
a long time or when I have been very active on the net. I shall try to close
mozilla on a regular base to see if that change anything.

Florent
Removing all the bugs that are marked DUPLICATE from the depend list. 
These were bug 203583, bug 205200, bug 205231, bug 209975, bug 211050, bug
221037, bug 222339, bug 223384
No longer depends on: 203583, 205200, 205231, 209975, 211050, 221037, 222339, 223384
The error always still exists in Mozilla 1.6.
All of my bookmarks simply disappeared without any reason. I can't even get the
bookmark toolbar to function correctly.
John, to get help in resolving this problem try
http://www.mozilla.org/support#community

Prog.
Whiteboard: For support, see http://www.mozilla.org/support
I tried posting previously the following, but it seems not to have showed up. 
--------------------------------------------------------------
I still maintain, and have complained several times in the newsgroups, that moz
bookmark function has multiple problems that go *backward* from NS 4.8.  In one
of these messages [news://news.mozilla.org:119/c1dfup$fgl2@ripley.netscape.com],
I indicated the following bookmark-specific items:  "Other items that went
backward from NS 4.x include removal of 'insert separator' from the right-click
context menu in bookmarks manager, the scrolling format of bookmarks in a large
file, vs. the multi-column wide view [*much* superior, IMO],".  In a later post,
someone else wrote:  "I also have accumulated a large bookmarks file, and really
miss Netscape 4's ability to search (find) withIN the bookmarks window -- IOW
just advance to and select the (next) matching bookmark within the (context of
all the) other bookmarks. "  I also agree with this assessment.  Finally, in a
yet later article [news://news.mozilla.org:119/c2au3h$ga23@ripley.netscape.com]
I indicated some additional problems: "1.    Even for  the toolbar folders into
which I can drag/drop links, the list will not scroll, so I am limited to only
the range that comes up by default.  Also, what I consider the backward movement
to the scrolling bookmarks [vs. multi-column format] also impacts this negatively.

2.    I cannot drag/drop links into the pulldown-menu bookmarks list at all. " 
These last 2 issue, though, seemingly are sporadic; occasionally [but not
usually] they seem to work.  FWIW, moz 1.6/win2k[fully patched].  

Sorry if these issues duplicate, but my initial search did not show them on
here.  I resisted going bugzilla, but finally got fed up and had to provide
$.02.  Thanks.
That complaint does not seem relevant to this bug. 
(In reply to comment #24)
> That complaint does not seem relevant to this bug. 

I disagree.  The bottom line problem is that the bookmarks file is not writing itself correctly.  This is the most closely related bug I could find; if you start shunting off this type of report as not related, then you open yourself to tons of new bug reports that, IMO, seem rather likely to have a common problem with this one.  

(In reply to comment #25)
> (In reply to comment #24)
> > That complaint does not seem relevant to this bug. 
> 
> I disagree.  []eports that, IMO, seem rather likely to have a common problem with this one.  
> 
> 

I should modify my reply; yes, what I posted here is more marginal to this particular issue.  Sorry for adding any confusion.  More useful would have been to reference *this* post:

news://news.mozilla.org:119/c75tqi$n591@ripley.netscape.com

and my follow up:

news://news.mozilla.org:119/c7ohh6$icn1@ripley.netscape.com

Bottom line I *intended* to convey:  bookmarks file is not saving itself correctly, leading to losses of new URLs whether closed normally or crashed.  

Sorry for adding confusion.  


Another way to lose your bookmarks

If you run mozilla via sudo (for example when installing system-wide extensions
like multizilla), mozilla sets the ownership of the bookmarks.html file to
root:root. The next time you start mozilla as the same user who ran 'sudo',
mozilla tries to open bookmarks.html, but because it's owned by root, the file
is not readable. Instead the file is truncated to zero bytes (because the normal
user has write access to the directory - can write and delete and therefore
truncate but cannot read this file) and you lose all your bookmarks.

If you run mozilla via sudo, you *must* change the ownership of bookmarks.html
back (or make sure it has o=rw permissions) before running mozilla again as your
normal user.

I think the fact that mozilla seems to place the bookmarks.html file in such
jeopardy is bad.
David Antliff, the problem you've described in comment #27 warrants a separate
bug report. Please open a new bug and mark it as blocking this one.

Prog.
(In reply to comment #28)
> David Antliff, the problem you've described in comment #27 warrants a separate
> bug report. Please open a new bug and mark it as blocking this one.

I performed a search and found bugs 212447 and 205053 that already cover this,
however for older versions of mozilla. The bug is still present in 1.6 (linux).
Well, bug 212447 is a dupe, and bug 205053 is already listed here, so the bug
reporting is taken care of.

A bug report applies from the version in which it is reported to the version in
which it is resolved.  If each bug were re-filed for every version, the database
would grow beyond usability.
Flags: blocking1.7+
Clearing the 1.7+ blocker flag set by "j" a.k.a. 0py4obm02@sneakemail.com.

J: Only Mozilla DRIVERS can set blocking flags. You can REQUEST that a driver
considers this bug for blocking by setting it to "?".
Flags: blocking1.7+
In this case, there no point to request blocking at all, as "metabugs don't
block releases." (see comment #9).

Prog.
(In reply to comment #31)
> Clearing the 1.7+ blocker flag set by "j" a.k.a. 0py4obm02@sneakemail.com.
> 
> J: Only Mozilla DRIVERS can set blocking flags. You can REQUEST that a driver
> considers this bug for blocking by setting it to "?".


OK, sorry, that was my intention.
Flags: blocking1.7?
(In reply to comment #32)
> In this case, there no point to request blocking at all, as "metabugs don't
> block releases." (see comment #9).
> 
> Prog.



That's real helpful, repeating a previous, non-elaborative comment.  Those of us
without the time to help develop are trying to help with comments, yet you seem
to trap these responses in a permanent loop.  

OK, then:

1) How about explain what the **** is a 'metabug', and why this is one?  Search
of mozilla site gave 3 non-explanatory references.  Essentially the same results
from >15 online references. 

2)  WHY NOT???  This is simply a CRITICAL problem, and everything I see suggests
you continue trying to AVOID it rather than ADDRESS it!!!



To simplify the concept of metabugs, think about them as a folder in your
bookmarks. These bugs are just pointers to help track other ("real") bugs. Just
follow the "depends" list above, and vote for the bugs you feel are most important. 

As for the Blocking flag, there's really no use in messing with it, unless a bug
has a patch. This bug doesn't (and won't naturally), which is another fine
reason to leave that flag alone.

I suggest that you read 
http://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Prog.
Flags: blocking1.7?
Depends on: 251456
How the hell can this *all-OS* bug 'depend' on a linux-specific bug [251456]???
It's simple.  For a bug to be fixed on all OSs, it must be fixed on Linux, and
for it to be fixed on Linux, the Linux-specific bug on which it depends must be
fixed.

OK, so this is a tracker.  But a similar logic applies.  A tracker cannot be
singled out as applying to a single operating system, unless its purpose is to
track failings of some kind specific to one OS (e.g. bug 12985).  And so the OS
is specified as All.  This doesn't mean that it's exclusively to track
cross-platform bugs, simply that it can track bugs regardless of the OS on which
they occur.
(In reply to comment #37)
> It's simple.  For a bug to be fixed on all OSs, it must be fixed on Linux, and
> for it to be fixed on Linux, the Linux-specific bug on which it depends must be
> fixed.[]

OK, gotcha.  Thanks.  
Lack of clarity on Profile Manager, and the ill-designed manner through which
Profile Manager is accessible, have teamed to kill my bookmarks.
The profile manager is accessible through "firefox.exe -p". However, it won't
work if any FireFox window is open. the "-p" is ignored. The most acessible way
to run that command ("firefox.exe -p") is to alter the QuickLaunch (or desktop)
shortcut. So I ended up with "-p" on my QuickLaunch shortcut.
Now the Profile Manager opened each time I launched afresh FireFox.This wan't
obviuos because it only shows when launching a fresh copy while no other window
is opened. What's worse: What seems to be an action of choosing a profile is
actually Creating a new profile: so my bookmarks were erased time after time.
True, all this would not have happened had I been more cautious or less tired.
Still I think this is a bad design: The profile manager must be accessible in a
more sensible way, and it's interface more clear.
(In reply to comment #0)

Here is another one that I currently have to deal with on a sort of monthly basis:

114824 - Personal toolbar icons are lost when mozilla is killed (or crashes)

...very annoying.
Anyone can add dependencies.  But I'm not sure that this one counts - what's the
consensus?  Should losing the icon images fall under bookmark dataloss?
Product: Browser → Seamonkey
I've got a computer that's losing bookmarks under Mozilla and Firefox.  This is
the first time I've experienced this ever.  Mozilla 1.8a3 and Firefox 1.0 are
both doing similar things.  Mozilla won't let bookmarks be created in the
personal toolbar, but it hasn't lost the other bookmarks.  Firefox has lost all
of the bookmarks.  We put Firefox on thinking it might solve the problem, but no
luck.  Other than backinup the bookmarks file periodically is here any
suggestion for avoiding the problems or diagnosing what's going on?
Flags: blocking1.7.5?
1.7.5 has shipped. Moving request to 1.7.6.
Flags: blocking1.7.5? → blocking1.7.6?
jlrodriguez@terra.es, meta bugs don't block releases. More here:
https://bugzilla.mozilla.org/show_bug.cgi?id=203343#c35

Prog.
Flags: blocking1.7.6?
This is in addition to bug#193916 where I lost my mail files and connection to
my email provider.
My Bookmarks were cut off, coincidental with the NEW version (with prominent
GOOGLE entry box).  It COULD have happened also coincident with a system
hang/crash (XP Pro up-to-date) - APPEARS to have lost everything after the
Bookmark folder I had JUST added a Bookmark to. THAT Bookmark is preserved...the
next Folder and all after are gone!
I just had this happen to me two days ago on my Win XP box. Everything was fine
when I shut down the machine. Next morning I turn it on and login, suddenly
Firefox has no bookmarks and won't remember window formatting. Every time I
restart it the window is tall and thin.

I was running 1.5 beta 2 and have since uninstalled and reinstalled RC1 and the
problem persists.
After the computer crash, the bookmark still has a similar size to the size it had before the crash. However it is unreadable, even by Mozilla.
I am reproducing the bug systematicaly.
I have a problem with my graphic card driver, and each time I close firefox with an applet loaded, my computer crashes. Next time I start mozilla, I have no bookmark and my preferences are lost. Looking at the bookmark.html file, it has the same size than the last one, but it can't be opend since it seems to be a binarry file (see attachement).
After closing and restarting Mozilla, the bookmark file is valid but empty, its size is <1k

Tell me if I can help and give you more data. I have some developper knowledge...
Forgot...

I am running mozilla 1.0.7 on windows XP sp2, on an NTFS partition.
This is a tracker.  If you want to discuss a specific bug, how about doing so under that bug's page?
Assignee: bugs → nobody
QA Contact: chrispetersen → bookmarks
All of my bookmarks mysteriously disappeared. Don't know when it happened, but it did.
Depends on: 226720
Mozilla automatically updated to Firefox 10 and bookmarks are gone. Haven't restarted Firefox on other computer for fear of same thing happening when it installs update.
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: --- → INCOMPLETE
No longer depends on: 193749
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: