On 10 Jan 2013, at 3:13pm, Michael Schlenker <[email protected]> wrote:
> So this is a sure way to corrupt the database if the shm code gets an > outdated but not corrupted copy of the -shm file from the OS/filesystem > and additional writes are done. > > Ok, so it seems i should implement some really strict asserts/checks so > customers do not even try to put those files up on NFS, and just have > some pretty error blow up in their face if they try on startup. I've run into this problem when a customer moved a system which had been working perfectly from a local hard disk to a Windows share using SMB or CIFS or something like it. They already knew they shouldn't do this because my company charged a lot more for a network-compatible version of the system than a single-user version. But until they tried it they thought we were simply trying to get more money out of them and didn't expect their data to be corrupted through the complicated problems to do with networking. So fortunately I was able to tell them that they'd violated our license agreement and were suffering the consequences. However, after the incident I looked into ways of checking that the file was being accessed locally rather than on a network share and totally failed. There didn't seem to be any way of doing this under Windows which worked all the time. I ended up putting a check in to see that the full path of the database file started with "C:", as being the only way I could get even close to a proper check, and it's possible to fool even that. Simon. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
