DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 532HwA022921314
Date: Wed, 2 Apr 2025 19:57:03 +0200
To: Paul Eggert <eggert@cs.ucla.edu>
Subject: Re: symbolic link curiousity in 3.6.0
Message-ID: <Z-16b12ha13K7DQH@calimero.vinschen.de>
Mail-Followup-To: Paul Eggert <eggert@cs.ucla.edu>, cygwin@cygwin.com
References: <a78f800c-0463-4efb-b431-c2c244bd13c7@cs.ucla.edu>
 <Z-k-ALeeYtJx7SqL@calimero.vinschen.de>
 <1c0fb53a-2a6d-4d9d-8dbe-d70cc9296d5d@draigBrady.com>
 <37f0f8b7-4251-4acd-b448-2f0d7c30a988@cs.ucla.edu>
 <cf5a19db-0985-4f0c-887a-5eb0f7a126b4@draigBrady.com>
 <675dac19-3c71-436f-93ce-e8f73b65b16c@cs.ucla.edu>
 <Z-reVvpUB2n8pG-2@calimero.vinschen.de>
 <8082949c-968d-44ed-b8c7-88bb239c3653@cs.ucla.edu>
 <1448648585.20250401130709@yandex.ru>
 <896fb3d5-e019-4261-9284-58c204f03da6@cs.ucla.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <896fb3d5-e019-4261-9284-58c204f03da6@cs.ucla.edu>
Precedence: list
From: Corinna Vinschen via Cygwin <cygwin@cygwin.com>
Reply-To: cygwin@cygwin.com
Cc: Corinna Vinschen <corinna-cygwin@cygwin.com>, cygwin@cygwin.com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>

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