seriously? you should fix and solve why the soft crashed in the first place, reality check please.
"But it is possible that Dropbox will copy a database and journal files that are not consistent with each other, which can create problems" fix the sync process, that's easy. Best. On Mon, Jul 14, 2014 at 3:04 PM, Drago, William @ MWG - NARDAEAST < william.dr...@l-3com.com> wrote: > This may be a bit simplistic, but it does give me a reasonable degree of > confidence that hot journal files are being handled correctly in my > application. > > I simply put a 1/0 on the line before my commit to purposely crash my app. > Sure enough there's a journal file after the crash (I have a rather large > transaction consisting of among other things, about 35 rows inserted, each > containing a blob). > > When I restart my app it looks for the presence of a journal file and will > open and read the db so that SQLite can deal with it. It also displays a > message letting the user know that something went wrong during the last run. > > I do this with a test db of course, not the real one. > > -Bill > > > > > > -----Original Message----- > > From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- > > boun...@sqlite.org] On Behalf Of Charles Parnot > > Sent: Saturday, July 12, 2014 4:38 AM > > To: sqlite-users@sqlite.org > > Subject: [sqlite] capturing and testing a hot journal > > > > Hi all, > > > > For testing purposes of our application (a Mac app), I am generating > > what I thought would be a database with a "hot" journal using this > > approach (on an existing database): > > > > - open the database (and PRAGMA journal_mode = TRUNCATE;) > > - open a transaction: BEGIN IMMEDIATE TRANSACTION; > > - add some rows: INSERT etc... > > - **make a copy of the db and journal files** (while still hot?) > > - close the transaction > > > > Then I open the copied database+journal (naming the files > > appropriately), again in TRUNCATE journal mode. As expected, the > > content of the database does not include the inserted rows. However, > > the journal file is not emptied, even after closing the database. Based > > on the documentation > > (http://www.sqlite.org/lockingv3.html#hot_journals), I would have > > expected the journal file to be emptied because it is "hot". > > > > There are 2 options here: > > > > - the journal file is actually not "hot" and I misunderstood the > > conditions that make it hot > > - there is a bug in SQLite > > > > Obviously, I strongly suspect I am misunderstanding things, and don't > > think it is an SQLite bug. Despite intensive Google-ing and more > > testing, I am not sure what makes the journal non-hot. > > > > Thanks for your help! > > > > Charles > > > > > > NB: You might be wondering why I am doing the above. I realize SQLite > > has already much more advanced tests for "hot" db+journals (running > > custom versions of filesystems to generate all kind of edge cases). The > > test case I am generating is just for a simple edge case of our > > Dropbox-based syncing (see: https://github.com/cparnot/PARStore and > > http://mjtsai.com/blog/2014/05/21/findings-1-0-and-parstore/). For a > > given database file, there is only one device that can write to it, all > > other devices being read-only (not in terms of filesystem, but sqlite- > > wise). But it is possible that Dropbox will copy a database and journal > > files that are not consistent with each other, which can create > > problems. For instance, maybe a read-only device could try to open the > > (still old) database with a new non-empty journal file and sqlite would > > empty that journal file, then Dropbox could in turn empty the journal > > file before the writer client had finished the transaction. I am not > > (yet) going to test for and try to protect against more complicated > > (and rarer) edge cases where the database is in the middle of writing a > > transaction (which I suspect will only happen in case of crashes, not > > because of Dropbox, in which case the recovery of the database by the > > read-only client would actually be beneficial). > > > > -- > > Charles Parnot > > charles.par...@gmail.com > > http://app.net/cparnot > > twitter: @cparnot > > > > Your Lab Notebook, Reinvented. > > http://findingsapp.com > > > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@sqlite.org > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > CONFIDENTIALITY, EXPORT CONTROL AND DISCLAIMER NOTE:This e-mail and any > attachments are solely for the use of the addressee and may contain > information that is privileged or confidential. Any disclosure, use or > distribution of the information contained herein is prohibited. In the > event this e-mail contains technical data within the definition of the > International Traffic in Arms Regulations or Export Administration > Regulations, it is subject to the export control laws of the > U.S.Government. The recipient should check this e-mail and any attachments > for the presence of viruses as L-3 does not accept any liability associated > with the transmission of this e-mail. If you have received this > communication in error, please notify the sender by reply e-mail and > immediately delete this message and any attachments. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
