Hi, I recently discovered that for vfs implemented writable formats that actually change the data of the sqlite base (encryption, compression), there should be a complex logic behind the restoration from the hot journal, at least some versions ago. For correct password handling initially I relied on the test read after the first open to detect wrong password and reopen the db with a new one, but if a hot file is present one can lose the data. It looked like between no-error open (that usually always the case for any db) and my test read, there was also a restoration attempt and at least sqlite 3.6.10 deleted -journal if this attempt failed. I implemented a more complex logic when first open also tried to read data from header and reported SQLITE_NOTADB if it could not. This worked for 3.6.10
I tried also 3.7.4 and it looks like starting some version sqlite don't delete -journal if vfs failed to deliver the correct data. But if I disable my complex logic during open, after the correct password is supplied and vfs starts to return correct data, I see some reading/file size requests and something is done, but the final file is malformed. If I repeat the procedure with 3.6.10 and tricky open the restoration process correctly returns the original db (I compared them bit to bit). 3.7.4 with this complex open also returns the correct db. I know that it's deep about internals and I still can rely on my complex logic, but what was that change between 3.6.10 and 3.7.4 that fixed -journal deleting, but introduced something new that sometimes prevents the program from working correctly? Thanks, Max _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
