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:content-type:mime-version:subject:from
	:in-reply-to:date:content-transfer-encoding:message-id
	:references:to; q=dns; s=default; b=gU9QM+IEm5cGA6nbzF6IFJEGSEdM
	4y34k3YqBKLxMOwWyroLb9rClfBjvWNSG/bMhWrSWg3zWKT1zr1wjy8Vj6TWL/e5
	x/veX6NaO8Lq+SbCx+CDLsM9LOGEPKHlIBLAxGOvSzX5B5gcM9XWsrABU+RSY88A
	T1ZoBPNTI/3Jylg=
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:content-type:mime-version:subject:from
	:in-reply-to:date:content-transfer-encoding:message-id
	:references:to; s=default; bh=0dyVSqU9N2CI4mm1+zyFl/M64E4=; b=fB
	2JFzBGXnTq0hcbeBVmH6erUALr5BhBh4a7eOw9cz1fCKBHGsbSnXdYX7lqhfbb6r
	NKMbFdHvw1Rv+1Dq43YRgxOxNaP7IKVvtN51n/B0Zvyaz7NGDA1sGySdgbYsCUsG
	KQDO/4MqARGKudFxZMwXuJzfCRXeIL+9hAUs114hE=
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=1.6 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=sk:anrdaem, anrdaemon AT yandex DOT ru, anrdaemonyandexru, U*anrdaemon
X-HELO:	etr-usa.com
Mime-Version:	1.0 (Mac OS X Mail 9.3 \(3124\))
Subject:	Re: Unreliable flock
From:	Warren Young <wyml AT etr-usa DOT com>
In-Reply-To:	<59768064.20160404195111@yandex.ru>
Date:	Mon, 4 Apr 2016 13:24:03 -0600
Message-Id:	<32A7A4DF-AC8E-4586-A9A7-989694FBE733@etr-usa.com>
References:	<175808986 DOT 20160403002257 AT yandex DOT ru> <20160404151644 DOT GB29337 AT calimero DOT vinschen DOT de> <59768064 DOT 20160404195111 AT yandex DOT ru>
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id u34JORmS022898

On Apr 4, 2016, at 10:51 AM, Andrey Repin <anrdaemon AT yandex DOT ru> wrote:
> 
>> BSD file locks created via flock are only propagated to the direct parent
> 
> that's a showstopper. In short, it makes the function literally useless.

Nonsense.  That’s only true if “literally” every program that uses BSD locks creates grandchildren that also need to use those same locks.

I know of one program for certain that uses BSD locks under Cygwin that doesn’t create grandchildren, and its extensive test suite passed with Cygwin/BSD locks the last time I ran it.

> Why they aren't real locks? What's use for "advisory locks”?

“Real” locks are generally not what you want when running purely Unix/Linux software under Cygwin, because that’s not what you get by default on Linux or Unix.  You have to go out of your way to get mandatory locking on POSIX systems, as a rule.

Mandatory locks aren’t purely positive.  They’re the single biggest reason Windows still needs a reboot for many kinds of upgrades, while Linux generally only has to be rebooted for kernel or glibc upgrades, and the latter is, strictly speaking, optional.

> "I think I may
> have a use for this file, but you are free to delete it, if you wish” ?

Among cooperating processes, that’s perfectly fine.

Consider SQLite.  On a system where SQLite decides to use some form of advisory locking, the primary risk of damage isn’t rm or dd, it’s another copy of SQLite coming along and writing to the DB while the first is in the middle of a transaction,.

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