DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 5B4CM7u3560504
Authentication-Results:	delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results:	delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter:	OpenDKIM Filter v2.11.0 delorie.com 5B4CM7u3560504
Authentication-Results:	delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=QGIzI0C9
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org C7DE14BC89B4
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1764850926;
	bh=WYQQmCyrOdY3FdpFeQdPXo8AaWOjyMtPPLew6xfb+xo=;
	h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	From;
	b=QGIzI0C9Ib4uDzehF0gI6ZDxU9JPGBu/k2FH4oXkY6XtMk8Fo5Id9SZczZ3qJ2NC0
	bAxJwaL4w4nGkyWPbecMJK1hIngImw6v/r5jtlbx+/G+/Dt1w+qBVAqEr+3GbnvsQ7
	bcoA9DVhWanbKLl2qNAAWuU9o3Phe+WVibXYxPLc=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org 2EB0A4BA2E00
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org 2EB0A4BA2E00
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1764850878; cv=none;
	b=dg7fSI2MzF+kMJijUnOBf3Iwn4LdgN1uwxySdCQ25toWwgjH9nz3lpHjZXFnfaUni6CJJTo+dfe892ylfRN7qkGaThfnlvc97DWJrrnkhnv4njOE1ZQMJBCtJB9dRT7suQYyCS4/995YGvcanrmzZ3u0yQAgTdQjfMd+DIGrShk=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1764850878; c=relaxed/simple;
	bh=iNq3QeWsHqBJd8MtFYqncK4pcwTZ+I/AvF3nz6gvFmk=;
	h=DKIM-Signature:Subject:To:From:Message-ID:Date:MIME-Version;
	b=kep1iyHdoRSDXi1Uvi+NlClQSLlDrT13n0tGefOxQSLmBbB+/9q+KA1sNDeA7DKKPFssAFNfGUAXRs/dpFUMeyjiXOMry7a99aiLWAQj+EAjxuz/kCzslTv7YV5sCzAM1AgvFavtou8sUl0cKymjN1fm+p54SoqCp4z/nnt+5gY=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 2EB0A4BA2E00
Subject:	Re: flock/open random error
To:	cygwin AT cygwin DOT com
References:	<CA+1R0VjcBajGpLMJ_0Waie0g_5S15_kPfzpT2=GUyN+39RWrMw AT mail DOT gmail DOT com>
	<20251112182412 DOT ba3a65f36838b9b5fd7d3f9b AT nifty DOT ne DOT jp>
	<CA+1R0VjW5rbKAVBb_vAFqKcKmE0yfvOFi6i0-GB=2-mjOhCY7A AT mail DOT gmail DOT com>
	<20251121190009 DOT f08a3229007bbbf101ad1463 AT nifty DOT ne DOT jp>
	<CA+1R0VjRuU2V_j7aF4=_8KQa4E7D7dH071euo=Fdpweq8NH8mg AT mail DOT gmail DOT com>
Organization:	WiseMo A/S
Message-ID:	<5d07cf29-9adc-4279-1f96-fdca0637c3ef@wisemo.com>
Date:	Thu, 4 Dec 2025 13:21:17 +0100
X-Mailer:	Epyrus/2.1.3
MIME-Version:	1.0
In-Reply-To:	<CA+1R0VjRuU2V_j7aF4=_8KQa4E7D7dH071euo=Fdpweq8NH8mg@mail.gmail.com>
X-Content-Filtered-By:	Mailman/MimeDel 2.1.30
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Jakob Bohm via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Jakob Bohm <jb AT wisemo DOT com>
Errors-To:	cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 5B4CM7u3560504

On 23/11/2025 06:48, Nahor via Cygwin wrote:
> On Fri, Nov 21, 2025 at 2:00 AM Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp> wrote:
>> IIUC, flock() locks file itself, but not file descriptor. Usually,
>> flock() is used for inter-process file protection, isn't it?
> It's kind of fuzzy:
> - on one hand: "Locks created by flock() are associated with an open
> file description" (Linux man page)
> - on the other: "Locks are on files, not file descriptors" (BSD man page)
> Either way, they both follow up by saying that if the descriptor is
> duplicated/forked/etc, the copies will share the lock. But then that's
> not my issue.
 From my experience with MS-family file locks, I would say that the locks
are applied to the underlying file/inode as seen by the OS, but are each
held by the file descriptor through which they were "taken".  Thus
closing that file descriptor by any means (close(), dup2() on top,
execve(), exit(), kill() etc.) will implicitly release the lock. to
(dup(), inherit etc.) a file descriptor that holds a lock may or may
not cause that lock to be held by the set of mutually duplicate
descriptors, as the lock is really held by one of the internal objects
that implement the file descriptor concept, and more than one file
descriptor may refer to that same internal object which in turn holds
a lock on the underlying file/inode.

Put another way, each numeric file descriptor (such as fd=4 in pid=12345)
points to an underlying shared "file descriptor object", which in turn
points to other such objects, until reaching the object that owns the
lock and points further down, until finally looking at a disk inode.

-- 
Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 
<tel:+4531131610>
This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -