File::Find maintains its state in package level lexicals. So when you call File::Find from within the wanted() function it resets the state and thus looses track of where it was. I believe that this is implicitly a bug. I contemplated hacking File::Find into a OO version that maintains its state within an object thus allowing you to do what you wanted to do, but I dont have the time to deal with code that crotchety right now (it has gone on my list of things to do though.)

The way to deal with this is to use something like a breadth-first-traversal pattern. Ie, when you find a file that will cause the files in some other directory to change then push that file onto a list. Find all the files that need such an action _first_ then do the updating afterwards. Something like so: (this says that if we find a file in the first find then we will delete all similarly named files in a different dir)

 
  # untested example code that could cause all of your .pl files to be
+ deleted!
  my @fix;
  find {no_chdir=>1,
        wanted=>sub{ -f && m/\.pl$/ && push @fix,[File::Spec->splitpat
+h($_)];}
       },@paths;
  foreach my $fix (@fix) {
     find { no_chdir=>1, 
            wanted=>sub{ 
                 -f && (File::Spec->splitpath($_))[2] eq $fix->[2] && 
+unlink $_
            }
          },do{ (my $x=$fix->[0].$fix->[1]) =~s/foo/bar/g; $x};
  }
[download]

This is fairly idomatic perl code (sorry) but hopefully you get the idea.

--- demerphq
my friends call me, usually because I'm late....