On 12/25/2014 11:03 AM, 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. >
From: Ant <[email protected]> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 Yes it is reproducible... read everything above this line. _______________________________________________ support-seamonkey mailing list [email protected] https://lists.mozilla.org/listinfo/support-seamonkey
