[Mono-dev] Equivalent to LockFileEx on Linux

[Avery Pennarun]

On Tue, Mar 2, 2010 at 9:54 PM, Jonathan Pryor <jonpryor at 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