X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=G/raxLmJYmDLteu9TKgs6SYKAjK/527Kxr/n1uy1bP/
	y7txKqErSvIoqU+cXPnsiZajFTZeVlFEn9/zH+OjSgaIdebyFBa0qZms7zRFHsLF
	GKvQbIcuI8STxZfXMOwqSqQ09XrIiQt6mMnVAm1EjqMqaEwM74NqzP+Pif++wgDA
	=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 s=default; bh=bKKeg8Y3zLeR+acbx7O5w7iNaiI=; b=aNmHheY5WOe29ACPu
	p4UMORNpZCC1EcVSPFlfM1ujrcUmPZag8eLfW2jfxZ+awVxl/9s+i6XocMNbLi0l
	MBQYQ2jLj8L5h/qW7z4oWOePjY2vt0gFHYLBQiiQz9jZKICxhKvUqsyHtA6/10VC
	N562b+WNKy0C58/2AJQhFLemY4=
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
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_50,KHOP_THREADED,RDNS_NONE autolearn=no version=3.3.1
Message-ID: <51E74AB4.7010508@etr-usa.com>
Date: Wed, 17 Jul 2013 19:53:56 -0600
From: Warren Young <warren AT etr-usa DOT com>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Cygwin-L <cygwin AT cygwin DOT com>
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>
In-Reply-To: <trinity-1068d666-3dec-43c9-8453-39c7cae3a94c-1374102947415@3capp-gmx-bs33>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 7/17/2013 17:15, fger555 AT gmx DOT de wrote:
> Von: "Warren Young" <warren AT etr-usa DOT com>
>> try setting the new CYGWIN_SQLITE_LOCKING environment
>> variable to "posix".
>
> Why isn't it the default?

Because there are more native Windows programs based on SQLite than 
there are Cygwin programs based on SQLite.

Since we cannot interoperate with both sets of programs at the same 
time, we chose to interoperate with the larger set by default.

> I copied the mozilla places.sqlite bookmarks file to a backup directory

This at least gives me a way to reproduce it.

For anyone else who cares:

$ cp ~/AppData/Roaming/Mozilla/Firefox/Profiles/*/places.sqlite /tmp

(~/AppData is a symlink to the obvious location on my machine.)

$ sqlite3 /tmp/places.sqlite .schema

The query string can be anything that causes it to access the DB file. 
So, it can't just be ".quit", for example.

I've done some strace diffing, and the problem seems to happen outside 
the Cygwin DLL, immediately after the new locking code is called:

> read: 32768 = read(3, 0x80054620, 32768)
> flock: 0 = flock(3, 8)
> fhandler_pty_slave::write: pty0, write(0x40A502, 7)
> fhandler_pty_slave::write: (654): pty output_mutex (0xBC): waiting -1 ms
> fhandler_pty_slave::write: (654): pty output_mutex: acquired
> fhandler_pty_slave::write: (669): pty output_mutex(0xBC) released
> write: 7 = write(2, 0x40A502, 7)
> fhandler_pty_slave::write: pty0, write(0x80053FF0, 28)
> fhandler_pty_slave::write: (654): pty output_mutex (0xBC): waiting -1 ms
> fhandler_pty_slave::write: (654): pty output_mutex: acquired
> fhandler_pty_slave::write: (669): pty output_mutex(0xBC) released
> write: 28 = write(2, 0x80053FF0, 28)
> fhandler_pty_slave::write: pty0, write(0x40A50B, 1)
> fhandler_pty_slave::write: (654): pty output_mutex (0xBC): waiting -1 ms
> fhandler_pty_slave::write: (654): pty output_mutex: acquired
> fhandler_pty_slave::write: (669): pty output_mutex(0xBC) released
> write: 1 = write(2, 0x40A50B, 1)

Distilled, what this says is that it successfully read()s from the DB 
file it has open (fd=3), then it successfully flock()s it, and then for 
reasons I don't understand, does 3 write()s to stderr.

The mystery is what happens between lines 2 and 3, and for that I don't 
see anything for it but to dive back into the SQLite code.

> Does the sqlite file contain a locking flag inside?

Nothing so simple.  Locking is handled at the OS and/or Cygwin DLL 
level.  The build change between 3.7.16.2 and 3.7.17-3 is that we're now 
relying on new features in the Cygwin DLL to do Windows-style locking by 
default.

Older versions of Cygwin SQLite bypassed the Cygwin DLL entirely for 
this, going straight to the Win32 API, thereby preventing the DLL from 
interposing itself for the "posix" case.

> With the old version
> I never had a problem to access the files.

Yes, well, other people did have trouble with the old version, which is 
why we tried giving locking responsibility to the Cygwin DLL.

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