On 08/03/2012 04:07 PM, David E. Ross wrote: > On 8/3/12 2:02 PM, NoOp wrote: ... >> SeaMonkey uses SQLite3. >> $ file places.sqlite >> places.sqlite: SQLite 3.x database, user version 17 >> >> sqlitebrowser also supports 3.x: >> "Jens Miltner contributed the code to support SQLite 3.x databases for >> the 1.2 release." >> and I've not run into any issues with it so far. But doesn't mean that I >> won't in the future, so point taken. >> >> Digging a little further regarding vacuuming the places database every >> month, I found these: >> https://bugzilla.mozilla.org/show_bug.cgi?id=512854 >> [VACUUM places.sqlite database on daily idle once a month] >> https://wiki.mozilla.org/Firefox/Projects/Places_Vacuum >> >> BTW: places.last_vacuum is depreciated and no longer used. If you load >> up an fresh SeaMonkey, you won't find it in 'about:config'. I still have >> it in this version as it's been carried over from the older prefs.js >> when it was valid: >> >> places.last_vacuum;1261531940 >> $ date --date='@1261531940' >> Tue Dec 22 17:32:20 PST 2009 >> >> but it's no longer there in a new/fresh SeaMonkey/prefs.js install. >> >> storage.vacuum.last.places.sqlite has replaced places.last_vacuum: >> >> storage.vacuum.last.places.sqlite;1342907499 >> $ date --date='@1342907499' >> Sat Jul 21 14:51:39 PDT 2012 >> >> Here is an interesting breakdown of places.sqlite: >> http://www.forensicswiki.org/wiki/Mozilla_Firefox_3_History_File_Format >> This might be of interest also: >> <https://blog.mozilla.org/nnethercote/2011/11/16/memshrink-progress-report-week-22/> >> Particularly: >> <https://blog.mozilla.org/nnethercote/2011/11/16/memshrink-progress-report-week-22/comment-page-1/#comment-4355> >> This is the bug report referred to: >> <https://bugzilla.mozilla.org/show_bug.cgi?id=692487> >> [Decrease Storage connections default cache_size] >> >> So whether it's advisable to vacuum manually, I don't know. I wouldn't >> do it without first backing up the databse being vacuumed & I'd just let >> SeaMonkey do it monthly on it's own, unless of course places.sqlite is >> growing to large each day. However, if that is the case, then it might >> be better to review my browsing habits, or file a bug report. On the >> other hand, I've not encountered a problem with vacuuming any of my >> sqlite databases (including the Mozilla db's) manually, but I always >> keep backups & perhaps I've just been lucky so far... >> > > Note that bug #512854 only addressed places.sqlite and has been > implemented. Bug #538493 addresses ALL SQLite databases and has not yet > seen any attempt to implement it. See > <https://bugzilla.mozilla.org/show_bug.cgi?id=538493>. >
Thanks for the link. BTW & way OT: While reviewing that bug report I noticed that it mentions "Tools > Error Console". Out of curiosity I had a look at the 'Error Console' & found some interesting entries (all bugzilla.mozilla.org caused): bugzilla.mozilla.org : server does not support RFC 5746, see CVE-2009-3555 (multiple entries) Timestamp: 08/03/2012 04:51:35 PM Warning: Unknown property '-moz-opacity'. Declaration dropped. Source File: https://bugzilla.mozilla.org/js/yui/assets/skins/sam/autocomplete.css?1303753510 Line: 7 (multiple entries) and most interesting of all (IMO): statse.webtrendslive.com : server does not support RFC 5746, see CVE-2009-3555 Digging a little further, I find that Mozilla has an 'opt-out' requirement (as opposed to 'opt-in'), specifically for Webtrends: <https://www.mozilla.org/en-US/opt-out.html> I generally browse with cookies off & only turn them on for trusted sites that I know require them & then delete them when finished, so the Webtrends doesn't affect me until I turn cookies back on (logging into bugzilla). However, rather than following the info on https://www.mozilla.org/en-US/opt-out.html, simply let a webtrendslive cookie to be set, then Tools|Cookie Manager|Manage Stored Cookies| and nuke the cookie with the 'When removing, block the listed websites from setting future cookies'. Also see: <https://bugzilla.mozilla.org/show_bug.cgi?id=707212> [bugzilla pages cause lots of "statse.webtrendslive.com : server does not support RFC 5746, see CVE-2009-3555" messages to error console] <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3555> <https://bugzilla.mozilla.org/show_bug.cgi?id=CVE-2009-3555> [(CVE-2009-3555) SSL3 & TLS Renegotiation Vulnerability] _______________________________________________ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
