On Fri, 13 Jan 2017 11:17:11 +0800 Rowan Worth <row...@dug.com> wrote:
> I wonder if this is something sqlite could catch in normal operation > and return SQLITE_CORRUPT? Or are there reasons/history which would > render this conclusion inaccurate? Not without cost. In general, it's difficult for any program to verify the integrity of a file. One way would be to keep a checksum of some kind in the file, and update it whenever the file is closed. That imposes the cost of validating the checksum when the file is opened, and of computing it when it's closed. And the cost of a false positive: perhaps the data are OK, but the checksum was corrupted. A checksum like that couldn't be added to SQLite without changing the file format, which has been fixed for over a decade. The guard against FTP truncation is well known. Transfer the file to a temporary name, and rename it to its proper name only when the transfer is successfully concluded. TCP ensures reliable delivery; only a bug in the FTP program (or underlying software or hardware) could introduce data corruption. --jkl _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
