[From nobody Sat Oct 10 12:41:06 2026
Received: (at 960358-done) by bugs.debian.org; 10 Oct 2026 11:38:29 +0000
X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02
 (2024-03-25) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-6.2 required=4.0 tests=BAYES_00,DKIM_SIGNED,
 DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MD5_SHA1_SUM,SPF_HELO_NONE,
 SPF_NONE,VERSION autolearn=ham autolearn_force=no
 version=4.0.1-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 17; hammy, 92; neutral, 22; spammy, 0.
 spammytokens: hammytokens:0.000-+--H*F:U*ametzler,
 0.000-+--H*r:sk:ametzle, 0.000-+--H*RU:sk:ametzle,
 0.000-+--H*rp:U*ametzler, 0.000-+--Hx-spam-relays-external:sk:ametzle
Return-path: <ametzler@bebt.de>
Received: from vsrv21575.customer.vlinux.de ([31.15.64.248]:40318)
 by buxtehude.debian.org with esmtps
 (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
 (Exim 4.96) (envelope-from <ametzler@bebt.de>) id 1xFVPI-006INu-27
 for 960358-done@bugs.debian.org; Sat, 10 Oct 2026 11:38:28 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bebt.de;
 s=d2; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date:From:Sender
 :Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:
 Content-Transfer-Encoding:Content-ID:Content-Description:In-Reply-To:
 References; bh=I47NLzwtr+6/iLIRmDmbHyMIp9b7S3lVfCX8CMb/FcM=; b=DsXBUxzfUDZVBZ
 Tg72GYHGnYLcqt8a0fY2JwzcpdPr1fdD4sTKWjie5CFB3wqnj79y4qOnHk8hYezb0z4IV7rELtdmt
 kUkAyDTKJIq8VXRAwjxv3hQ/PgDTNcXtEN//smd2oDNRHnmO0BVcOANJtKsEFf7uYqlCowi63tBIz
 ju5Fm0c8GRYU2Jj6+Sulyy9bV1jm7TP5Fml5pHeEocHUfwEmxAv6KOOkel6PnV/Y71YrGZD+KkkeD
 VjyQLja0WJcHE/b46YtxGk8kYngoJXNxa26jrjWbAn31sOJg0JlL5Gfr3mtzumsQswmMV1n25XuDY
 rB9e6TzzWZLUNM/NxCMw==;
Received: from [41.66.122.26] (helo=argenau.bebt.de)
 by vsrv21575.customer.vlinux.de with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.100.1)
 (envelope-from <ametzler@bebt.de>) id 1xFVPD-00000001h0f-0a0l
 for 960358-done@bugs.debian.org; Sat, 10 Oct 2026 11:38:24 +0000
Received: from [::1] (helo=argenau.bebt.de)
 by argenau.bebt.de with esmtps (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.100.1)
 (envelope-from <ametzler@bebt.de>) id 1xFVPD-00000000OfR-1LUl
 for 960358-done@bugs.debian.org; Sat, 10 Oct 2026 13:38:22 +0200
Date: Sat, 10 Oct 2026 13:38:21 +0200
From: Andreas Metzler <ametzler@bebt.de>
To: 960358-done@bugs.debian.org
Subject: Fixed in 4.100
Message-ID: <asojrdEB-nVe6H_D@argenau.bebt.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Version: 4.100-1

This was fixed in 4.100 with commit
1da9c193f2851ca19edf72ac626d133521586491

Docs: correct NFS file locking advice for appendfile (closes #3147)

The use_lockfile description claimed fcntl() locking risks file corruption
on NFS while a lock file prevents it. As pointed out in the exim-users
thread [1] and Debian #960358 [2], that is unfounded: if fcntl() over NFS
works, it is sufficient; if it does not, a lock file does not rescue the
situation either (client-side caching can still let stale writes reach
the server). Rewrite the paragraph and soften the matching "always use
lock files" advice in the file option description.

cu Andreas]