>It is a reasonable assumption to make that the only thing which can have >changed since the last write is the disk becoming full. A disk cable falling >off, head crash or mechanical disk failure is not only unlikely but would >crash the entire machine and make error detection and recovery unlikely so >testing for it is futile.
It is reasonable for a program like sqlite to operate on the assumption that other hardware and software perform as intended, and not attempt heroic error recovery. On the other hand, sqlite operates in the real world, and wierd shit happens out there. When something goes wrong, every bit of information that is available should BE available to those trying to clean up the mess. There is a huge difference, coming in in the morning after an expected overnight run, finding it failed, and having the message database full verses having the message 09-feb-2006 03:13:12 database write failed, windows error code 14 for f:\temp\vacuumtemp.txt, current file size = 10200K
