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? [snip] >> Well...a more structured test exposed the problem and it was this: >> >> The feof() does return true until you attempt to read PAST the end of a >> file. If feof doesn't continue to return true, it is broken. > So the code worked great until the file's length was a multiple of > the >> buffer size (in my case 262,144 bytes). As you can imagine that doesn't >> happen too often in the real world. >> >> Since I assumed that a feof would return true where there wasn't any more >> data in the file, I would start another pass at reading a chunk of data >> (which wouldn't find anything) and run thru the compression/encryption > code. >> The compression code worked handled it correctly, but the encryption >> required that a DWORD boundary (blowfish) and since 0 is on such a > boundary >> but at the wrong end...it would fail. Silently? Unlogged? In any case, I would have thought using feof() was not needed ... long time since I've written C in earnest, but isn't something like this the standard idiom: #define BUFSIZ 262144 buff char[BUFSIZ]; size_t nbytes; FILE *f; f = fopen("filename", "rb"); while ((nbytes = fread(buff, 1, BUFSIZ, f)) { do_something(buff, nbytes); } ?? HTH, John _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users