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/.../dirent.h.html

and

http://www.opengroup.org/onlinepubs/...l#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

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://www.mindrot.org/mailman/listi...enssh-unix-dev