On 7 Sep 2012, at 1:19pm, Steinar Midtskogen <stei...@latinitas.org> wrote:
> [Richard Hipp] > >> If the last writer to the database file crashed and left a hot >> journal<http://www.sqlite.org/atomiccommit.html#section_4_2>then the >> next reader to come along must rollback that journal before it can >> start reading, and that will require write access. > > Can similar things happen if you copy the database file (using > cp/tar/whatever) while an application wants to write to it? It depends on what you're actually doing when you copy the database file. The hot journal is actually another file, and may be even on a different disk to the database file. So there's a chance that the database file will be marked "Part way through a transaction. There should be a journal file somewhere." but the journal file won't be found. Other models have the database app, the database, and the hot journal all in the same folder, and when someone "copies the database file" they're really copying the whole folder. The real solution to all of this is that if you are writing a program which needs only READONLY access, write your code right from the start to make it open the database in readonly mode. That way, when you are testing your disk image and there's something wrong with the database file it'll be more likely to spit out an understandable error message than to just look like it'll work but fail later. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
