Follow-up Comment #1, bug #25294 (project findutils):
More info:
The bug first surfaced in commit acb82fe, Nov 30 2008, at the point when Jim
provided a patch to gnulib fts to do fewer stat's when d_type is reliable.
The problem starts when readdir recognizes that it is too expensive to decide
what the type of a broken symlink is (at least on cygwin), and returns
DT_UNKNOWN (defined as 0). Next, fts calls fts_stat, which fails because the
symlink is broken, but on cygwin, a symlink to "//nowhere" fails with the
nonstandard errno==ENOSHARE rather than the more typical ENOENT, so no lstat
is attempted to see if the file might be a dangling symlink.
So the bug might be in fts.c, line 1540, for not recognizing all cases of bad
symlinks (even ignoring cygwin's nonstandard ENOSHARE, what happens for a
looping symlink that returns ELOOP?). Would a readlink() be better than
lstat() to determine that a symlink exists but can't be followed?
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?25294>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
