DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 5ALA1LKt3657228 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 5ALA1LKt3657228 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=fdWyF192 X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 53E51385841F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1763719279; bh=uUx+7JLCZtq0vf/f5gzY9zEuS43b7zchu5Wvigq/WwM=; h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=fdWyF192XqsMe8ePL6KoSutGT4LAlvGfUkQnnrBBSrua8nd7ocF/hljBOqKaVC6PT nzzuYISK8Wwq1iTrTrgutEpn5t6Z5jzrPx3dTN8eScrkKjjao25zHrZeMX51hso0nj 48el0uR0ArOWmdoav9+UxyWO2TOfXQv1u0IZNHQw= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A3C9F3858CDB ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A3C9F3858CDB ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1763719213; cv=none; b=T7UG0ObLx01ACSNSvvOuEXE69sahdxrsBoqglnK0d/JlDHBFrjXpRNcr9p9txWCBrNC+cDDI6HX6C8rkHjI0UVjjej+111fwljUTgN1zaE+uBE9GcIdbnkBQ4edqfsRNFtof3UP+nXW6qBLdFAYcH3QArQdScwTKIw4dzHqBrvQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1763719213; c=relaxed/simple; bh=YqIzrT1HV5RblvVYXuB+E2gten4C2JietFUy8OOXL5Y=; h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature; b=j9zZRiTV/+lxN9cobKFSvmSAG0b4e7D7cYcLcngnyJn1uJjTjDlI+dGlOVLriHguAxnfsBqzgCs8lxgOsCDSLT5N10wU4ilAZm5DrV4AKfNF/rnwk4+mWYsPuzQt0Hn1Wl0xWx2PLv9kkosUW4ZQQd6JmJHYDygYC22yCt+vLIg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A3C9F3858CDB Date: Fri, 21 Nov 2025 19:00:09 +0900 To: cygwin AT cygwin DOT com Subject: Re: flock/open random error Message-Id: <20251121190009.f08a3229007bbbf101ad1463@nifty.ne.jp> In-Reply-To: References: <20251112182412 DOT ba3a65f36838b9b5fd7d3f9b AT nifty DOT ne DOT jp> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Takashi Yano via Cygwin Reply-To: Takashi Yano Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" On Fri, 14 Nov 2025 11:27:04 -0800 Nahor wrote: > If `flock()` was used on the same file descriptor, then this might > have been a valid point. However, each thread has its own file > descriptor in this case, so this would be very surprising if it wasn't > thread-safe. IIUC, flock() locks file itself, but not file descriptor. Usually, flock() is used for inter-process file protection, isn't it? > Moreover, it's not just `flock()` failing, it's also (and mostly!) > `open()` that fails. And it's the `open()` for a completely different > file than the one being locked. So that would suggest that `open()` is > not also not MT-safe. And not safe when using different files. And not > safe across multiple different functions (flock+open). Indeed, this is really weird. I looked into this, and found 'upath' in path.cc is destroyed after 'NtCreateFile()' call at the following line. I added assertion as follows: diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc index 710775e38..562100161 100644 --- a/winsup/cygwin/path.cc +++ b/winsup/cygwin/path.cc @@ -3189,6 +3189,8 @@ restart: symlink (which would spoil the task of this method quite a bit). Fortunately it's ignored on most other file systems so we don't have to special case NFS too much. */ + wchar_t c; + c = upath.Buffer[0]; status = NtCreateFile (&h, READ_CONTROL | FILE_READ_ATTRIBUTES | FILE_READ_EA, &attr, &io, NULL, 0, FILE_SHARE_VALID_FLAGS, @@ -3196,6 +3198,7 @@ restart: FILE_OPEN_REPARSE_POINT | FILE_OPEN_FOR_BACKUP_INTENT, eabuf, easize); + assert (upath.Buffer[0] == c); debug_printf ("%y = NtCreateFile (%S)", status, &upath); /* No right to access EAs or EAs not supported? */ if (!NT_SUCCESS (status) then, the assertion fails for your test case like: tmp_dir: /tmp/flockAQ4Hbb assertion "upath.Buffer[0] == c" failed: file "../../.././winsup/cygwin/path.cc", line 3201, function: int symlink_info::check(char*, const suffix_info*, fs_info&, path_conv_handle&) Abort Does another thread destroy the puthbuf? But pathbuf is thread local, IIUC. Corinna, have you noticed anything? > And more generally, I've never heard of file operations not being > thread safe. Atomicity and ordering are common problems, but not > thread safety. The linux man page for flock() does not mention about MT-safe https://man7.org/linux/man-pages/man2/flock.2.html while it mentions about MT-safe for https://man7.org/linux/man-pages/man3/lockf.3.html So I doubt flock() should really be MT-safe. -- Takashi Yano -- 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