Peter said:
Thanks, I did this and used a Hex editor to delete
the contents. It didn't work though.
Arrgh!
No, that's not necessary.
Delete the file if you're unhappy with it.
I don't know where the garbage is coming from in the file.
(It's possible when you clear cookies, the file size is
never reduced, and only certain sectors are completely rewritten.)
The sqlite .dump command shows what is "real" in the file.
The parts that don't matter to sqlite, I don't know if they
were already on that disk sector, or whether an uninitialized
buffer in the sqlite driver is doing that.
If you wanted to "cleanse" the file, you could try re-creating
the file, using the output of the .dump. As far as I know,
the stuff in the .dump output, should be the same stuff
needed to re-create the file. I've never had to do that
before, so I don't know the recipe right off hand.
It occurs to me, that maybe what I need, is VACUUM command.
Vacuum is not to be used carelessly.
I've seen claims you need to re-index or something, before
you're done. So it isn't perfectly harmless, when there
are multiple database files.
http://www.sqlite.org/lang_vacuum.html
It would be something along the lines of
sqlite3 cookies.sqlite VACUUM;
As seen here...
http://www.reddit.com/r/linux/comments/7nri6/compact_your_firefox_sqlite_databases_for_f_in/
You play with the databases, only when Firefox is not running.
You'd check Task Manager to make sure. (Because Firefox is not
dead, even if the GUI goes away. Sometimes it is still running,
which is why you check Task Manager before VACUUMing.
And until you can prove what you're doing has no side
effects, keep backups of any important files. For example,
if you're playing with vacuuming places.sqlite, you'd keep a backup
copy handy just in case.
OK, when I VACUUM my cookies.sqlite, it becomes 2048 bytes,
and only the important stuff remains (no more garbage). If I do
a dump again, I get the expected stuff for an "empty cookies".
So it's not damaged (because we expect it to be virtually empty,
and there is nothing to index here).
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE moz_cookies (id INTEGER PRIMARY KEY, name TEXT, value TEXT,
host TEXT, path TEXT,expiry INTEGER,
lastAccessed INTEGER, isSecure INTEGER,
isHttpOnly INTEGER);
COMMIT;
It might be a different situation, if there were actual cookies in
there, and VACUUMing created an indexing problem. I don't know
anything about databases, and this is just something I read when
researching what happens if you vacuum places.sqlite or equivalent.
In the case of places.sqlite, you're trying to preserve that
one most of the time, so it's important not to damage it.
*******
Firefox Private browsing mode...
http://forum.piriform.com/index.php?showtopic=22704
Near the bottom of that page, it mentions that "sessionstore.js"
can contain cookies. It's possible if you kill Firefox with Task
Manager, cookies could be left in there. And conversely, the
cookies.sqlite gets updated when Firefox exits.
In a test here, sessionstore.js exists if you "kill" Firefox from
Task Manager. Whereas if you shut down Firefox normally, there is
no need to keep track of the session, and sessionstore.js is
deleted. So it's just a way of allowing you to recover a session
if Firefox exits abnormally. So I don't see that as being an issue,
unless you go around "hammering" Firefox a lot just for fun. When
I looked in my sessionstore, I didn't see a cookie, but plenty of
URLs were in there anyway. So it does keep some information. But
on a normal termination of Firefox, that file is gone.
Paul
