DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 532HwA022921314 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 532HwA022921314 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=R2hyx5Vi X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2B5063858280 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1743616688; bh=VD3EOgZwir1ZTRhZ2dtvmPeySg0A8rSRBW1TtQ8sH9w=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=R2hyx5Vi4T4WNS/nYzjXznjY6eq/48RenhfTolvzHqXfy2ZoB8GNGsNClLTcDWdMT O0el5pq9dGw2EW32tVALRsZyP/xWOXbce9QLYYOCv6eIzUNERjWoAv0ykQtuoswtE3 px0SBNNTH+AZiuNR7BrN/XaCLscoHervUpqtlBJ0= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DB0973858D38 Date: Wed, 2 Apr 2025 19:57:03 +0200 To: Paul Eggert Subject: Re: symbolic link curiousity in 3.6.0 Message-ID: Mail-Followup-To: Paul Eggert , cygwin AT cygwin DOT com References: <1c0fb53a-2a6d-4d9d-8dbe-d70cc9296d5d AT draigBrady DOT com> <37f0f8b7-4251-4acd-b448-2f0d7c30a988 AT cs DOT ucla DOT edu> <675dac19-3c71-436f-93ce-e8f73b65b16c AT cs DOT ucla DOT edu> <8082949c-968d-44ed-b8c7-88bb239c3653 AT cs DOT ucla DOT edu> <1448648585 DOT 20250401130709 AT yandex DOT ru> <896fb3d5-e019-4261-9284-58c204f03da6 AT cs DOT ucla DOT edu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <896fb3d5-e019-4261-9284-58c204f03da6@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: Corinna Vinschen via Cygwin Reply-To: cygwin AT cygwin DOT com Cc: Corinna Vinschen , cygwin AT cygwin DOT com 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 Apr 1 15:32, Paul Eggert via Cygwin wrote: > > > traditionally (and I'm talking about 7th edition Unix) a single > > > output line of 'ls' corresponded to a state obtained atomically from the > > > file system. I realize we can't always do that nowadays but the further we > > > depart from it, the worse 'ls' users will be. > > The link dereferencing is a courtesy of LS, and in no way it is guaranteed to > > be stable in a long run. > > Not sure I get the point here. Although 7th edition Unix didn't have > symlinks, the idea that 'stat' should be atomic is valid even in the > presence of symlinks. > > Is your point that 'stat', which follows symlinks, might give results that > don't correspond to any state of the filesystem at any time in the past? If > so, I'm not sure I agree (at least for filesystems that do things atomically > as POSIX requires); if not, then I am not understanding the point. Requesting ACL information after stat was never atomic, and ACL information wasn't covered by 7th edition Unix. It's ok trying to make the output atomic, I just wonder if that's not too much hassle for not much gain. After all, even the filename could have changed while you call fstat() and acl_get_fd() even while you still have the same file handle open. So you have atomic display of stat and acl information, but the filename you're printing is already wrong. Or the dangling symlink isn't dangling anymore. Or vice versa. And O_PATH is still not standarized, so you should also allow the code to open the file with O_RDONLY, if you're going that way, I think. Corinna -- 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