X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD,TW_SV
X-Spam-Check-By:	sourceware.org
Message-ID:	<502CCBB1.2070600@etr-usa.com>
Date:	Thu, 16 Aug 2012 04:30:09 -0600
From:	Warren Young <warren AT etr-usa DOT com>
User-Agent:	Mozilla/5.0 (Windows NT 6.0; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: Promote sqlite 3.7.13-1 from test status?
References:	<announce DOT 5029275C DOT 4040009 AT etr-usa DOT com> <502C0B7D DOT 10909 AT etr-usa DOT com> <loom DOT 20120816T092134-266 AT post DOT gmane DOT org> <20120816085016 DOT GB5536 AT calimero DOT vinschen DOT de>
In-Reply-To:	<20120816085016.GB5536@calimero.vinschen.de>
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

On 8/16/2012 2:50 AM, Corinna Vinschen wrote:
> On Aug 16 07:41, Achim Gratz wrote:
>> there's a race
>> somewhere between calls from the Cygwin DLL and Windows file locking functions.
>
> Cygwin does not use Windows mandatory locking.  The locking is entirely
> implemented within the Cygwin DLL and is only advisory, as is befitting
> for a POSIX envionment.

Interesting.  I never knew that.  I'd assumed that since Cygwin 
occasionally gets tangled up with Windows mandatory locking (e.g. in-use 
DLL replacement) that it was playing by those rules all the time.

> If you try to use the same file with a
> non-Cygwin tool using Windows locking in parallel with a Cygwin tool,
> you will get into trouble.  The mandatory Windows locking will always
> win and the Cygwin tool will fail.

I think that nails the problem.

SQLite has a lot of Windows and Cygwin specific code in it, and in large 
part, it treats Cygwin as "Windows", including use of the Win32 API 
LockFile().  (See osLockFile() and winLock*() in sqlite3.c.)

When you force it to build in "Unix mode", all that code gets ifdef'd 
out, replaced by an entirely different set of OS-specific I/O wrappers, 
such as unixLock().

So, what you did with that requested change, Achim, is prevented Cygwin 
svn from winning any fights over ownership of .svn/wc.db.

This could have happened to anything built against Cygwin SQLite, where 
there is also another native Windows program trying to access the same 
DB file.  The only Subversion-specific thing about this problem was how 
Subversion was coded to react when it happened.  Another program might 
not say "disk I/O error," but would somehow fail nevertheless.

Reverting this change put Cygwin SQLite based programs back on an even 
footing with native SQLite based programs.

I gotta say, I'm not wild about the way SQLite treats Cygwin as Windows, 
bypassing the POSIX APIs so often.  Yet, you can see the logic, at least 
in the case of file locking.  Mandatory file locking is a very good 
thing in the case of SQLite.

Anyway, I'm going to update my RFU request to promote 3.7.13-1 to curr.

Thanks all for the responses.  It's helped clear things up for me.

--
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

- Raw text -