X-Spam-Check-By: sourceware.org
Date: Fri, 20 Jan 2006 13:25:59 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com, emacs-devel AT gnu DOT org, Eli Zaretskii <eliz AT gnu DOT org>
Subject: Re: New platform independent problem
Message-ID: <20060120122559.GZ8318@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com, emacs-devel AT gnu DOT org, Eli Zaretskii <eliz AT gnu DOT org>
Mail-Followup-To: cygwin AT cygwin DOT com, emacs-devel AT gnu DOT org, 	Eli Zaretskii <eliz AT gnu DOT org>
References: <43D0797C DOT 1030604 AT it DOT to-be DOT co DOT jp> <ur773qhq5 DOT fsf AT gnu DOT org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ur773qhq5.fsf@gnu.org>
User-Agent: Mutt/1.4.2i
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT 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

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

--
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/