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=IVCT6/miYB26z7pTnxZS4QNXLpfLr9hiEZZTOxP/neA
	YHzw2+mPe+phgZOdy9LwdmPT5d9cL6EeWbGqAmwlfPyQ5qD6gnj3jnNDu2UROofm
	16QTUsPuQ8MXjdGeYvi8NXXgV0u5iTAIm3iLCPzWxglEXE5Ml0VOBbjp14nLp0KI
	=
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=QfmWP9Cz44izNBpLBoZeKfBdBoA=; b=muSOD94lZ8LlhYYj5
	eGc1ZRpRFkgY/2o0u8sdbTjtni8/cmhsn89IiBpXuhU8YZuF/ny6Ro4Net3Lck+O
	YEiazaHAwYEWU0QlP2uQUyB48BVyLeiZQuZZjyYt9gUnZO0dR4dRovHVeeZ6ImjN
	3RWrYnUAda1QSyGgMxDdWbqWQE=
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=-4.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD autolearn=ham version=3.3.1
Message-ID:	<51AF6433.5050104@etr-usa.com>
Date:	Wed, 05 Jun 2013 10:15:47 -0600
From:	Warren Young <warren AT etr-usa DOT com>
User-Agent:	Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: Mandatory file locking semantics (was: sqlite3: bug with monotone)
References:	<51A6B6EB DOT 6050309 AT users DOT sourceforge DOT net> <loom DOT 20130530T122354-144 AT post DOT gmane DOT org> <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>
In-Reply-To:	<20130604084815.GD19572@calimero.vinschen.de>

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.

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




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

Cygwin's mandatory locking is effectively a flag on the file that, once 
set, stays with the file descriptor as long as it is open.

You can later unset the flag, but under what condition would that ever 
be the right thing?  That effectively tries to mix locking semantics on 
the same file descriptor!

The F_LCK_MANDATORY design also allows you to do arbitrary I/O between 
open() and setting the flag, another thing which can never be correct. 
It violates the rule laid out above that allows two Cygwin programs to 
cooperatively enable mandatory file locking "atomically".

If a Cygwin program wants mandatory locking, it should be enabled 
continuously from open() to close().



If those weren't enough reasons, it now feels weird that you use fcntl() 
to set the locking flag even when you're going to use flock() or lockf() 
to do the actual locking.

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