> Does it suck as much as file corruption wiping out your bookmarks after your computer (not
Firefox) crashes?
1) write to bookmarks.new ,
2) every 5 min
a) fsync
b) mv -f bookmarks.new bookmarks.html
c) open bookmarks.new (new)
d) write all data to bookmarks.new
3) goto 1
easy, fast(if file below 3MB) and safe , it seems FF2 does it this way?
Fsyncers and curveballs (the Firefox 3 fsync() problem)
Posted May 26, 2008 16:35 UTC (Mon) by orev (subscriber, #50902)
[Link]
Obviously!
You should at least understand how Firefox 3 bookmarks work. They use the sqlite database and
no longer use the bookmarks.html file.
Fsyncers and curveballs (the Firefox 3 fsync() problem)
Posted May 26, 2008 17:34 UTC (Mon) by ikm (subscriber, #493)
[Link]
And what difference does it make in regard to the given solution? Sqlite database is just a
file as well.
Fsyncers and curveballs (the Firefox 3 fsync() problem)
Posted May 27, 2008 0:10 UTC (Tue) by szh (guest, #23558)
[Link]
I am asking - why go for this sql db fsync FF2->FF3 regression ? , nobody will make sql
queries to their bookmarks, imho.
Fsyncers and curveballs (the Firefox 3 fsync() problem)
Posted May 27, 2008 0:57 UTC (Tue) by bojan (subscriber, #14302)
[Link]
> nobody will make sql queries to their bookmarks
FF3 does.
Fsyncers and curveballs (the Firefox 3 fsync() problem)
Posted May 27, 2008 10:03 UTC (Tue) by szh (guest, #23558)
[Link]
again, does it give FF3 any technical superiority over the FF2, or only speed regression ?
As long as file is small imho thats a bad decision. (and yes, a backup copy of sqlite file +
removing fsync, would/will be a solution)
Fsyncers and curveballs (the Firefox 3 fsync() problem)
Posted May 27, 2008 10:30 UTC (Tue) by bojan (subscriber, #14302)
[Link]
I guess, by looking at FF3B5. FF developers also think so.
Believe it or not, I think this bug is a good thing. If you have a look at the bug itself:
https://bugzilla.mozilla.org/show_bug.cgi?id=421482
You'll see that important kernel folks got involved, so maybe some ext3 bugs will get fixed.
Also SQLite leading man got involved, so maybe it will get improved as a result. And finally
FF will be better for it.
It's just a bug. It will be fixed (actually, looks like it already was fixed). It's all good.
Fsyncers and curveballs (the Firefox 3 fsync() problem)
Posted May 27, 2008 16:19 UTC (Tue) by drag (subscriber, #31333)
[Link]
It's very good that the problem is found and it's getting fixed. It would probably help a
whole of of people and different applications.
It's still probably very silly to use a SQL database to store bookmarks, even if it's a very
light database engine. Seems like a bunch of people need to be smacked by a cluebat that a
lightly formatted flat text file is superior (simplier/faster) to a SQL database for most
things that people need a database for... (ie: storing small amounts of editable data in a
file on a filesystem)
Personally I liked the bookmarks.html. Makes it very easy to backup my bookmarks and use them
with/in other programs.
Ever used bookmarks.html as a home page?
Fsyncers and curveballs (the Firefox 3 fsync() problem)
Posted May 27, 2008 21:19 UTC (Tue) by roc (subscriber, #30627)
[Link]
The real need for a database isn't bookmarks, it's history.
Fsyncers and curveballs (the Firefox 3 fsync() problem)
Posted May 28, 2008 9:01 UTC (Wed) by IkeTo (subscriber, #2122)
[Link]
> The real need for a database isn't bookmarks, it's history.
The real need for a database isn't history either. It is extensions. You can have a custom
format for history so that given an URL you know whether it is in it or not, and you can list
all of them in the order of time. Easy. But extension is different. You don't really know
what they need, because each of them need different thing. So your only option is to ship
something really generic, in other words, database. If they have to ship a database anyway, I
don't see any reason they are not merging bookmarks and history into the same framework.
Fsyncers and curveballs (the Firefox 3 fsync() problem)
Posted May 26, 2008 18:04 UTC (Mon) by ikm (subscriber, #493)
[Link]
Limiting possible damage to one session is probably ok, since the probability of the damage is
low. So just doing a backup on startup (or, alternatively, restoring from it if the current
copy is mangled too much due to some hardware/kernel failure) would seem fine.
Another solution is to just separate the normal, manually made bookmarks from everything else.
The only real precious stuff is the actual bookmarks, all other automatically collected data
is just a convenience which helps you type less, and which would fix itself over time anyway.
Since they're at rc1 already, maybe it's just too late for all that. I wonder though what
platform they develop on, since this is very obvious stuff and the fact that it is still
present in rc1 probably means Windows is their primary target. I would understand that, but
that's a pity.
Fsyncers and curveballs (the Firefox 3 fsync() problem)
Posted May 26, 2008 23:08 UTC (Mon) by bojan (subscriber, #14302)
[Link]