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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=TjQkcKhu3SZr7U7hgz1ILgoHpX80jAR2tTm2PwF7OdAWId5FjCwRw
	FDCSj5YeAnCDGMeEivgcn3hwfPVu+qz3RxBmFRzK3yiHQ7b4B5u8MCh3/VYUDsnZ
	y0cpfrx/rVOV84SEPeEUBWAWm6+W6rSi7MYlwmCqbbNZTBx1Q0lcek=
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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=IYpKa9q1F7zPqQgdv6Fl2zUZUeE=; b=IjRVnvO0cozN9qywyFoJYrmI8sKN
	CZDB68vofgVKs3EatvJSprvwv0H7tO8M/Ce4iwBl66Fu/U6IDQFTg+a9SzYeAo4Z
	AE7xvxlVUBBSmZbdFBf3qm69livpwv0mfTsL+N8K0IZlUTDrKjvV15ZHhZksayOh
	2GhWZ3yze71q9RI=
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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1
Date:	Wed, 5 Jun 2013 19:02:46 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Mandatory file locking semantics (was: sqlite3: bug with monotone)
Message-ID:	<20130605170246.GD3250@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<51A7862F DOT 1070507 AT etr-usa DOT com> <51A7D47E DOT 3050502 AT users DOT sourceforge DOT net> <51A7F547 DOT 6020509 AT etr-usa DOT com> <20130531092228 DOT GB30659 AT calimero DOT vinschen DOT de> <51A900EF DOT 2020606 AT etr-usa DOT com> <20130601105741 DOT GC30659 AT calimero DOT vinschen DOT de> <20130602103125 DOT GE13934 AT calimero DOT vinschen DOT de> <51ACD415 DOT 2090709 AT etr-usa DOT com> <20130604084815 DOT GD19572 AT calimero DOT vinschen DOT de> <51AF6433 DOT 5050104 AT etr-usa DOT com>
MIME-Version:	1.0
In-Reply-To:	<51AF6433.5050104@etr-usa.com>
User-Agent:	Mutt/1.5.21 (2010-09-15)

On Jun  5 10:15, Warren Young wrote:
> On 6/4/2013 02:48, Corinna Vinschen wrote:
> >On Jun  3 11:36, Warren Young wrote:
> >>Could you add an O_MAND open(2) option as well to turn on the same
> >>feature?  This will avoid a race condition.
> >
> >If you call F_LCK_MANDATORY right after open in the opening routine,
> >there won't be (much of) a race.  I know what you mean (it's the
> >O_CLOEXEC dilemma)
> 
> As long as everyone plays by the rules, there actually isn't a race.
> 
> For this style of locking to work at all, every program involved has
> to enable the mandatory locking flag before doing any I/O on the
> file.  In that sense, locking is already atomic.
> 
> Adding O_MAND changes the call pattern from:
> 
>    fd = open(..., O_RDWR);
>    fcntl(fd, F_LCK_MANDATORY, 1);
>    fcntl(fd, F_SETLK, &lock);
> 
> to:
> 
>    fd = open(..., O_RDWR | O_MAND);
>    fcntl(fd, F_SETLK, &lock);
> 
> Since there are two required calls due to the POSIX design, there's
> still a hole here, where an uncooperative program could call open(2)
> for writing on the same file without acquiring the lock.  To fix
> *that* race condition, you'd need an extension to open(2) that lets
> it acquire the lock on open.  That just isn't in the cards.

Advisory locking is *based* on cooperative behaviour.  That means,
the assumption is that all applications accessing certain files
behave like they should and not write to a file before asking for the
lock.  In your case, there's the sqlite lib.  If every application
accessing an sqlite db uses the sqlite lib, there's no reason to
assume that there's an uncooperative application.

> Or am I missing something?  Does mandatory locking on Linux or SysV
> somehow avoid the "uncooperative program" race?

Not at all.  Did you read Section 0, "Why you should avoid mandatory
locking" in Linux Documentation/filesystems/mandatory-locking.txt file?
It's all about races.

> That having been said, I still think O_MAND works better.
> [...]

Again, to be clear: Mandatory locking is not for the every day use of a
Cygwin application.  I provided it for the sake of a *very* limited
scenario, where Cygwin applications have to cooperate with native Windows
applications using record locking.  The burden to use it correctly is
on the application developer.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

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