From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eric Blake Newsgroups: gmane.os.cygwin,gmane.emacs.devel Subject: Re: New platform independent problem Date: Fri, 20 Jan 2006 06:59:01 -0700 Message-ID: <43D0ECA5.3030506@byu.net> References: <43D0797C.1030604@it.to-be.co.jp> <20060120122559.GZ8318@calimero.vinschen.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1137765567 4013 80.91.229.2 (20 Jan 2006 13:59:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 20 Jan 2006 13:59:27 +0000 (UTC) Original-X-From: cygwin-return-117758-goc-cygwin=m.gmane.org@cygwin.com Fri Jan 20 14:59:25 2006 Return-path: Envelope-to: goc-cygwin@gmane.org Original-Received: from sourceware.org ([209.132.176.174]) by ciao.gmane.org with smtp (Exim 4.43) id 1EzwnN-0001LM-Gk for goc-cygwin@gmane.org; Fri, 20 Jan 2006 14:59:17 +0100 Original-Received: (qmail 1027 invoked by alias); 20 Jan 2006 13:59:12 -0000 Original-Received: (qmail 1016 invoked by uid 22791); 20 Jan 2006 13:59:09 -0000 X-Spam-Check-By: sourceware.org Original-Received: from sccrmhc13.comcast.net (HELO sccrmhc13.comcast.net) (63.240.77.83) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 20 Jan 2006 13:59:06 +0000 Original-Received: from [192.168.0.100] (c-24-10-241-225.hsd1.ut.comcast.net[24.10.241.225]) by comcast.net (sccrmhc13) with ESMTP id <2006012013590301300o9b2te>; Fri, 20 Jan 2006 13:59:04 +0000 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) Original-To: cygwin@cygwin.com, emacs-devel@gnu.org, Eli Zaretskii In-Reply-To: <20060120122559.GZ8318@calimero.vinschen.de> X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Xref: news.gmane.org gmane.os.cygwin:73978 gmane.emacs.devel:49317 Archived-At: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Corinna Vinschen on 1/20/2006 5:25 AM: > > I'm also having a problem right now building rcp and scp due to the > missing d_ino. OTOH, the d_ino member is not required by POSIX, but > only in X/Open compliant OSes, see > > http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html > http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap02.html#tag_02_01_04 > > So, portable applications shouldn't rely on d_ino. Is there a compromise here? Many applications that look at d_ino also check whether the d_ino member is 0, in which case they fall back on st_ino. For example, coreutils's pwd.c contains: #define NOT_AN_INODE_NUMBER 0 #ifdef D_INO_IN_DIRENT # define D_INO(dp)((dp)->d_ino) #else /* Some systems don't have inodes, so fake them to avoid lots of ifdefs. */ # define D_INO(dp) NOT_AN_INODE_NUMBER #endif Then later on, it can blindly do: ino_t ino = D_INO(dp); if (ino == NOT_AN_INODE_NUMBER) { if (lstat (dp->d_name, &ent_sb) < 0) continue; /* Skip any entry we can't stat. */ ino = ent_sb.st_ino; } > > Whether we should revert to using d_ino or not, I'm not sure. From a > Windows perspective, it's a step in the right direction. From an > application portability perspective, it should be ok to do it. From a > Linux compatibility perspective, which we claim, it might be somewhat > hazardous to drop d_ino, though. This would allow cygwin to provide the d_ino member (but probably in a new offset, rather than renaming __deprecated_d_ino back to d_ino, to avoid breaking backwards compatibility with old cygwin apps that have come to rely on the field at offset __deprecated_d_ino being a hash rather than an inode value). Cygwin would then set it to 0 on WinNT and 2k (where it is prohibitively expensive to determine a real value), set it to the hash on Win9x and ME (since st_ino is also the hash on those platforms), and set it to the actual st_ino value on WinXP and beyond (since the API exists). It would just be a matter of educating apps that use d_ino that when d_ino==0, fall back on st_ino instead. And based on the code in coreutils, this is probably already the case for code that strives to be portable, since it appears there are already existing Unix machines that return d_ino == 0 when a real value is not available. - -- Life is short - so eat dessert first! Eric Blake ebb9@byu.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD0Oyk84KuGfSFAYARArXgAJ0aQu09wfK4ab0R+upRH7kLq6FlTACgluSD Y8hqZD9P15tdhF6v2Rv2sXY= =+rha -----END PGP SIGNATURE-----