Re: dirent.d_ino check

[Eric Blake]

> As I understand it, that test will work only if you happen to run
> it in an NTFS file system.
> 
> How about if we just modify the test to always report failure when
> building for Cygwin?  That's simple and it's better than sometimes
> returning the wrong answer.

That's fine for now, and much simpler (but will need revisiting if cygwin ever 
fixes this POSIX-compliance bug).

Apparently, Windows XP is much more efficient than Windows NT at reading inodes 
off an NTFS drive, and one of the cygwin developers is contemplating a patch 
that would enable correct readdir() inodes for NTFS, but only on XP.  If that 
patch goes in, should readdir() be changed in NT to always set d_ino to 0 on 
NTFS?  It looks like everywhere that coreutils looks for d_ino, it uses macros 
that default to 0 on systems without support, so that d_ino of 0 falls back to 
the stat() family.  If that fallback is common practice among portable 
programs, then having cygwin return 0 rather than a bogus hash when the cost of 
determining the inode is prohibitive would be preferable for allowing dynamic 
runtime detection rather than a fixed autoconf run test.  And on FAT, where the 
hash IS the inode, cygwin could get the speed benefit from having a valid d_ino.

--
Eric Blake