DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52VHT5Am1848872 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 52VHT5Am1848872 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=YeQAq5su X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BE7153865C24 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1743442143; bh=Tid8kXPh7W91S/0w+/0PICOT12lmGmN0GeBkAkdA2UU=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=YeQAq5suITHUqjZMxGrP4zSNmqlufn+y1+CyAcYg+Nf+lUzIPI9XCsvYO1Y0qSVUu sXpxqZX4LDMh6CKhKsqAvwBzKBI3RsCx4GsncLpVlJMQ3AMxBCjVgSAJ8fhG2nqKf9 GAlxrQ3iVtTFnv3eai21W+085p4384ODa+GylGzU= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D046F385AC21 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D046F385AC21 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1743442082; cv=none; b=mab74vXode8f6QDsjoa53q/cktKdaLxkLyblzLxK0z6URcciU14yjZSEyAAFBehD6P85o123BuJ4H0WH7a+WzYrHFuEWaBsPCEkPr01uRCWlGYwdbu5QBYHNXvv40h2Xi6DiR6DQVcg6FPU7ho4T1QTnRi9UF1ccwXkum1n6/4g= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1743442082; c=relaxed/simple; bh=CywarPgI3FX6CDITqTf3rKOysTaVGvZU5czkST0tUpY=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=HvhrBBEKNQi7YpmC+2syvTXq0Xnyt7UJ6jyXEQBnSQYZK3xEqnwpUPpP5m0EKS7tnRovwbe+MFcQ5CvlSWC+xhJRMRczAFLLF3bokZpBv9CQjeu7PyLOBBC1EWfV4nYVntkhKQHSJXsBSYWMQhpFTGVlmbEYty1Miozli+janbI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D046F385AC21 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743442080; x=1744046880; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2l6lz4qsYuPOOxMpZrgF8pNB4fIFqIvZNLq+hKxumm4=; b=cQx/V4gIemUs6SVVswyMVsHJcy4X0w2KdgkJpJMMrxr5wHM2L95vdyp/lLH4t9nsOI 44gBQSYsiU4Pjb+RH8Zvzj7EdEqCO9+6R52er/mSCrIvoc61somWoGHuRTExV1rRcgvj xSJ5GUD6+9pYI20CapytCzGQsJYkQudsthMooWLNDkh671Y7hEk14ZyoizBAeEZ7AaK+ Mzy8BBgyTJNradsFyy6eTpBhgsmtCqGBPuGaEUbpmsMdXyvlNjnGt4P+YLWlNx2V+Aci ngtcuKgLHtWsOv758yoJUfW7wsatMBeMChEj2WVdsP7x9FeViw2comtixG42PBw7KrUA CPGw== X-Forwarded-Encrypted: i=1; AJvYcCXTVo6Q1Zu3GhwYvDElM8bkhdivCSxGZdPXkvX6LFObExyWnhbhwERjEpYkEhkBmaMAuEKezoQ=@cygwin.com X-Gm-Message-State: AOJu0YzC1yGMGKKoFoOOCoaUNqmOPGe0lDmP70FtOGh1SpSCjq5bgjc9 NcU0BZpbHYfGF5UZco8UR6v/64+VaDPsjaDzlZH4RDGZo5J7SITm X-Gm-Gg: ASbGncvVrmjJplbnonS5mpoNXpP4jd2P2VIKoE9BaO9yT07Nku4NhSuEtCUg2wv1nXx nuM1Flb98xfh7SUtnVWXU0+QXYYQkSzO35K25q9ZAtdihrDFWFGaKIpPi3lB0214txEt2z3BWA0 48tWJLXGCCEB8xXPOzCd97OmyRLXTZ3YiSVpcDpYkD8gYDYxTnPoEXv04CD3Nhx1tDkArrheAaU ZQwd7FPC+yhE9ldDYUhxPlSGbeF9A5ByWMtjHogGirHlHvSwW5nWEAlvj/4R3ldgIZxwVEUIQj+ U6Kcw6w75/1uDeCjyhoJAIxh8ejdGpEtU0c13LfQETy5J2TFKIpBrZX8wFM+kOaAafIe71VcLYZ /orCWa14NULrbrSi6r6ZLC5+c X-Google-Smtp-Source: AGHT+IHiW3xIdyJe554WOnywRUIiEvJTujg1dFWm3qMQoUAmbbKDzN1ZXk9tEatZ/VuIdfjwioqibg== X-Received: by 2002:a05:600c:8117:b0:43c:efed:732d with SMTP id 5b1f17b1804b1-43e8e3cf858mr90801585e9.16.1743442080206; Mon, 31 Mar 2025 10:28:00 -0700 (PDT) Message-ID: Date: Mon, 31 Mar 2025 18:27:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: symbolic link curiousity in 3.6.0 To: Paul Eggert , Bruno Haible , bug-gnulib AT gnu DOT org, cygwin AT cygwin DOT com, Coreutils References: <11037686 DOT 3WhfQktd6Z AT nimes> <91c9d441-36e3-4dd5-b2ca-3cfd498d2260 AT draigBrady DOT com> <1c0fb53a-2a6d-4d9d-8dbe-d70cc9296d5d AT draigBrady DOT com> <37f0f8b7-4251-4acd-b448-2f0d7c30a988 AT cs DOT ucla DOT edu> Content-Language: en-US In-Reply-To: <37f0f8b7-4251-4acd-b448-2f0d7c30a988@cs.ucla.edu> 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: =?utf-8?q?P=C3=A1draig_Brady_via_Cygwin?= Reply-To: =?UTF-8?Q?P=C3=A1draig_Brady?=

Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 52VHT5Am1848872 On 31/03/2025 17:32, Paul Eggert wrote: > On 2025-03-30 07:26, Pádraig Brady wrote: >> On 30/03/2025 13:50, Corinna Vinschen wrote: >>> In terms of coreutils, I think either ls(1) gobble_file() or >>> file_has_aclinfo_cache() should still handle ENOENT from >>> file_has_aclinfo() and not print any error message.  After all, due to >>> the preconditions for building acl_get_link_np, we can't be sure >>> acl_get_link_np has really been built into file-has-acl.c, and the >>> problem persists. >> >> I tend to agree. I'll apply this later: >> >> >> commit 88385a0d6d56197d3c180432c8a4bca07241e90b (HEAD -> master) >> Author: Pádraig Brady

>> Date:   Sun Mar 30 15:16:54 2025 +0100 >> >>     ls: suppress ENOENT errors when reading ACL info >> >>     * src/ls.c (gobble_file): Indicating unknown ACL info with '?' >>     suffices for the edge case of a file being removed while reading, >>     or older cygwin when reading through dangling symlinks. >>     Reported by Corinna Vinschen. > > Not sure this is a good idea, as a file being removed while getting its > attributes indicates a serious issue that's worth bringing to the user's > attention more directly. I don't think this is a serious issue. The file could be deleted at any time. We're just suppressing errors in the edge case it's deleted in the small window between the stat() and the acl_get_file(). We of course don't guarantee a file is present after we list it, so we shouldn't jump through hoops for this edge case I think. > How about if we instead use O_PATH on the file first, and then use fstat > etc. on the result? That should fix the > file-removed-while-getting-attributes situation, at least on platforms > with /proc/self/fd (which I assume includes Cygnus). I realize that > flistxattr etc. don't work on fds opened via O_PATH (why? this seems > silly, but it's not my bailiwick) but /proc/self/fd works around that > problem. cheers, Pádraig -- 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