delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2009/01/11/09:47:45

X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL
X-Spam-Check-By: sourceware.org
Message-ID: <496A0673.108@byu.net>
Date: Sun, 11 Jan 2009 07:47:15 -0700
From: Eric Blake <ebb9 AT byu DOT net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: find assert
References: <495A4B87 DOT 3080009 AT partners DOT org> <20081230170638 DOT GB5230 AT ednor DOT casa DOT cgf DOT cx> <20081230174104 DOT GD5230 AT ednor DOT casa DOT cgf DOT cx> <20081230175246 DOT GE5230 AT ednor DOT casa DOT cgf DOT cx> <20081230190603 DOT GA13443 AT ednor DOT casa DOT cgf DOT cx> <49695A74 DOT 1010302 AT byu DOT net> <20090111091638 DOT GH400 AT calimero DOT vinschen DOT de>
In-Reply-To: <20090111091638.GH400@calimero.vinschen.de>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Corinna Vinschen on 1/11/2009 2:16 AM:
>> To some degree, it is a cygwin bug, when "n" points to "//nowhere".  If
>> stat("n",&st) were to fail with the standardized ENOENT, rather than the
>> cygwin-specific ENOSHARE, then fts_read would have set fts_info to
>> FTS_SLNONE (a dangling symlink) rather than FTS_NS (stat failed, possibly
>> from ELOOP).
> 
> Are you proposing that Cygwin should change setting errno from ENOSHARE
> to ENOENT?  ENOSHARE is only set in one single instance and is only
> explicitly requested in another.  AFAICS, dropping ENOSHARE entirely
> would only simplify the code and should have no negative consequences
> (knock on wood here).

Changing from ENOSHARE to ENOENT would certainly be more POSIX-compliant -
the error is conveying the information that a path does not exist.  Also,
if you put some historical context on the problem, ENOSHARE predates the
implementation of the // namespace.  Back when //server did not represent
a valid path name, it made sense to have a different error for
//nosuch/share seeing as how //nosuch could never resolve on its own.  But
now that //nosuch can potentially resolve, it makes sense to treat it like
any other path name that can potentially resolve, by returning ENOENT.

However, I discovered that find still has a bug, whether or not we change
away from using ENOSHARE; the assert was also reproducible in this situation:

$ mkdir example
$ ln -s loop example/loop
$ find -L example

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9 AT byu DOT net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklqBnMACgkQ84KuGfSFAYCztQCgo/d7I4lDUrppbl7AowdEJDV8
K14An2zZoXXEDAH9Q1xbof0AgqxLfK1t
=deOC
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019