From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 59C3A1FF141 for ; Tue, 30 Jun 2026 17:02:29 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id EB93B21425; Tue, 30 Jun 2026 17:02:28 +0200 (CEST) Message-ID: <5d997f60-a0c2-4c14-94b7-832936761a68@proxmox.com> Date: Tue, 30 Jun 2026 17:02:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 proxmox 2/2] fix #7690: proxmox-sys: close fd before rename/unlink in replace_file To: Robert Obkircher , pbs-devel@lists.proxmox.com References: <20260617105000.232928-1-r.obkircher@proxmox.com> <20260617105000.232928-3-r.obkircher@proxmox.com> <0fb3fc84-c8cc-4cc8-be71-5bcdf4e95132@proxmox.com> <75c9d389-0cd5-4a24-91f6-39cbc96c75b1@proxmox.com> Content-Language: en-US, de-DE From: Christian Ebner In-Reply-To: <75c9d389-0cd5-4a24-91f6-39cbc96c75b1@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1782831732154 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.000 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: NIX7DSNPI4HK5BXS3CHUXW7475RTNIZ3 X-Message-ID-Hash: NIX7DSNPI4HK5BXS3CHUXW7475RTNIZ3 X-MailFrom: c.ebner@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox Backup Server development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 6/30/26 3:24 PM, Robert Obkircher wrote: > > On 29.06.26 13:18, Christian Ebner wrote: >> On 6/17/26 12:49 PM, Robert Obkircher wrote: >>> Fix the rename operation on WORM file systems and allow FUSE file >>> systems to unlink without creating temporary .fuse_hidden files. >> >> question: what about other helpers using a similar pattern when >> removing a temp file in error case, e.g. unlink() after file content >> writing or fsync() failed while still holding an open file >> descriptor in atomic_open_or_create_file()? These will produce the >> .fuse_hidden files as well? > I think so, but .fuse_hidden files are not really harmful, and it > seems like we mostly use that function for lockfiles outside of > datastores. Okay, thanks for clarification. Was unsure if these could cause issues for the mentioned WORM filesystem implementation as well, so wanted to mention these as well. > Should I write a test to verify when .fuse_hidden files are created? I > didn't bother because I wasn't sure how to create a fuse file system > in a test. Not really worth the effort for the time being, unless we do want to explicitly support such FUSE based filesystems in the near future. Correct me if I'm wrong, but I'm not aware of active efforts to do so. > But it also seems a bit strange to me that we use mkostemp and > path-based renames in the first place. Creating the file > with O_TMPFILE and linking it into place would definitely be safer.