This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: sqlite defect
- From: jojelino <jojelino at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Fri, 19 Jul 2013 20:53:21 +0900
- Subject: Re: sqlite defect
- References: <trinity-fdc5a0b5-6dcf-4fc0-9370-dd32a75fe928-1373654994500 at 3capp-gmx-bs47> <51E703FB dot 1010300 at etr-usa dot com> <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>
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.
Corinna
--
Regards.
--
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