On Tue, Mar 2, 2010 at 9:54 PM, Jonathan Pryor <jonpr...@vt.edu> wrote: > In short, SQLite (1) uses advisory file locking (as FileStream.Lock() > provides under Mono), then (2) requires that all SQLite users actually > use libsqlite.so (otherwise they won't use the internal management).
Well, I'm guessing the developer of libsqlite.so was not expecting there to be other conflicting implementations of sqlite that would all be accessing the same database. So if the managed sqlite clone is supposed to be 100% interoperable with the real sqlite (which I doubt it very important), it needs to do exactly the same kind of locking, ie. your solution #3. Otherwise, it needs to do its own locking however it likes, your solution #1 or #2. So I suppose I'm agreeing with your facts, but not your opinions... I'm not sure what's so ugly about this solution. > So if someone re-implements SQLite (or just cat(1)'s the file), they > won't go through SQLites lock management, and they'll be none the wiser. As it (arguably of course) should be. People writing backup software on Unix are much happier people than people writing backup software on Windows. And as a user, I'd prefer to have multiple possibly-slightly-corrupted backups of my MS Exchange server or virtual machine disks instead of the terrible surprise upon restoring of finding out there were no backups (because mandatory locks rejected me). Mandatory locking isn't nearly as great as it sounds. Have fun, Avery _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
