X-Recipient: archive-cygwin@delorie.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 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 Subject: Re: cygwin 1.7.15: svn disk I/O error References: <87pq8vxaok.fsf@Rainer.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@cygwin.com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.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