From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28870 invoked by alias); 16 Aug 2012 19:52:28 -0000 Received: (qmail 28847 invoked by uid 22791); 16 Aug 2012 19:52:26 -0000 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 Received: from etr-usa.com (HELO etr-usa.com) (130.94.180.135) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 16 Aug 2012 19:52:09 +0000 Received: (qmail 79313 invoked by uid 13447); 16 Aug 2012 19:52:08 -0000 Received: from unknown (HELO [172.20.0.42]) ([71.210.206.56]) (envelope-sender ) by 130.94.180.135 (qmail-ldap-1.03) with SMTP for ; 16 Aug 2012 19:52:08 -0000 Message-ID: <502D4F2F.5080306@etr-usa.com> Date: Thu, 16 Aug 2012 20:41:00 -0000 From: Warren Young User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: Options for getting mandatory locking in cygwin1.dll (was: Promote sqlite 3.7.13-1 from test status?) References: <502C0B7D.10909@etr-usa.com> <20120816085016.GB5536@calimero.vinschen.de> <502CCBB1.2070600@etr-usa.com> <20120816105507.GD17546@calimero.vinschen.de> <502CE120.4050900@etr-usa.com> <20120816122654.GG17546@calimero.vinschen.de> In-Reply-To: <20120816122654.GG17546@calimero.vinschen.de> 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 Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2012-08/txt/msg00395.txt.bz2 On 8/16/2012 6:26 AM, Corinna Vinschen wrote: > On Aug 16 06:01, Warren Young wrote: >> Advisory locking only works when all players cooperate. We can't >> assume that on Windows, unless we set up an insular Cygwin ghetto. > > So, are you saying that Cygwin should use mandatory file locking? Of course not. That would be a disaster. > You are aware that there's no chance at all to implement the UNIX > locking API calls correctly this way since Windows locking has nothing > in common with UNIX locking except for the word "locking". Not even on a per-process basis (cygwin_set_mandatory_locking(1)), in conjunction with fcntl(F_SETLK)? That's how SQLite's unixFileLock() function is implemented. That is, this proposal would put the DLL in a mode where it called LockFileEx() to establish the reader/writer lock byte ranges instead of using its private advisory locking scheme. Alternately, Cygwin could follow Linux and implement 'mount -o mand'. You could get mandatory locking on just your svn checkout tree this way, for example. It would apply to all Cygwin programs, not just svn/SQLite, but it shouldn't be any more problematic than normal day to day Windows use. Cygwin programs not run within that mount wouldn't be affected. I'm aware that fcntl(F_SETLK) isn't thread-safe[1] but we're arguing "if it's good enough for Unix, it's good enough for Cygwin" here, aren't we? The other objection in reference [1] is that it doesn't work with NFS, which doesn't matter to us here, I think. If neither of those proposals will work, I think we'll have no choice but to continue to try and chase a SQLite specific solution. You can't fix it on the Windows native side of things. I doubt you can fix it in Subversion, and even if you could, that's no better than fixing it in SQLite. Worse, actually, because then you've got a fix that affects only one program, not all SQLite dependents. [1] http://0pointer.de/blog/projects/locking.html -- 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