On 29/05/2009 10:18 AM, John Machin wrote: > On 29/05/2009 9:34 AM, Gene Allen wrote: >> Yeah. >> >> Since my code works in blocks, read/compress/encrypt/write, loop. Almost >> all the real data was being written to the compressed file, however any >> finalization and flushing of the stream wasn't occurring (since the encrypt >> was failing) > > and the encrypt failure wasn't logged? > > > so the last bit of any SQLite database wouldn't be written. > > If so, pragma integrity_check should report that some of the pages > actually written contain pointers to pages that are past the end of the > file, shouldn't it?
Your output from the integrity_check shows complaints about invalid page numbers in the range 462 to 773. At the default page size of 1024, those page numbers span (773-462+1)*1024 = 319488 bytes so you are missing more than a 262144-byte chunk [unless your page size is 512!]. This doesn't seem to gel with the combination of "almost all the real data was being written" and the hypothesis that the database was corrupted merely by truncation. What are the page size, the expected size of the database, and the actual (truncated) size of the database? What evidence do you have that the feof problem actually happened in this case? _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
