On 12/23/2014 10:37 AM, NoOp wrote: > On 12/21/2014 09:32 AM, Cruz, Jaime wrote: >> Ed Mullen wrote: >>> Cruz, Jaime wrote on 12/19/2014 8:11 PM: >>>> >>>> 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)... _______________________________________________ support-seamonkey mailing list [email protected] https://lists.mozilla.org/listinfo/support-seamonkey
