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,TW_SV,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Message-ID: <4FE117BA.1020909@etr-usa.com>
Date: Tue, 19 Jun 2012 18:22:18 -0600
From: Warren Young <warren AT etr-usa DOT com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0
MIME-Version: 1.0
To: Cygwin-L <cygwin AT cygwin DOT com>
Subject: Re: cygwin 1.7.15: svn disk I/O error
References: <jrdf56$61r$1 AT dough DOT gmane DOT org>	<CE9C056E12502146A72FD81290379E9A4361BBA1 AT ENFIRHMBX1 DOT datcon DOT co DOT uk>	<jrqjko$dc3$1 AT dough DOT gmane DOT org> <87pq8vxaok DOT fsf AT Rainer DOT invalid>
In-Reply-To: <87pq8vxaok.fsf@Rainer.invalid>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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 6/19/2012 3:18 PM, Achim Gratz wrote:
>
> I suspect that svn
> does not deal with the file being locked exclusively (when TortoiseSVN
> accesses the database) and some call through the windows interface
> blocked.

It's possible svn has a timer on the call that results in a SQL call 
through SQLite, and when this doesn't return as fast as svn thinks it 
ought to, it bombs out, complaining that there "must" be a disk I/O 
problem.  What may actually be happening is that Windows' aggressive 
locking strategy has set up a deadlock between two processes.

As for why .3 and .12 behave differently, it's probably because one or 
more locks that used to be owned by the SQLite DLL that are now owned by 
the Cygwin DLL.  That is, files are being accessed on the DLL's behalf 
by Cygwin now, rather than directly through the Windows API.  Since 
Cygwin doubtless does file I/O differently than SQLite did, for the same 
basic reason that any two programmers tend to write code differently, 
there's a new conflict.

If this is the case, the best solution may be for TortoiseSVN to stop 
grabbing files for long-term exclusive use.  It should only be locking 
the svn DB files as long as is necessary to make some change.

> Note that SQLite isn't really designed for concurrent access
> to the database file from a different process.

There is a paucity of truth in that statement.  See the SQLite FAQ:

	https://sqlite.org/faq.html#q5

But, there's only so much SQLite can do to cooperate with the OS's 
locking strategy.  On POSIX systems where SQLite was born, locking is 
mostly advisory and cooperative, whereas Windows gives you mandatory 
locks by default in a lot of cases.  Mandatory locks allow one process 
(e.g. TortoiseSVN) to deny another (e.g. Cygwin svn) the ability to 
change a file, indefinitely.

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