Hi, There's exactly one usage of the dirent.d_ino member in the whole project, which is in the readdir loop in scp.c, like this: while (readdir) { if (d_ino == 0) continue; [...] } This loop is basically taken from rcp.c as far as I can see. However, I have two problems here. - First, I have no idea why and when readdir should return an entry with a 0 inode number. Is that historically? - Second, POSIX does not demand the existence of the d_ino member in dirent. Only systems which claim to be X/Open compatible are required to have the d_ino member in dirent. See http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html and http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap02.html#tag_02_01_04 Since it's fairly tricky and time consuming to generate the correct inode number when running the Windows equivalent of readdir, the d_ino entry was faked in Cygwin by using a name hash for a long time now. The problem is that this doesn't match the inode number returned by the Windows equivalent of the stat function, which can result in some applications creating dubious error messages. So, after some wailing and chattering we're now trying to get rid of the d_ino field entirely, since we're not trying to be X/Open compatible. We would already be happy to be POSIX compliant :-} The question now is this. Is the above test for a 0 inode number still required or is that something long gone? And, if it's still required, would it be ok to disable the test for system which are not X/Open compatible, either by using some define (_XOPEN_UNIX ?), or by adding a configure test for d_ino? Thanks in advance, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat