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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type
	:content-transfer-encoding; q=dns; s=default; b=KluStmfuJWr7xrY7
	TCNkfiOiuJCKFF7f4oWVGdwQinMvNWR+N+Uo1a7EDF9HKrhPdv2HCypF3ZDQarxx
	hv0N0rPAXPNRGOH2fo0vCxV7xdxQwsX4V7V5ypWokj13cal0nS3NC6NGyF0MdRxu
	MuNPQ7cszgS3tL4WtlJo73TsVvc=
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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type
	:content-transfer-encoding; s=default; bh=NedQhSVStAYrWwEhXlp+Na
	1bn9M=; b=P3l2PwvrQ66cHB6I0QIeGGBWBN/EBH3ZF0yu9lJYhbTgrdTvN+mvlV
	NfPmJXO1LVH1Q4hiM44mpFRqvZbY5fQEKHUBI5JXnmU/NVxIhltS9ScfEshFz6Jz
	Y/ecN8yn/h8ZJYGFtEEmHiPYAJbsHCv+qaSBGxSBpe7+Buf1wCrK4=
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
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-0.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO:	mail-lb0-f174.google.com
MIME-Version:	1.0
X-Received:	by 10.152.204.70 with SMTP id kw6mr44432934lac.53.1421177760939; Tue, 13 Jan 2015 11:36:00 -0800 (PST)
In-Reply-To:	<D5908A8D-69EA-48CB-ABBD-4AFFF9B9BB5C@etr-usa.com>
References:	<CAO1jNws2XKcySKD0Lzi-C2hWS=pcdHQ7sCSNJADU4qEtgej28A AT mail DOT gmail DOT com> <3949B731-0E84-464F-A5D7-837D31ABF25E AT etr-usa DOT com> <CAO1jNwto=M6YZ_Q-zY-qcBVvWLNkTnyrPSPticUywSg3pWjW4Q AT mail DOT gmail DOT com> <D5908A8D-69EA-48CB-ABBD-4AFFF9B9BB5C AT etr-usa DOT com>
Date:	Tue, 13 Jan 2015 20:36:00 +0100
Message-ID:	<CAO1jNwvTJXtGBtA1AzC6P92Uij8FvnDu7G9Jq=dac21MSNXyBw@mail.gmail.com>
Subject:	Re: Updated: sqlite3-3.8.7.2-1 for Cygwin/Cygwin64
From:	Jan Nijtmans <jan DOT nijtmans AT gmail DOT com>
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id t0DJaJf0030453

2015-01-12 19:55 GMT+01:00 Warren Young <wyml AT etr-usa DOT com>:
> Example disaster scenario:
>
> Someone installs Cygwin Fossil, and exposes its critical _FOSSIL_ file to a native Windows program that could modify it.  Then all you need is a situation where both programs try to modify it at the same time, and you get DB corruption because they aren’t agreeing on locking semantics.


Another disaster scenario:

Assume someone has tortoisesvn installed, and has a project
checked-out from an SVN server somewhere. The "foo" project
builds a foo.exe cygwin executable, which uses a sqlite repository
located on a shared drive, which is accessed by some
UNIX machines as well. Therefore the "unix" locking is
chosen for interoperability. The user decides to set the
CYGWIN_SQLITE_LOCKING environment variable to
"unix-posix", that's the easiest way.

As soon as tortoisesvn accesses the checked-out working
copy of the "foo" project, it's just a matter of time waiting
for the working copy to get corrupt: Both tortoisesvn and
cygwin svn access the same sqlite database, but they
don't agree on the locking semantics. It's not immediately
clear from this example that svn uses sqlite too, setting
the CYGWIN_SQLITE_LOCKING environment variable
causes this problem.

Remedy: All executables on the same machine should
use the same locking semantics, which can be done
by using the default VFS. Using any other VFS should
be discouraged.

> I created it to solve a Cygwin-specific problem.

Yes, and this problem is solved now in the default VFS.
There should be no reason any more to use another than
the default VFS (except in some special situations like
described above). That's what I recommend.

If you know of any situations where the default VFS
mis-behaves in cooperation with other (win32 or cygwin)
programs on the same machine, I'm interested
to hear all about that. But - so far - no-one reported
such a situation to me.

Regards,
        Jan Nijtmans

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