[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dirent.d_ino check
From: |
Eric Blake |
Subject: |
Re: dirent.d_ino check |
Date: |
Tue, 10 May 2005 03:47:23 +0000 |
> 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