On 2009-07-03 22:15, Steven D'Aprano wrote:
On Sat, 4 Jul 2009 12:56:36 pm Ron Johnson wrote:
Also (and maybe because I'm a DBA), this problem just *screams* for
SQLite and a database in the "First Normal Form".
Please no. SQLite has problems with NFS. It's not so much that SQLite
won't work on NFS as that when (not if) something breaks, it's
difficult to unbreak it.
Honestly, how many people who use Pan also mount $HOME over NFS?
Obviously (as in your use-case below), some people do. But they are
mostly in "institutional" settings, where Pan probably wouldn't be
approved anyway.
My employer supplies Linux desktops to prisons. We have to support a
browser, and the system uses NFS. After an unexpected desktop shutdown,
to recover Firefox 2 you just need to remove a couple of lock files.
For Firefox 3, we needed to open the database (read-only) with the
sqlite3 command-line tool, dump the data into a new sqlite database,
quit, replace the "locked" file with the new "unlocked" file.
That's poor transaction handling on the part of Mozilla, unless
SQLite is *sooooo* broken that it corrupts it's data file even when
no transactions are active.
Did you all contact Mozilla developers, or file a bug? If they
dismissive or not responsive, some bad publicity might get them off
the stick...
Needless to say, this was a major factor in use deciding not to support
Firefox 3 as the browser on the desktop.
I'm sure that there's some work-around hack involving mounting that
directory in tmpfs, and then having a cron job run from the NFS
server sweep thru all the clients, copying that .db file back to the
main $HOME location.
But obviously that's a major hack.
--
Scooty Puff, Sr
The Doom-Bringer
_______________________________________________
Pan-users mailing list
Pan-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/pan-users
