James Youngman wrote: > On Sun, Jul 19, 2009 at 9:35 PM, Jim Meyering<j...@meyering.net> wrote: >> I'm considering a rewrite of rm that uses fts.c, >> and see that the resulting rm fails coreutils' rm/cycle test >> because it incorrectly reports a cycle for that unusual case. >> >> The following patch fixes fts so that it properly reinitializes one of >> its cycle-detection data structure for each new command line argument. >> >> I might save a little by merely clearing the hash table >> and reusing it, rather than freeing it altogether, but don't >> think that would be worth the added code. >> >> I have not yet been able to cause trouble with chmod, chown, chcon, >> or du, but haven't tried very hard, either. > >>From your description, I would have assumed that find would be > affected, but this appears not to be the case: > > $ ./find/find ~/tmp/a ~/tmp/a > /home/james/tmp/a > /home/james/tmp/a/file > /home/james/tmp/a > /home/james/tmp/a/file
The difference is that the rewritten rm calls fts_open just once with all of its non-option command line arguments. By contrast, ftsfind.c calls fts_open for each command line argument individually. Since fts_open is what initializes the cycle-detection machinery, find is not susceptible.
