Re: [bug #25294] assertion failure on dangling symlink to //

[Eric Blake]

-----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             address@hidden
-----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-----