-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Eric Blake on 1/10/2009 6:58 PM: > 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.
Jim, you may want to take a look at this assertion in find, caused by your improvements to gnulib fts to avoid excess stat's on new enough cygwin. > > 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? Currently, the ELOOP case triggers fts_info of FTS_NS rather than FTS_SLNONE. On seeing FTS_NS, find's consider_visiting calls symlink_loop, which performs a stat, but does not adjust state.have_stat to record this fact, leading to potentially duplicated stat's. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklpWZoACgkQ84KuGfSFAYBXqACdHkhzXQlFP9GKMSSDhC5cvIDj +6IAoKc7JSeDuUDPXwUtd/lP59j8o6Uv =bczA -----END PGP SIGNATURE-----
