On Wed, Oct 19, 2011 at 03:24:35PM -0500, Nico Williams scratched on the wall: > On Wed, Oct 19, 2011 at 2:23 PM, Jay A. Kreibich <j...@kreibi.ch> wrote: > > On Wed, Oct 19, 2011 at 02:13:35PM -0500, Nico Williams scratched on the > > wall: > >> On Wed, Oct 19, 2011 at 4:00 AM, Stephan Beal <sgb...@googlemail.com> > >> wrote: > >> > On Tue, Oct 18, 2011 at 12:37 PM, Sune Ahlgren > >> > <sune_ahlg...@hotmail.com>wrote: > >> >> What can I do to make SQLite run safely on CIFS? > >> > > >> > Nothing. Even MS Access cannot (or could not way back when i used it) be > >> > safely used on SMB/CIFS storage. > >> > >> Can you elaborate as to why? > > > > ??http://sqlite.org/faq.html#q5 > > > > > > ??In short: buggy filesystem code that doesn't support distributed > > ??locks correctly. > > That explains why concurrent access over NFS or CIFS is dangerous.
For most applications using a database, if there is a moderately high possible loss of data (i.e. "dangerous"), that's the same thing as "not possible." "Not a very good idea," at minimum. > It doesn't explain that it's not possible to use SQLite3 over NFS or > CIFS. As with concurrent access, it is *possible*, just dangerous. Which is "not possible" for most applications. Even if concurrency isn't an issue in your specific case, locks and synchronization tend to go hand in hand. Correct SQLite transactions depend on the ability to verify data has been physically written to storage. Most network file systems don't do this correctly. Heck... a lot of physical hard drives don't do this correctly. See: http://sqlite.org/lockingv3.html#how_to_corrupt http://sqlite.org/atomiccommit.html#sect_9_0 > Also, regarding NFS, it would be safe to use if SQLite3 were to use > whole-file byte range locks. NFS makes concurrent access to byte > ranges that are not locked unsafe. Of course, safely making changes > to how SQLite3 locks files may be difficult now... > > CIFS does support byte range locking, and I suspect that the same rule > I mentioned above regarding NFS applies. Plus, as a last resort > there's CIFS open deny modes that SQLite3 could use to prevent > concurrency. Just because the standards include such features, you seem to be under the impression that every client and every server running on top of any filesystem actually implement said features correctly, and that every combination of client and server interacts and operates correctly. Needless to say, it just ain't so. Not by a long-shot. As for modifying SQLite, the locking mechanism is actually somewhat modular, and I believe SQLite already includes the ability to some types of range locks. That still doesn't do you any good if the filesystem doesn't answer the APIs correctly. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
