Ant wrote:
On 12/25/2014 10:06 AM PT, NoOp typed:
Eureka! I found it! There were FOUR files all prefixed by
"places.sqlite" including the original file. If I delete all four
and
copy in the "places.sqlite" from my Windows system to my Linux
system,
it works! I only have to copy that one file.
Again, this wasn't necessary until 2.29 came along, so I wonder what
changed??
Do not understand. I don't care how many files contain
places.sqlite in
their filenames, copying the specific fiel "places.sqlite" should
do the
trick.
Just to make things clear, I ALWAYS shut down Seamonkey BEFORE I copy
places.sqlite from the source system, and I ALWAYS shut down Seamonkey
on the target system BEFORE I move over the copy. It didn't matter. I
think the "SHM" and "WAL" files had to be in sync with the base
file, or
it ended up creating a "CORRUPTED" file and I had no bookmarks at all.
Deleting ALL of the places.sqlite* files from the target directory
before copying in the new places.sqlite does the trick. When I restart
Seamonkey it has all of the bookmarks and history, and it recreates the
SHM and WAL files.
This was true for my copy of Firefox running under VirtualBox on my
machine as well. Had to do the same there, too. Never had to do this
before Seamonkey 2.29 so SOMETHING changed.
You should file a bug report; the temp files places.sqlite.shm and
places.sqlite.wal should be closed and removed when SeaMonkey shuts
down. So you've most likely found a bug. See:
<https://www.sqlite.org/tempfiles.html>
2.2 Write-Ahead Log (WAL) Files
...
"The WAL file is created when the first connection to the database is
opened and is normally removed when the last connection to the database
closes. However, if the last connection does not shutdown cleanly, the
WAL file will remain in the filesystem and will be automatically cleaned
up the next time the database is opened."
2.3 Shared-Memory Files
...
" The shared-memory file has the same lifetime as its associated WAL
file. The shared-memory file is created when the WAL file is created and
is deleted when the WAL file is deleted. During WAL file recovery, the
shared memory file is recreated from scratch based on the contents of
the WAL file being recovered. "
Follow-up: looks like someone already opened a bug report & it got the
wishy-washy "RESOLVED WORKSFORME" (aka 'Don't Know, Don't Care)
treatment:
<https://bugzilla.mozilla.org/show_bug.cgi?id=686237>
(places.sqlite-wal and places.sqlite-shm not removed on exit)
I reckon it's worth reopening (notice comment #2)...
Can we easily reproduce this though? I only see these files if my web
browsers are still opened. I'll need to see if my process is stuck after
exiting.
Hell I can recreate this at will on Ubuntu Trusty, Mint Qiana and
Windows7 with Seamonkey AND Windows7 and WindowsXP with Firefox.
Every single time I shut down the browser I'll find those -shm and -wal
files in the profile directory. This didn't happen with SM 2.26 (and the
equivalent level of Firefox).
--
Jaime A. Cruz
Nassau Wings Motorcycle Club
http://www.nassauwings.org/
AMA District 34
http://www.AMADistrict34.com/
Pop's Run
http://www.popsrun.org/
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
