From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Corinna Vinschen Newsgroups: gmane.os.cygwin,gmane.emacs.devel Subject: Re: New platform independent problem Date: Fri, 20 Jan 2006 13:25:59 +0100 Message-ID: <20060120122559.GZ8318@calimero.vinschen.de> References: <43D0797C.1030604@it.to-be.co.jp> Reply-To: cygwin@cygwin.com, emacs-devel@gnu.org, Eli Zaretskii NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1137759986 16671 80.91.229.2 (20 Jan 2006 12:26:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 20 Jan 2006 12:26:26 +0000 (UTC) Original-X-From: cygwin-return-117754-goc-cygwin=m.gmane.org@cygwin.com Fri Jan 20 13:26:24 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 1EzvLJ-0004sJ-LX for goc-cygwin@gmane.org; Fri, 20 Jan 2006 13:26:14 +0100 Original-Received: (qmail 32134 invoked by alias); 20 Jan 2006 12:26:07 -0000 Original-Received: (qmail 32124 invoked by uid 22791); 20 Jan 2006 12:26:07 -0000 X-Spam-Check-By: sourceware.org Original-Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 20 Jan 2006 12:26:03 +0000 Original-Received: by calimero.vinschen.de (Postfix, from userid 500) id B42ED544001; Fri, 20 Jan 2006 13:25:59 +0100 (CET) Original-To: cygwin@cygwin.com, emacs-devel@gnu.org, Eli Zaretskii Mail-Followup-To: cygwin@cygwin.com, emacs-devel@gnu.org, Eli Zaretskii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i 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:73974 gmane.emacs.devel:49311 Archived-At: On Jan 20 13:08, Eli Zaretskii wrote: > > Date: Fri, 20 Jan 2006 14:47:40 +0900 > > From: djh > > > > In December of last year, 2005, the cygwin developers deprecated d_ino > > out of the dirent.h defined dirent structure. > > > > This break emac's dired.c (from compiling) > > > > Ref: http://www.cygwin.com/ml/cygwin/2005-12/msg00205.html > > Without knowing the full details, I'd risk saying that this was not > the best decision. Is there really no way of making d_ino be > consistent with what `stat' returns about the same directory? The problem is that the Windows functions for reading directory content don't return the inode number(*), so we ended up using a namehash for the d_ino member. Otherwise, to get the inode number for the files' directory entry, we would have to open each file to get a handle, then call GetFileInformationByHandle, and then have to close the handle again. This would make the readdir function *very* slow. The other alternative would be to use always a namehash, also in the st_ino case. The problem with this approach is that hardlinks to the same file would have different inode numbers, which then confuse tar or cpio. > In any case, I think removing the member is a solution that is much > worse than the problem: many programs refer to d_ino, but don't > require too much from its contents. These programs will now fail to > compile. I don't think that the goal of educating the maintainers of > Bash and Find (a worthy goal in itself) justifies breaking the other > packages. > > If making d_ino consistent with st_ino is impossible, a better way of > dealing with problems in Bash and Find is to make changes in those > packages' sources that are specific to Cygwin. 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. 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. Corinna (*) Beginning with Windows XP, two such functions exist now, but they won't help for older OSes, obviously. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat