Closed Bug 105883 Opened 24 years ago Closed 23 years ago

Manage Bookmarks data loss

Categories

(SeaMonkey :: Bookmarks & History, defect)

Product:
SeaMonkey
Component:
Bookmarks & History
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: grantbow, Assigned: bugs)

Details

(Keywords: dataloss)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.5) Gecko/20011012 BuildID: 2001101202 This may not be a clearly reproducible bug, however I have encountered this problem more than once and have a bad feeling about it. I know of one instance where I had a sub-folder full of bookmarks. I rearranged and moved bookmarks all around. I came back still to find the folder there, but it was empty. I know I didn't delete them. I have a backup file of a before and after. I hope this bug will signal others to look for instances where there is data loss of bookmark information. Bookmarks are one of the few -highly- important areas to users, and ignoring this is too dangerous not to at least have an open tracking bug like this one. Reproducible: Couldn't Reproduce Steps to Reproduce: 1. Create a sub-folder with a set of bookmarks in it. Let's say 6 bookmarks and no sub-sub-folders. 2. Rearrange bookmarks, move some, move the folders around, up a level, down a level, I don't know exact steps here. Actual Results: Folder remains but bookmarks that it contains are gone. Data Loss. Expected Results: No data loss.
Adding keyword "dataloss"
Keywords: dataloss
This has happened three times now. I only notice it later when I try to find bookmarks and there's no data! I need help to track this down. I need to understand these strange dat fields and how to correlate them to real dates. Here is some example data before and after: <DT><H3 ADD_DATE="1003287027" LAST_MODIFIED="1003287054" ID="NC:BookmarksRoot#$e0b56575">Sailing Charters</H3> <DL><p> <DT><A HREF="http://www.sailors.com/sfbay/charters/" ADD_DATE="1003286872" LAST_CHARSET="ISO-8859-1">San Francisco Bay Sailing - Yacht Chartering Companies</A> <DT><A HREF="http://www.adventurecat.com/index.html" ADD_DATE="1003286768" LAST_CHARSET="ISO-8859-1">Adventure Cat Sailing Charter - San Francisco Bay Cruise With A Difference</A> <DT><A HREF="http://www.sf-escapes.com/pirate.html" ADD_DATE="1003286465" LAST_CHARSET="ISO-8859-1">San Francisco - Sail on a Pirate Ship</A> <DT><A HREF="http://www.comesailing.com/" ADD_DATE="1003286489" LAST_CHARSET="ISO-8859-1">ComeSailing.com San Francisco - Imagine a dinner cruise on the bay by the city</A> <DT><A HREF="http://www.serioussports.com/ocsc/" ADD_DATE="1003286685" LAST_CHARSET="ISO-8859-1">OCSC Sailing Schools San Francisco Bay California</A> </DL><p> and the after: <DT><H3 ADD_DATE="1003287027" LAST_MODIFIED="1003436158" ID="NC:BookmarksRoot#$809bf353">Sailing Charters</H3> <DL><p> </DL><p>
I had to search to find out how to do the conversion of unix epoch time to real time. For anyone else tracking this down, the command to convert 1003968782 to a readable date is: date -d '1970-01-01 1003968782 sec'
I am poking around the code for the first time, so... I'm looking at nsBookmarksService.cpp. Bug 78882 seems relevant. It talks about the Personal Toolbar folder contents getting erased. There seemed to be some confusion about all the details, so this would be a good place to start looking. There was discussion of a varilable nextVal not being set correctly. I also noticed a diff 1.68 on nsBookmarksService.cpp which talks about the RDF container utilities that might be related. I have a question too: how are the ID variables set/used for bookmark folders? I can't understand from what I have seen where they are created and what they are used for.
I wasn't very clear with my question at all. In a bookmark folder, I am curious what the ID filed means/does/is used for such as in: <DT><H3 ADD_DATE="1003287027" LAST_MODIFIED="1003287054" ID="NC:BookmarksRoot#$e0b56575">Sailing Charters</H3> Might these problems be related to copy and paste moving of bookmarks while managing them? I was thinking that is path may use the RDF utility routines.
There have traditionally been a number of ways to lose bookmarks in the manage bookmarks dialog (mostly having to do with js errors rather than the RDF "losing" arcs). I'm not sure which you're hitting here. Blake is on the verge of landing his rewrite of the bookmark manager using the outliner (bug 73508), which will hopefully fix many of these problems.
I'm using 0.9.6 on OpenVMS, BuildID 2001112014. Today Mozilla completely wiped my bookmarks clean, not even leaving the Personal Toolbar or the Mozilla Project folder. I had to get the bookmark.html file from a backup.
One way to loose the bookmark I noticed is to drag it to empty bookmark subfolder. A bookmark can disappear when it is dragged to a folder that is not empty, but it appears more seldom.
Could you guys please retry with the new bookmarks manager? Thanks :-)
Is anyone still seeing this issue on a recent build?
From comment 1, this sounds like bug 92380.
Andrew, I think you've got the wrong bug.
WFM - No activity for a few months. Please reopen if anyone can reproduce on a recent build.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.