Re: [sqlite] work-arounds for (possibly buggy) nfs?

Richard Hipp wrote: > Try using: > > sqlite3 db ./foo -vfs unix-dotfile When my application dies while holding a lock under unix-dotfile, all subsequent runs always think the database is locked. I guess this is because the lock file exists. Is there an obvious/good way to know whether the

Re: [sqlite] work-arounds for (possibly buggy) nfs?

Richard Hipp wrote: > sqlite3 db ./foo -vfs unix-dotfile > > That uses an alternative VFS that uses dot-file locking instead of > posix advisory locks. The dot-file locks are someone slower and have less > concurrency, so the use of "PRAGMA locking_mode=EXCLUSIVE" might also be a > good

Re: [sqlite] work-arounds for (possibly buggy) nfs?

Richard Hipp wrote: > sqlite3 db ./foo -vfs unix-dotfile Works like a charm! > That uses an alternative VFS that uses dot-file locking instead of posix > advisory locks. The dot-file locks are someone slower and have less > concurrency, so the use of "PRAGMA locking_mode=EXCLUSIVE" might

Re: [sqlite] work-arounds for (possibly buggy) nfs?

On Thu, Jul 8, 2010 at 10:31 AM, Eric Smith wrote: > I'm forced into a situation where I have to use an nfs server that I > think is buggy. > Try using: sqlite3 db ./foo -vfs unix-dotfile That uses an alternative VFS that uses dot-file locking instead of posix advisory

[sqlite] work-arounds for (possibly buggy) nfs?

I'm forced into a situation where I have to use an nfs server that I think is buggy. I can read/write files normally using fopen() on the exported filesystem, but can't do anything useful with sqlite 3.6.23.1: -bash-2.05b$ tclsh % package require sqlite 3.6.23 % sqlite3 db ./foo % db eval