File not written to by System.Data.SQLite on windows share after network failure

Question

I have the following scenario:

WPF Application using SQLite-file per System.Data.SQLite on a windows-share as backend. Client is Windows 7 Home Edition

A user reported, that she was using the software, saving the new data she entered, but then after a while when she re-visited the software, some of her stuff was gone.

She said the session lasted until about 11:50am - the timestamp on the SQLite file in question was 10:55am. I have a logfile in the same network share, it is written to using a filewriter with autoflush.

The logfile looks normal until 10:55am, then there is one line with rubbish (looks like several lines written together in one), then goes on as normal.

Clearly the network (or maybe the drive) must have had a hiccup at that time. Miraculously my application just continued as normal. No exceptions were thrown, according to the logfile all transactions are "completed". No journal file remains to tell the tale. This behaviour - although wonderous in itself - is not appreciated by the user :)

My question: what happened here and how can I prevent it in the future? Did Windows 7 cache the file in the standby list and not care at all about comitting the changes to the actual disk? Why is my application or the SQLite provider unaware of this?

I will now build a confirmation mechanism that checks the timestamp on the backend file to see if it was actually changed at all after the last transaction, but that seems a bit silly. Just as silly as being very pedantic with catching exceptions when they are not being thrown :)

Thank you

TL;DR SQlite file shows no changes after momentarily hardware (network or drive) failure, but the application seemingly continues to function and no exceptions are thrown by System.Data.SQLite.

Answer 1

See section 3 of How To Corrupt An SQLite Database File; it appears that Windows did not sync the network share when SQLite told it to.