> 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 _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils