Eric Blake <e...@byu.net> wrote: > According to Jim Meyering on 1/11/2009 3:06 PM: >> I tried your "find -L dir-containing-loop" example >> on ext3, tmpfs, and xfs, and it appears d_type is always DT_LNK, > > Is there any file system on Linux where you can always get DT_UNKNOWN? If > not, I'll keep playing with it on the cygwin side of things.
Sure. reiserfs (3 at least) has no d_type information. >> so what do you think about changing the test to e.g., >> >> if (FAILED_STAT_ERRNO_MAY_INDICATE_SYMLINK (errno) >> >> Where the macro is defined like this: >> >> #ifdef ENOSHARE >> # define FAILED_STAT_ERRNO_MAY_INDICATE_SYMLINK(Errno) \ >> ((Errno) == ENOENT || (Errno) == ENOSHARE) >> #else >> # define FAILED_STAT_ERRNO_MAY_INDICATE_SYMLINK(Errno) ((Errno) == ENOENT) >> #endif > > I already did something like that patch that on my copy of findutils on > cygwin; the //noshare bug went away, but the assertion failure on a loop > still remains. But this particular patch seems like overkill, now that > cygwin no longer returns ENOSHARE (as of this morning, the developers Good! > agreed that ENOSHARE doesn't make sense any more; it predates the time > when cygwin had support for //server syntax): > > http://cygwin.com/ml/cygwin/2009-01/msg00284.html > http://cygwin.com/ml/cygwin-cvs/2009-q1/msg00014.html > >> I checked a few Linux/GNU systems and found no ENOSHARE definition. >> I.e,. how about this patch? > > Let's not bother with it. Cygwin 1.5.x is immune (no d_type support), and > since cygwin 1.7.0 is not yet a stable release, and has fixed the ENOSHARE > issue already, there are no stable cygwin releases that need the workaround. All the better. > On the other hand, what did you think of my idea of using readlink() > instead of lstat() to determine if a file is a symlink after stat() fails > (and when d_type is unavailable or DT_UNKNOWN)? Is that any more Documented semantics of FTS_SLNONE require that fts_statp point to valid stat data. > reliable? Or would the slight semantics changes introduced by treating > things like ELOOP as FTS_SLNONE instead of FTS_NS be an issue? It might be. That change would make at least tests/du/long-sloop fail in coreutils' test suite.
