DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52SA0oI03957310 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 52SA0oI03957310 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=MaxPfpXx X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 50926382E2A6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1743156049; bh=ilKIam3pSkEkOj5n3d1n2S9V6NS9RnJbbE55M+vdzto=; 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=MaxPfpXxsiV44zvB9++l8G42PXd8P/r/WGTleEUNI/DKmi9ptN38fIi4HxSpxGMzh uKX39lB1IMyDzUn04FMdIghjXQ6cnvQenWaC0q5JYAAjHi+TGCeGswmLy3S2a1NPda +oKLJ1RX8LMyPEXbrIK26Vnmdeu9k7Ltq6PjqdPs= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 29234382E285 Date: Fri, 28 Mar 2025 10:59:36 +0100 To: Bruno Haible Subject: Re: symbolic link curiousity in 3.6.0 Message-ID: Mail-Followup-To: Bruno Haible , cygwin AT cygwin DOT com References:

<8758454b-bd9f-427b-9cc7-854ffd9b9596 AT maxrnd DOT com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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" [Adding Bruno Haible] Hi Bruno, can you please take a look? To reiterate, with coreutils 9.6: $ ln -s foo bar $ ls -l bar ls: bar: Not supported lrwxrwxrwx 1 corinna vinschen 3 Mar 27 10:20 bar -> foo The introducing commit in coreutils is apparently commit b58e321c8d5dd ("ls: suppress "Permission denied" errors on NFS") The reason this works as expected on Linux but not on Cygwin is that the underlying gnulib function file_has_aclinfo() differs between Linux and Cygwin. On Cygwin, it's basically just a call to acl_get_file() since Cygwin has the POSIX.1e functions but none of the extensions of Linux or FreeBSD/NetBSD. As a result, when calling file_has_aclinfo("bar",...), the symlink "bar" is always followed and file_has_aclinfo() returns with errno set to ENOENT. See below for the rest of the story. Two questions: - Would you place the problem inside gnulib:file_has_aclinfo() or coreutils:gobble_file()? Personally I think this is a coreutils problem rather than a gnulib problem in that it fails to take ENOENT on symlinks into account. - Would it make sense to implement the FreeBSD/NetBSD functions acl_get_fd_np() and acl_get_link_np() in Cygwin? Theoretically this should fix the problem without having to fix coreutils, but I think coreutils really should take systems into account which only have the documented POSIX.1e functions. What do you think? Thanks, Corinna On Mar 27 11:49, Corinna Vinschen via Cygwin wrote: > [...] > Ok, this looks like a coreutils 9.6 problem. > > What happens is that 9.6 `ls -l' tries to fetch the ACL of "bar". > However, "bar" is a symlink, and the underlying acl_get_file() function > resolves symlinks. What it does is, it tries to open("bar") for reading > the ACL. This is resolved into "foo", which doesn't exist. So the open > call returns ENOENT, and this is returned to the calling ls(1) function > file_has_aclinfo(). > > Two frames up is the function gobble_file(). This function encounters a > return value of -1 from the called function file_has_aclinfo_cache() > with errno set to ENOENT. Next is a funny expression: > > bool cannot_access_acl = n < 0 && errno == EACCES; > > So cannot_access_acl is not set, because errno is not EACCES. > > 9 lines later, we have this expression: > > if (format == long_format && n < 0 && !cannot_access_acl) > error (0, ai.u.err, "%s", quotef (full_name)); > > And this is what prints the "Not supported" error to stdout, because > ai.u.err is preloaded earlier with ENOTSUPP. > > So the entire reason for the message is an (IMHO wrong) expectation in > terms of calling acl_get_file() on a symlink. > > I'd be surprised if that doesn't occur on Linux as well, unless it's > wrong that Cygwin's acl_get_file() follows symlinks. > > However, I checked this scenario codewise against libacl, which is the > library providing acl_get_file() on Linux. > > ACLs on Linux are stored in extended attributes, and consequentially > libacl's acl_get_file() calls getxattr(filename, ...) to fetch the ACL. > Note, it calls getxattr, NOT lgetxattr, so it follows symlinks just as > Cygwin's acl_get_file(). > > What surprises me is that you say it doesn't occur prior to the -327 > test release. It occurs even back to 3.5.5 for me. The error occuring > here shouldn't depend on the Cygwin version. "foo" doesn't exist and > the open() behaviour of acl_get_file() has never changed for symlinks. > > > 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 -- 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