This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: sqlite defect
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Fri, 19 Jul 2013 14:02:42 +0200
- Subject: Re: sqlite defect
- References: <trinity-1068d666-3dec-43c9-8453-39c7cae3a94c-1374102947415 at 3capp-gmx-bs33> <51E74AB4 dot 7010508 at etr-usa dot com> <ks87ur$nle$1 at ger dot gmane dot org> <20130718085953 dot GC9628 at calimero dot vinschen dot de> <ksa6bs$ac9$1 at ger dot gmane dot org> <20130719100329 dot GC20871 at calimero dot vinschen dot de> <20130719100809 dot GD20871 at calimero dot vinschen dot de> <ksb4cn$cp8$1 at ger dot gmane dot org> <20130719113009 dot GE20871 at calimero dot vinschen dot de> <ksb9be$2ss$1 at ger dot gmane dot org>
- Reply-to: cygwin at cygwin dot com
On Jul 19 20:53, jojelino wrote:
> On 2013-07-19 PM 8:30, Corinna Vinschen wrote:
> >A valid testcase would help a lot, though. What you meant to do
> >was calling flock with LOCK_EX|LOCK_NB.
> >
> that's what exactly sqlite3 that uses the mandatory-locking did.
> reproducing the behavior was i meant to do.
> >And then again, your testcase works as designed. Not by me, but by
> >Microsoft. You can't overwrite an existing lock, even if hold by the
> >same file handle. See http://cygwin.com/cygwin-api/std-notes.html
> >
> Yes. the testcase works without mandatory locking. so i hope next
> sqlite3 release doesn't use mandatory locking feature of cygwin.
> someone who have plenty of time to waste digging into sqlite3 source
> code would come with workaround to the problem.
There *is* a workaround:
export CYGWIN_SQLITE_LOCKING=posix
See http://cygwin.com/ml/cygwin-announce/2013-06/msg00014.html
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple