Follow-up Comment #11, bug #23443 (project findutils):
If we save additional information from stuct stat as potentially
disambiguating information, we run the risk of (more) false negatives. For
example while we are searching /a/b/c/d something could concurrently modify
/a/b, changing its mtime, ctime, size, mode, number of links, uid, gid, and in
extreme cases also block count. The only things I can see in struct stat
that would not change are the file-type fields in st_mode (that is, S_ISDIR
would still be true) and probably st_blksize (which is likely not
disambiguating anyway).
We could also try to qualify possible false positives by checking st_dev and
st_ino on the directory _containing_ the potential ancestor in the loop.
There are a number of possible problems with this (poor performance and
possible problems with FTS_LOGICAL). I suppose this also slightly changes the
side effects of "mv /a/b/c/d /a", though I guess in the worst case the new
parent would make us traverse the cycle one more time before becoming sure
there is a cycle. That would mean in our case that we would return FTS_D for
some things for which we should return FTS_DC.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?23443>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
