User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701
I use Firebird on PC/Windows platform. I have a problem when windows system
crash (blue screen), the next time I invoke Firebird, the bookmark file sometime
I wonder if its possible to place a backup file before 'FB' is up? This backup
file will just contain the bookmarks from last saved session, don't need to
syncronize with current using one. And while 'FB' is closed, do nothing to
backup file. Next time 'FB' is called, remove old backup with new bookmark....
Steps to Reproduce:
lost bookmark file...
that i can recover my bookmark from not too long ago when windows F$$K up
please....i've lost my bookmark for a couple of times.....
Quite agree on this bug. If it had journaling backup and rollback feature, it'd
be better, for Mozilla bookmark is a kind of personal database.
*** Bug 220252 has been marked as a duplicate of this bug. ***
*** Bug 221432 has been marked as a duplicate of this bug. ***
*** Bug 221721 has been marked as a duplicate of this bug. ***
I suggest to add a feature to Mozilla / Firebird that allows to create backups
of files such as bookmarks.html, Personal toolbar, mail prefs, news prefs, etc.
How about adding a menu entry to the "Edit / Preferences..." menu underneath the
"Navigator" branch called "Settings backup"?
This should contain tick boxes of what somebody wants to backup, to where and
how often (time interval) this should happen. Also a restore feature should be
introduced with a selection option what and which backup should be restored.
This may solve some of the issues where an OS freezes or crashes unrecoverably.
I discovered a plugin in the Firebird extentions page:
I am using it, it will save the bookmark to your specified folder every day with
the weekday as a loop. So I end up with 7 bookmark backups in that folder, which
is quite acceptable for me. I guess people who need the backup feature can use
this before the actual native solution would came out.
*** Bug 227734 has been marked as a duplicate of this bug. ***
*** Bug 227968 has been marked as a duplicate of this bug. ***
*** Bug 228985 has been marked as a duplicate of this bug. ***
Targeting for Pierre. Enough people are encountering mysterious bookmarks loss
that having a backup is useful.
brendan says it's worthwhile investigating if there's a platform pattern here
... perhaps file rename/move operations aren't atomic on windows, etc.
*** Bug 229276 has been marked as a duplicate of this bug. ***
The Bookmarks Synchronizer extension is also a valuable tool that allows for
off-site backup of bookmarks using the FTP protocol. It can also export
bookmarks in XML format, and the latest versions have quite advanced functionality.
do a bugzilla query on "lost bookmarks" to find a number of bugs that backing up
the bookmark file would work around.
First of all, just check to see if bookmark file is being held open when it
should have been closed...
A safe approach in general might be to make a copy of the bookmarks.html file
for backup purposes after a successful write of the bookmarks file. Many of the
"lost bookmarks" bugs result in bookmarks.html either being REMOVED or being
truncated to 0. In either case - when the browser starts instead of replacing
the bookmarks file with the DEFAULT one, the BACKUP file if present should be
used. This may hide the bug completely from users.
*** Bug 249731 has been marked as a duplicate of this bug. ***
*** Bug 250302 has been marked as a duplicate of this bug. ***
Created attachment 154340 [details] [diff] [review]
not sure if we want to do this - not sure what the use is, but here it is
who would be good reviewers? danm, sspitzer, dveditz... lets get some eyes on
this and decide..
Patch needs to be updated due to nsSafeOutputStream changes (bug 252053). Ben
and I also talked about making the parser catch a truncated file by catching a
missing "</HTML>" -- should be done either later today or by monday at the latest.
Created attachment 155020 [details] [diff] [review]
Updated patch. Tries to save a backup copy of the previous successful write,
instead of right after the latest write -- if the problems we're seeing are
caused by fs corruption/lossage, then doing that copy afterwards won't help us
any. The patch then ends up saving a backup after any change but before the
next Flush or if the save timer fires, whichever comes first. It also moves
the scheduling-related timer-disabling into the timer callback itself, so we
still get the periodic saves even though scheduling/etc. is disabled
Comment on attachment 155020 [details] [diff] [review]
>- // bookmark timers and scheduling are disabled for 1.0, until
>- // they can be fixed (bug 253478)
> /* timer initialization */
> busyResource = nsnull;
> if (!mTimer)
> busySchedule = PR_FALSE;
> mTimer = do_CreateInstance("@mozilla.org/timer;1", &rv);
> NS_ASSERTION(NS_SUCCEEDED(rv), "unable to create a timer");
> if (NS_FAILED(rv)) return rv;
> mTimer->InitWithFuncCallback(nsBookmarksService::FireTimer, this, BOOKMARK_TIMEOUT,
> // Note: don't addref "this" as we'll cancel the timer in the nsBookmarkService destructor
did you mean to remove this if 0?
(In reply to comment #23)
> did you mean to remove this if 0?
Yeah, I did, though I guess I meant to change the comment above it as well --
turns out I need that timer to do periodic saves of bookmarks. :)
On my system the bookmarks.bak file doesn't seem to get updated when
bookmarks.html is changed and Firefox restarted, it simply stays the same as it
was when first created (according to nsIFile.idl copyTo can fail if the target
file already exists).
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040809 Firefox/0.9.1+
setting fixed-aviary1.0 for bugfixes checked into branch, for searching purposes.
*** Bug 262228 has been marked as a duplicate of this bug. ***
*** Bug 276169 has been marked as a duplicate of this bug. ***
*** Bug 308237 has been marked as a duplicate of this bug. ***
*** Bug 311160 has been marked as a duplicate of this bug. ***
*** Bug 314424 has been marked as a duplicate of this bug. ***
*** Bug 315102 has been marked as a duplicate of this bug. ***
*** Bug 329102 has been marked as a duplicate of this bug. ***
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change